[Mageia-dev] new mgarepo version

Sat Jul 16 03:27:18 CEST 2011

Le mercredi 13 juillet 2011 à 21:31 +0200, Maarten Vanraes a écrit :
+> Op woensdag 13 juli 2011 20:46:30 schreef nicolas vigier:
+> [...]
+> > > Is this process also available for novice packagers?
+> > 
+> > Novice packagers cannot be maintainer. But content of maintdb is
+> > also available at this url :
+> > http://pkgsubmit.mageia.org/data/maintdb.txt
+> 
+> I would like novices to be allowed to grab maintainership as well for the 
+> following 3 reasons:
+>  - easier as a padawan to check your packages and followup to see which have 
+> to be updated/backported
+
+Then we should not use maintainership as the only source for such
+informations. The tool written by stormi ( madb ) should fill that gap.
+
+>  - the day a padawan gets full packager, he would have to set all the 
+> packages, and it might not be easy to find them, or even alot of work, if the 
+> mentor has alot of them
+
+If there is lots of packages, then either the packages are not good
+enough, and the mentor should not accept them so the problem should not
+exist in practice, or they are good enough, and then the novice should
+have become packager sooner.
+
+The goal of novice is not to add lots of packages to become packagers,
+but to demonstrate enough knowledge while maintaining them. So I would
+rather have a system that discourage adding lots of rpms. Ie, if there
+is a incentive to focus on existing rpms, I think we should use it.
+
+>  - bug reports would then be assigned to the mentor instead of the novice, 
+> which would perhaps give a bit more work towards mentor to notify his novice 
+> about it.
+
+If the novice disappear, then someone should take care of the packages,
+and it should be the mentor. This way, they will not accept random rpms
+thinking "this is not my duty to take care".  
+
+A novice is not responsible for a package, since he is novice. So the
+database should simply reflect that.
+
+And if restricting the access is a way to motivate a novice to finish
+his training, then we should simply do it.
+
+Also, having people being listed while not being able to submit will
+make the creation of re-assignation rules harder. ( ie, if for example
+we say that a package that was not touched by the original maintainer
+after X submit is reassigned to the current uploader, stuff like that ).
+
+-- 
+Michael Scherer
+
+