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

Allan McRae allan at archlinux.org
Tue Mar 2 21:46:57 EST 2010


On 03/03/10 03:54, Pierre Schmitz wrote:
> Am Dienstag, 2. März 2010 17:02:02 schrieb Thomas Bächler:
>> We should instead introduce a comment into those PKGBUILDs right above
>> the pkgver= to prevent people from messing with them. Something like:
>
> Or people could just talk to each other. We probably all have jabber, email
> etc., or at least send a mail to this list. If the package is orphaned or the
> maintainer is temporary unavailable just send a mail to the list.

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.

Allan


More information about the arch-dev-public mailing list