Thimo: I've uploaded an NMU to fix gnuplot bugs 321967 and 330024; this is the context. On Tue, Dec 20, 2005 at 10:07:34AM +0100, Frank Küster wrote: > Anthony Towns <aj@azure.humbug.org.au> wrote: > >> > "A far-east document is typeset in a certain encoding" doesn't sound like > >> > an RC bug; and therefore not something that should hold up transitioning > >> > to testing. > >> The package with the RC bug is debian-reference, which builds documents > >> in different languages from sgml source for its binary packages. If > >> this package fails to create one of its documents, this is a FTBFS and > >> of course RC. > > Sure, but it's not an RC bug in teTeX -- and it can be downgraded by > > simply disabling the generation of that document in developers-reference. > Yes, but there were lots of bugs like this. If there were lots of bugs like that, that's fine; they all need to be fixed. > Personally, I thought and > still think that testing should rather not be in an inconsistent state > where some packages cannot be rebuilt, and therefore that teTeX 3.0 > should not enter testing unless there's at least a fixed package in sid > with good chances to propagate to testing without delay, or rather in > testing itself. Not necessarily; sometimes letting minor breakage happen in testing is the best way of ensuring testing meets its dual goals of minimal breakage and currency. > > Which is to say, had you handled tetex then, the way you are now, the > > RC bug count would have been worse, and thus would like have not dropped > > to zero by the time sarge did release a year later. > I don't think so - on the one hand I had much more time in summer 04, on > the other hand I would have stopped working on 2.0.2, which took away > quite some working and thinking time during that year, and especially > during the half year where teTeX-3.0 "rot" in experimental and sarge was > not yet released.. Sure, getting tetex-3.0 done would've been quicker; but it wouldn't necessarily have been quick enough -- after all, it's not ready *now* and there's been six months since sarge's release. And this isn't just *you*, everyone's in a similar position. > > You can use usertags to track bugs fairly easily. From the RC buglist, > > the only open RC bug mentioning tetex is against gnuplot, and has had > > a patch since it was filed four and half months ago -- that's exactly > > the sort of thing that should be fixed far more quickly than it has been. > There are I think 6 more; look for the strings "dvi" or "pdf" - > unfortunately the last one also gives some xpdf code security bugs ATM. Sure; but again, look at the broader context: if people aren't fixing trivial bugs like the gnuplot one, why should anyone else spend time worrying about the harder ones? Why haven't you done the appropriate NMU of gnuplot already, eg? > >> I (and some others) manage teTeX as a volunteer in my free time. If > >> Debian thinks that this is not enough, it should either help us with > >> manpower or drop teTeX and depending packages. Just ranting at how we > >> handle the package doesn't help us, our users or the release process. > > There're at least three aspects: one is changing the attitude from "eh, > > whatever, we're not releasing for months anyway" to "argh, i hate bugs, > > kill, maim, destroy", > Do you imply that I have the first attitude, and why? In arguing that it's okay not to fix bugs quickly? Definitely. It's the same thing when people look at the gnuplot or similar packages and say "oh well, there's no great rush to fix this, tetex 3 isn't in testing yet anyway", eg. Heck, why are we even talking about this without spending the time to fix gnuplot? Hrm. One reason is that it takes ages to setup a unstable chroot to check it builds right, and another is it takes even longer to work out how to encode your name... Doh. :) > >> [1] and I have no indication that the RC bugs count had any influence on > >> the sarge delay between summer 04 and march 05. > > If you don't take the fairly linear drop from 400 to ~0 when we released as > > an indication it had an influence, I can't think of anything to say... > If you don't understand the frustration among DDs caused by the > month-long delay of the freeze caused by the nonexistence of testing > buildd infrastructure which wasn't used in the end, Uh, the infrastructure was the sarge security buildds; they're being used almost every day. I assure you I have a pretty good understanding of the frustration at delays related to security infrasture. > and everything > beeing communicated as being fixed "during the next weeks", I can't > think of anything to say. *shrug* The way to solve that's to have the security stuff used continually, rather that having lots of cleanup work amongst dozens of systems needing to be done as part of the release pulse. Having testing and stable security integrated is my preferred way of resolving that; there are others, but they've been similarly unsuccessful, unfortunately. Cheers, aj
Attachment:
signature.asc
Description: Digital signature