[Mageia-dev] [Mageia-discuss] MANDATORY READ : 7 days before misc unleashes CERBERUS !

Fri Sep 16 22:27:23 CEST 2011

Le vendredi 16 septembre 2011 18:48:20, Colin Guthrie a écrit :
+> 'Twas brillig, and Michael Scherer at 16/09/11 14:39 did gyre and gimble:
+> > Le vendredi 16 septembre 2011 à 12:44 +0200, Guillaume Rousse a écrit :
+> >> Le 16/09/2011 11:47, Sander Lepik a écrit :
+> >>> 15.09.2011 21:43, Maarten Vanraes kirjutas:
+> >>>> I have a script ready to set the last comittor (that's a full
+> >>>> packager) as
+> >>>> maintainer. perhaps it can be activated before the GREAT PURGE.
+> >>> 
+> >>> That's not so good idea. What we maybe can do is that we send out a
+> >>> warning that if you commit to a package after the warning and the
+> >>> package has no maintainer yet then you become one. So that people would
+> >>> first check what they get on their name. Many packages were imported by
+> >>> Anne, i'm not sure that she's going to maintain them all. :)
+> >>> 
+> >>> I would do something like that:
+> >>> 2 months of warning period, if you touch package that has no maintainer
+> >>> you become its maintainer. After 2 months we start dropping those
+> >>> packages that have still no maintainer.
+> >> 
+> >> This whole idea of 'touch a package, become its maintainer' assumes than
+> >> anyone modifying a package has an obvious interest in it.
+> > 
+> > Then we can increase the heuristic, like "upgrade to a new version", or
+> > "do several commit on it". Someone upgrading a package either :
+> > - is interested in it for the package ( and thus would be a maintainer )
+> > - is interested into having it upgraded for using on another package
+> > ( and thus, as a user of the rpm for another rpm, has a interest to not
+> > make it disappear ).
+> > 
+> > And i doubt that someone would do X commit on a rpm if not interested in
+> > it.
+> 
+> Are heuristics a good idea? How about just making mgarepo ask you if you
+> want to become the maintainer with a Y/n option (Y being default) when
+> you call submit on an unmaintained package.
+> 
+> This should be simple enough that people genuinely maintaining it can
+> just hit return and also easy enough to opt out in the case of drive by
+> upgrades.
+> 
+> Col
+
+This is an idea I like. More visibility to the fact that the package is 
+unmaintained, but no mandatory assignment.
+
+I also think, like Philippe, that groups would help here : if for example a 
+"games" packager group is ready to maintain all games that have no specific 
+maintainer, I would certainly join that group. 
+
+Best regards
+
+Samuel
+