[arch-dev-public] Updating packages that you do not maintain - Was: samba 3.5.0 bump

Giovanni Scafora giovanni at archlinux.org
Tue Mar 2 21:59:15 EST 2010

2010/3/3, Allan McRae <allan at 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

More information about the arch-dev-public mailing list