On Sun, Dec 18, 2005 at 08:34:04PM +0100, Frank Küster wrote: > I don't know of any autobuilders that build packages from sid against > build-dependencies in experimental. So that's one problem. Another (mentioned previously) is the case of two packages, A and B that often should be installed together (tetex and X, say) but where that's not required by dependencies so testing can't tell. Up 'til now the only way of dealing with that has been filing a fake RC bug and hoping. In theory, we've got a new way to fix that using britney's FauxPackages rather than fake bugs now. > > "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. > > Uh, no, it shouldn't. Next December is when sarge will be released, > A year before sarge's release was June 2004, and at that time all > unenlightened DDs believed we would freeze on August 1st (or something > around that date) and release in September + x. For that very reason I > handled teTeX much more conservatively than I had done had I known that > I had one year left[1], 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 realise that you've got a hard job and you're trying to do your best, but you have to realise the consequences of that: getting a release in a year will either require you (and others) to act like you did a year before etch released; or a significant improvement in our development procedures. Personally, I'd rather the latter. > That sounds all very nice. But currently, I didn't even have time to > build a lists of packages we filed RC bugs on, and track whether they > have been properly fixed. Before that I can't judge whether it should > proceed to testing, or which packages would need to be removed. 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. > 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", another is ensuring that we have the resources to actually find and kill bugs, and another is making sure there're people around to have that attitude and use the resources. If tetex doesn't get maintained for months on end because you've got other things to do, that's a problem; if the bugs don't get found or fixed because the tools don't work or no one knows about them, that's a problem too. If they don't get fixed and worked around because people just don't think it matters, well... Sometimes the unacceptable is unavoidable, but if you let that change your attitude, you'll find you accept it even when it is avoidable, and that sucks. > [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... Cheers, aj
Attachment:
signature.asc
Description: Digital signature