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. > This is almost ridiculous. The reason you've missed it could very well be > that the package doesn't interest you at all and that you've not had a > look at it (or its http://bugz.fedoraproject.org/NAME page) before. You > haven't taken care of it in the package collection either. And if you've > discovered the software just recently, would you be its only user in > Fedora? Nobody else? Perhaps just a few users who run with a personal > repo or a 3rd party repo on the web? Impressive. One example is smb4k. I hadn't noticed that because I don't use it myself, but more than one user has asked for it, 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. Kevin Kofler -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
