FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 03-03-2010, 01:46 AM
Allan McRae
 
Default Updating packages that you do not maintain - Was: samba 3.5.0 bump

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
 

Thread Tools




All times are GMT. The time now is 04:57 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org