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