On Fri, Apr 02, 2004 at 12:49:55PM +0200, Adrian Bunk wrote:
> > There are two main reasons for that: one is it's essentially impossible
> > to install testing, although we might see that one solved after sarge
> > is released with d-i. The other is that there's no security support
> > for testing, and there's still no prospect of that changing.
> The first issue you mention isn't an issue for people who upgrade from
> the current stable.
*shrug* People can't upgrade from current stable and use testing because
there's no security support, and people can't install testing from scratch
because there's neither an installer nor security support. That takes
away pretty much all of the motivation for worrying about other details
that stop it from being "constantly releasable"; which leaves only its
other use, namely "helping prepare the next stable release". You're
welcome to dispute the utility of it there, but I can assure you that
in my experience it's both a far more efficient use of my time and has
far better results than the alternatives.
> There are other problems that are not external but problems with testing
> itself:
> E.g. for some time, there was an unusable mixture of GNOME 1 and GNOME 2
> in testing.
I've been running testing on my desktop system exclusively since 2000 or
so; and the only GUI unusability was a single X bug that was downgraded
that shouldn't've been. You're welcome to be unhappy with the results
but, again, your opinion really doesn't matter that much. The results
were exactly appropriate and to be expected, and if the maintainers are
or were unhappy, they have the mechanisms to avoid it.
> And there are far more serious bugs in testing than in stable, e.g.
Of course there are. There. is. no. security. support.
> I
> personally know a person who had serious mail loss because of #220983,
> and the cyrus-imapd/libc6 combination causing this problem was in
> testing at this time.
I've no idea why you'd want to worry about occassional mail loss when
occassional remote root exploits are still a problem.
> > > I have yet to see any objective evaluation whether testing really is an
> > > improvement.
> > potato's release was held up by RC bug fixing -- b-f's was working
> Not only RC bugs fixing.
Yes, RC bug fixing. The release wasn't held up while people fixed random
other things; and indeed, if people weren't fixing an RC bug in their
upload their random other fixes got rejected. Do you know how I know
this? Because I rejected packages for exactly that reason.
> There were also two months spent in three test cycles. During the first
> two test cycles several bugs were discover that were fixed before
> Debian 2.2.
Several bugs? Hundreds of RC bugs were discovered and fixed in that period.
> This wasn't "bug fixing", it was "bug finding", and the thorough
> testing contributed to the good quality of potato.
Yes, and that's what's going on now. That's what the installation-reports
and upgrade-reports pseudo packages are for. That's what the
debian-testing list is for. That's why people run pbuilder. It's why
people run unstable and testing systems, even without security support.
If testing is important -- and it is -- it needs to be done continually,
not for a few weeks or months just before release.
> I'm wondering why the Debian 3.1 schedule is so tightly coupled on _one_
> external source (the Debian installer), but lets nearly no time for
> testing after actual freeze.
You shouldn't be. The reason Debian's so tightly coupled to one particular
project (which isn't remotely external), is that of the software required
for a stable release, it's the only one that's not within a few days or
a fortnight of ready to be released.
The reason we don't set aside much time for "bug fix only" work
immediately before a release is that we don't have the resources to
manage it per se -- we have some 20k open bugs across some 5000 packages,
and manually verifying that uploads of those packages aren't accidently
adding features simply isn't possible -- and the nearest compromise we
have -- which is limiting it to RC bugfixes only -- simply doesn't need
a long freeze the way we're doing things now.
> The many package removals are not something I'm a fan of.
> During the potato freeze, it was always clear which package might be
> removed long before.
Every package on http://bugs.debian.org/release-critical is a candidate
for removal. A list of such packages is posted to debian-devel-announce
regularly. I don't believe any of those packages are being removed within
a few weeks' of an RC bug being filed unless the maintainer specifically
asks otherwise; if that's not the case, it's probably a mistake and I'd
be interested to see any examples.
> I'm not concerned about "very important" packages like Gimp. I'm more
> concerned about one package here and one package there like users are
> asking "Why is gnuchess not in Debian 3.0?".
I can't say I'm particularly impressed at not being able to find an
explicit answer to that; but the simplest explanation is that Bug#102449
didn't get fixed for ten months (two months as RC), and the fix didn't
get uploaded to unstable in time before the "zero kelvin" freeze began.
I can't see an obvious reason why the fix didn't get in, though there
were two security holes discovered later (Bug#162701 and Bug#163757),
and there was a relatively severe usability bug discovered within a week
or so of the "fixed" version's upload, that didn't get fixed for five
and a half months. I don't think I knew about either of the first two
bugs, and don't see why I would've considered the other bug RC, though;
it's possible the lack of gnuchess was accidental.
If you want something to fix, then the most important thing to work on
is avoiding having packages have RC bugs for months on end.
That's not to say that questions like "Why is gnuchess not in Debian 3.0?"
should be as hard to answer even this far after the fact as they are.
> I have sometimes the
> impression removing packages should in some way punish the maintainer.
It's not about punishing anyone; it's about making sure that everyone
else who uses Debian actually ends up getting a result.
> > If you think this is a major problem work on ensuring programs with bugs
> > are found and fixed in unstable, or beforehand.
> This doesn't reduce the continous stream of new bugs and problems
> introduced by new upstream versions. And it often takes a month or two
> until some serious bug is discovered and reported.
Huh? "Finding and fixing bugs before they get into unstable" "doesn't reduce
the new bugs by new upstream versions" ?
If you really think that, you've either misread or misunderstood what
I said. Let me translate: find and fix the bugs in upstream or unstable
before they get to testing, let alone stable.
Do it before the package gets out of development versions. Do it
by writing automated test suites, or packaging the software for
experimental. Or do it some other way. Whatever.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
Linux.conf.au 2004 -- Because we could.
http://conf.linux.org.au/ -- Jan 12-17, 2004
Attachment:
signature.asc
Description: Digital signature