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
