Re: buildd administration
Anthony Towns <aj@azure.humbug.org.au> wrote:
> On Thu, Dec 15, 2005 at 10:43:05AM +0100, Frank Küster wrote:
>> Anthony Towns <aj@azure.humbug.org.au> wrote:
>> > If your package isn't going to be suitable for release; it should probably
>> > be in experimental instead, which is even autobuilt these days. There's
>> > almost no reason to have RC bugs that are open longer than a couple of
>> > weeks these days.
>> So do you suggest that I should have let tetex 3.0 migrate to testing,
>> even though there are still a couple of important issues with it, and
>> even though it would have made half of the packages that depend on it in
>> testing RC-buggy, either because they were uninstallable, or wouldn't
>> work?
>
> 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. Some of the
problems where fixed soon during this time, but most of it went
undetected.
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. So either we could have delayed teTeX 3.0 until
god-knows-when, maybe until it's too late for etch, or force some part
of the testing onto other maintainers.
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? On
the other hand, some bugs in add-on packages only revealed itself after
other add-on packages had been fixed (because the latter one's bugs
prevented the former's installation).
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...
> slightly non-standard, so presumably they're not the hold up. And heck,
> October's long enough ago that maybe there're new reasons to not add it
> to testing and the above's completely misleading now.
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.
>> I really think that such things should be sorted out in unstable first,
>> and only if the fixed packages are available should it migrate to
>> testing. At least if testing serves any purpose.
>
> The purpose of testing isn't to make it okay to put broken packages in
> unstable. If the packages in unstable aren't broken; then it's appropriate
> to put them in testing. So yes, fine -- sort them out in unstable first,
> but do it *quickly*; ie over a matter of days or weeks, not months.
You're welcome to offer me a permanent job where I can also do Debian
work, or just a permanent job that leaves me more free time for Debian
work, then I'll happily fix things within a couple of days or weeks. As
it is, nobody in the teTeX team can do that.
> 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.
> today, a year before etch's release, we're at 600
> RC bugs in testing, 1300 in unstable. Just looking at the testing count,
> that's a six month delay right there; looking at the unstable count,
> it's either something like a twelve month delay, or an indication huge
> chunks of unstable -- including packages like tetex -- won't make it
> into etch if we release on 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.
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Reply to: