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 > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 10-08-2011, 03:20 PM
Ian Jackson
 
Default New package doesn't fix the problem in the old version

Raf Czlonka writes ("Re: New package doesn't fix the problem in the old version"):
> Hi Ian,
> > There is a third possibility which is that the maintainer has made a
> > judgement that this bug is not worth going to special effort to fix in
> > the package. Policy does not need to be involved.
>
> My point is exactly that: "who makes the call?".

The maintainer(s) of the package(s) in question. If you disagree and
care enough to escalate it, and you haven't managed to persuade the
maintainer, then debian-devel is available to give a second opinion
and if that's not sufficient for you, or doesn't reach consensus, the
Technical Committee is available to make a formal determination.

Note that when I say "haven't managed to persuade the maintainer", I
don't mean that you harangued them in a bug report, by (for example)
implying they're lazy. I mean that you had a reasonable and friendly
conversation where you make sure that the maintainer is aware of all
the relevant tradeoffs and consequences. You need to conduct this
conversation in a manner that doesn't presuppose that the maintainer
has no option but to do as you wish.

> It's not just about that package and that particular bug.
> Maybe there should be a clear policy, which should apply to all releases
> which are fully fledged (stable, testing, unstable[0]), on what is
> deemed to be called a bug fix - IMHO uninstall (purge rather) a package
> and install it again is not.

No, there shouldn't. Whether a transiently present bug needs special
action in current packages to fix it up, and how perfect that special
action needs to be, is not something we can or should write a single
simple policy for.

It's a tradeoff, of precisely the kind that we delegate to
maintainers.

> If we scale it (might be a bit far-fetched, but it really isn't IMHO)
> we get to the point where personal judgement and opinion takes
> precedence over everything else and is quite harmful[1].

If a person makes a wrong judgement, we have mechanisms to deal with
that. They may not be ideal, and I would like to see them improved,
but that doesn't mean that the right answer is to try to nail
everything down in policy.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20112.27211.999112.164717@chiark.greenend.org.uk"> http://lists.debian.org/20112.27211.999112.164717@chiark.greenend.org.uk
 
Old 10-08-2011, 03:50 PM
Stefano Zacchiroli
 
Default New package doesn't fix the problem in the old version

On Sat, Oct 08, 2011 at 04:20:43PM +0100, Ian Jackson wrote:
> Raf Czlonka writes ("Re: New package doesn't fix the problem in the old version"):
> > > There is a third possibility which is that the maintainer has made a
> > > judgement that this bug is not worth going to special effort to fix in
> > > the package. Policy does not need to be involved.
> >
> > My point is exactly that: "who makes the call?".
>
> The maintainer(s) of the package(s) in question. If you disagree and
> care enough to escalate it, and you haven't managed to persuade the
> maintainer, then debian-devel is available to give a second opinion
> and if that's not sufficient for you, or doesn't reach consensus, the
> Technical Committee is available to make a formal determination.

To nitpick a bit, your third possibility mentioned that the fix is "not
worth", but there are at least two sub-cases there: (1) maintainer does
not want to spend *their own time* preparing the fix, but would gladly
accept patches from others and (2) the maintainer does not want the fix
to reach user machines (e.g. because they consider the fix might make
things worse).

Given Raf's interest in getting this particular issue fixed, I wonder
whether he has tried proposing a patch to the maintainer (there is no
trace of it in the buglog mentioned in this thread). Going that way can
be way more useful in actually improving the life of users affected by
the issue than this intriguing discussion about who *in theory* is
responsible of cleaning up old debris.

Share the code, we'll all be happier.
--
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences ...... http://upsilon.cc/zack ...... . . o
Debian Project Leader ....... @zack on identi.ca ....... o o o
« the first rule of tautology club is the first rule of tautology club »
 
Old 10-11-2011, 07:11 PM
Raf Czlonka
 
Default New package doesn't fix the problem in the old version

On Sat, Oct 08, 2011 at 04:50:35PM BST, Stefano Zacchiroli wrote:
> To nitpick a bit, your third possibility mentioned that the fix is "not
> worth", but there are at least two sub-cases there: (1) maintainer does
> not want to spend *their own time* preparing the fix, but would gladly
> accept patches from others and (2) the maintainer does not want the fix
> to reach user machines (e.g. because they consider the fix might make
> things worse).

The fix is trivial and it won't make things worse.
Now probably not worth it but what could have been done in version 5-1:

if [ -f /etc/cron.d/git-repack-repositories ]
then
sed -i 's/bin/git-repack-repositories/bin/git-repack-repositories-cron/g'
/etc/cron.d/git-repack-repositories
fi

> Given Raf's interest in getting this particular issue fixed, I wonder
> whether he has tried proposing a patch to the maintainer (there is no
> trace of it in the buglog mentioned in this thread). Going that way can
> be way more useful in actually improving the life of users affected by
> the issue than this intriguing discussion about who *in theory* is
> responsible of cleaning up old debris.

No I hadn't as I've mentioned before, the fix is trivial and would have
taken me longer to do that than the maintainer, who already knows his
package and is dealing with debian packages on a daily basis, I on the
other hand hadn't created any packages in years.

> Share the code, we'll all be happier.

:^)

--
Raf


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20111011191058.GA20160@thor.local">http://lists.debian.org/20111011191058.GA20160@thor.local
 

Thread Tools




All times are GMT. The time now is 03:48 AM.

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