2010/3/3, Allan McRae <allan@archlinux.org>:
This is my take on the issues:
1) If a package is an orphan, then no-one cares much about it and anybody should feel free to update or fix it.
2) If a package is maintained by a less active dev (we all have a fair idea who they are) and needs a _minor_ version bump, go ahead. For _major_ bumps, send them an email first. From my experience, even the ones who are not so active in packaging these days respond fairly quickly to emails.
3) If a package has a bug report that has not been dealt with in a long time and the maintainer has not put a negative comment against the fix, fell free to implement it. Of course, do not blindly assume bug reporters are correct. In particular, not all feature requests should be implemented...
4) If a package is maintained by an active dev and you still can not wait for them to update/fix it, send them an email. If they are losing interest in the package, it might even be offered for you to maintain.
5) TAKE RESPONSIBILITY FOR YOUR PACKAGING. Do not touch packages that you are unprepared to be assigned bugs reports from. Even minor upstream updates can result in issues. If your update breaks something, be prepared to fix it or downgrade the package.
Of course, large rebuilds are an "all hands on deck" situation and we are all encouraged to rebuild whatever we can.
Finally, get to know you other devs. This is one of the advantages of the fairly small team we have. I have a fair idea whose packages I can update/fix without them having any issues about it; whose packages I should ask first; and whose packages I would not touch with a 10 foot pole. And some devs cover all those categories depending on the package.
Thanks a lot for your contribution, Allan. In the future, I will follow very carefully the above simple five rules. -- Arch Linux Developer http://www.archlinux.org http://www.archlinux.it