On Sat, 14 Jan 2012 18:45:28 +0100, KK (Kevin) wrote: > Michael Schwendt wrote: > > Why must it be the opposite? Arbitrary access to packages, possibly > > sporadic or random upgrades (as time permits), with no one taking care of > > the packages normally. > > Because it's a much more effective use of our limited manpower. Everyone > does what they currently have time for, without requiring a long-term > commitment, the overhead of having to ask for commit access, discuss things > with some assigned maintainer who thinks (because that's what he/she's told > by the project) that he/she "owns" the package (all of which requires you to > wait for the maintainer's answer, which wastes time and means you might no > longer have free time when the answer finally arrives, plus, sometimes, you > have to nag the maintainer several times to even get an answer at all) etc. > I strongly believe that in the end, that would lead to MORE problems getting > fixed, not fewer. Unconvincing. It could be that - nobody finds the time to take care of a specific package, - nobody has enough interest to monitor upstream development for the package, - nobody handles incoming bug reports for the package, - nobody really uses the package, some users give it a try, but perhaps it doesn't work well, - nobody can guarantee that the package (or a set of related packages) will still be _low maintenance_ type of packages next year (that could be due to upstream development or stuff getting ancient, and suddenly you're supposed to deal with old APIs and broken/unmaintained software), - everyone, who has touched the package over the past years, suddenly does not do that anymore -- you refer to no "long-term commitment", but actually long-term commitment is needed, even if it means that a new maintainer supersedes the previous maintainer from time to time, and for a different package, - somebody apparently takes care of it, but somebody else all of a sudden applies an upgrade for no particular reason and then hides again. [package retirement process to cumbersome] > One example is smb4k. I hadn't noticed that because I don't use it myself, "Case closed" I could throw in here then. ;) > but more than one user has asked for it, And here, too. [that deserves a :-( smiley actually] > and if it just required me to hit a > button and then fix the occasional FTBFS issues every few months, I'd > probably sign up for it. Going through the rereview process (plus the SCM > admin request to unretire the package, plus the rel-eng request to unblock > it) just exceeded my threshold of what I'm willing to do for a package I > don't use, at least up to now (and it might also be hard to get somebody to > actually do the rereview). > > Reportedly, the package was building and working just fine, so there was no > practical reason for it to get retired in the first place, even though it > had no assigned primary maintainer. It's somewhat tragic there's an endless loop already. If the package requires "no to low" maintenance, it is low-hanging fruit for newbies, too. And if nobody volunteers to take it, the loop restarts. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
