On Fri, Dec 16, 2005 at 11:24:39AM +0100, Frank Küster wrote: > > No, that would be "unsuitable for release". Which is a problem that > > should either be fixed quickly, or means you're trying to make a big > > enough change that you should be working out how to get it done without > > breaking other packages in a separate area, such as experimental. > It's been in experimental for more than half a year. Err, that's kind of absurdly long too. > We could have tried to install and use every depending, and build every > build-depending package. But that is simply not feasible with the > manpower, time and machine power that's available to the teTeX > maintainers. Six months is a lot of time; and experimental should provide you with the space and machine power to handle the rebuilding. I don't know how many source changes are necessary to do the rebuilding, though. > So either we could have delayed teTeX 3.0 until > god-knows-when, Uh, no. The whole point is to delay _less_, not more. > Much worse, there are a couple of cases where we had to NMU the > packages, either because the maintainers where inactive, or in one case > because he said "no time here, just go ahead". Except for this one case > this couldn't have been done with the packages in experimental, since > failing to cooperate with a package in experimental isn't RC, is it? Not only do you not have to have an RC bug as an excuse to NMU; but uploads to experimental (which these presumably would be) have even less need for care and caution. > Of course, in principle, we could have created our own > "compatible_with_teTeX-3.0" repository and uploaded fixed packages > there, and do all the testing there. But then I don't understand what > unstable is for... Generally, experimental fits the above role. Unstable's for uploading new development of packages that will hopefully work, but might turn out not to. In particular, though, they need to be fixed pretty quickly -- six months in experimental, and another two so far in unstable isn't quickly. > Yes, the problem is that bugs in other packages keep popping up slowly. > Like #341849 in debiandoc-sgml: We already had checked that > debiandoc-sgml didn't have one of the "usual" incompatibility bugs, but > then it turned out that there is still one, which is only triggered when > a far-east document is typeset in a certain encoding. "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. Certainly, fix it ASAP once it's found, but that's the desired result for any bug. > > A year before sarge's release, we were at around 400 RC bugs in testing, > > and 600 in unstable; > Err, that should read "3 months before everybody thought sarge would be > released. Uh, no, it shouldn't. Next December is when sarge will be released, it's not some random date plucked out of the air to try to make people motivated when the real release is going to actually be nine months or eighteen months after that. We're twelve months before we want to actually release now, so it's appropriate to look at twelve months before we actually released last time. > That would be bad, but I can't see how I can speed up tetex's evolution > to be releasable by letting it rot in experimental. That's true; the idea isn't to let it rot in experimental, it's to have a quick pass through experimental that catches the most obscene bugs, then to put it in unstable where you catch a few more, then to let things progress to testing naturally, if necessary by having the RMs remove tetex related packages that aren't getting updated to the latest version in a timely or successful fashion. Cheers, aj
Attachment:
signature.asc
Description: Digital signature