Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111011191058.GA20160@thor.local
Re: New package doesn't fix the problem in the old version
Hi Ian, Thanks for taking the time to reply. All I was trying to do was to establish was whether you're being lazy/unhelpful or is there a policy which I've missed as, [...] I admit that I should have allowed a third possibility here. 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?. 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. Where should individual judgement end and a clear policy/good practice/standard way of doing things, start? 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]. The suggestion that someone is or might be lazy/unhelpful is not appropriate. It should have read: lazy or unhelpful or ... but because of there being two ORs I shortened it. As mentioned above I think I should have included a possibility of a third one. This however doesn't change the fact that lazy or unhelpful are some of many human states of mind, and therefore I don't see it as inappropriate to enumerate them as one is perfectly entitled to them. Besides, I gave it only as an option and yes, should have included more to choose from. I didn't mean any harm by it. [0] experimental excluded for obvious reasons [1] http://blog.aurel32.net/?p=47 - while the blog post itself is valuable, the links included in there show exactly what I have in mind Ta, -- Raf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111008060729.GA7757@thor.local
Re: 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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20112.27211.999112.164...@chiark.greenend.org.uk
Re: 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 »
signature.asc
Description: Digital signature
Re: New package doesn't fix the problem in the old version
* Raf Czlonka rafal.czlo...@gmail.com [111007 17:17]: While the new package indeed does not contain the bug itself when installed as a new package on a system which hadn't had it before, it does not fix the bug if installed on a system with the older version. As I had problems of understanding this first let me recap the situation: git-stuff before 5-1 created a buggy file when getting installed that is still causing problems when git-stuff 7-1 is installed. So it's not so much a bug in 7-1 but 7-1 not tidy up the mess left by earlier versions. As git-stuff was never released, those earlier buggy versions were not released either, so only people installing unstable or testing are effected. For not too serious stuff in unstable it is usually widely accepted that people sometimes might have to clean things up themselves. (Any cleaning code means the package is bigger for everyone and any fix could go wrong and introduce new bugs). I'm not sure what the consensus for packages that were in testing is (or if there was a consensus at all). I guess it mostly depends on the time it was in testing and how complicated the fix is. The bug was only in testing for either for 50 days or for 25 days, so it might depend how complex the fix is. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111007162603.gc4...@server.brlink.eu
Re: New package doesn't fix the problem in the old version
the facts.. * #640016 was introduced in version 2-1 on 2011-08-02. * #640016 was reported on 2011-09-01 and fixed on 2011-09-01 in version 5-1. * version 4-1 with the bug migrated on 2011-08-23 to testing, version 7-1 without the bug migrated on 2011-09-17 to testing. * testing was affected by the bug for 25 days. * the bug is by default not in the wild (git-repositories-repack cronjob, priority low debconf question, defaults to no). * the bug is just that the wrongly called scripts fails by doing nothing. worst case: user is annoyed by an error message that nothing happened. * git-stuff was not yet part of a stable release. my opinion.. * everything that Bernhard already said. * adding preinst scripts that check for certain md5sums for files sucks, in particular since in theory, you can only get rid of them after stable+1. so not worth the hassle, in particulary not to blow up the package considerably and unecessarily for everyone until stable+1, just to mitigate a minor annoyance for a handful of people. * unstable and *testing* users are supposed to be able to cope with the one or other glitch, if they don't, they use stable. * this is a colossal waste of time. Regards, Daniel -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e8f323e.3030...@progress-technologies.net
Re: New package doesn't fix the problem in the old version
On Fri, Oct 07, 2011 at 05:26:03PM BST, Bernhard R. Link wrote: As I had problems of understanding this first let me recap the situation: git-stuff before 5-1 created a buggy file when getting installed that is still causing problems when git-stuff 7-1 is installed. So it's not so much a bug in 7-1 but 7-1 not tidy up the mess left by earlier versions. That's correct. As git-stuff was never released, those earlier buggy versions were not released either, so only people installing unstable or testing are effected. For not too serious stuff in unstable it is usually widely accepted that people sometimes might have to clean things up themselves. (Any cleaning code means the package is bigger for everyone and any fix could go wrong and introduce new bugs). I've been using unstable exclusively for nearly 10 years. Most if not all packages I reported bugs for DO fix the issues caused by earlier versions, otherwise no one would use unstable if expected to fix everything by hand. I don't mind packages being broken, that's the reason why I use sid - to help develop Debian, find and report bugs, etc. I'm not sure what the consensus for packages that were in testing is (or if there was a consensus at all). I guess it mostly depends on the time it was in testing and how complicated the fix is. The bug was only in testing for either for 50 days or for 25 days, so it might depend how complex the fix is. It shouldn't matter that it's been in testing for so long, the bug's in unstable, and should be fixed there, even if doesn't reach testing in a long time. Both the bug and a fix are trivial - it's simply an entry in a cron job file - the links I've attached have all the relevant information. Regards, -- Raf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111007172312.GA28774@thor.local
Re: New package doesn't fix the problem in the old version
On Fri, Oct 07, 2011 at 06:09:18PM BST, Daniel Baumann wrote: my opinion.. [cut] * unstable and *testing* users are supposed to be able to cope with the one or other glitch, if they don't, they use stable. I know that, thank you. I've been doing that for nearly a decade. * this is a colossal waste of time. That might be true. All I was trying to do was to establish was whether you're being lazy/unhelpful or is there a policy which I've missed as, per my earlier email, I can't remember last time I filed a bug which later version hadn't corrected, no matter how trivial it was. Cheers, -- Raf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111007174009.GA2944@thor.local
Re: New package doesn't fix the problem in the old version
On Fri, Oct 7, 2011 at 18:40:10 +0100, Raf Czlonka wrote: On Fri, Oct 07, 2011 at 06:09:18PM BST, Daniel Baumann wrote: my opinion.. [cut] * unstable and *testing* users are supposed to be able to cope with the one or other glitch, if they don't, they use stable. I know that, thank you. I've been doing that for nearly a decade. * this is a colossal waste of time. That might be true. All I was trying to do was to establish was whether you're being lazy/unhelpful or is there a policy which I've missed as, per my earlier email, I can't remember last time I filed a bug which later version hadn't corrected, no matter how trivial it was. Looks like it's the former. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111007180017.gw2...@radis.liafa.jussieu.fr
Re: New package doesn't fix the problem in the old version
Julien Cristau writes (Re: New package doesn't fix the problem in the old version): On Fri, Oct 7, 2011 at 18:40:10 +0100, Raf Czlonka wrote: On Fri, Oct 07, 2011 at 06:09:18PM BST, Daniel Baumann wrote: * this is a colossal waste of time. All I was trying to do was to establish was whether you're being lazy/unhelpful or is there a policy which I've missed as, [...] 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. The suggestion that someone is or might be lazy/unhelpful is not appropriate. Looks like it's the former. The suggestion that someone is or might be lazy/unhelpful is not appropriate. Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111.23271.215195.156...@chiark.greenend.org.uk
