Re: Debian has failed us
From: Christian Perrier <bubulle@debian.org>
> and certainly can't expect to have everything run like a charm,
> especially with very special hardware like the one you described in
> the mail that started this thread.
It's not "very special hardware". It's a bunch of IBM JS20 blades
configured as a cluster. $1700 a pop, and that was 2 years ago.
> This kernel is not in testing because of RC issues about it
So, you can't put the testing kernel in "testing", because someone might
test it and hit a bug? I thought that was the entire point of
"testing"!!! Annoying bugs are *GOOD* things to find in testing
release, because they get fixed rapidly.
The separation between the installer and the ports is a problem. The
two need to be tested as a single unit. Otherwise you may as well have
"stable testing" and "unstable testing".
From: Joey Hess <joeyh@debian.org>
> As I have already said in this thread, those builds do not use the
> current development version of d-i (because the daily builds of d-i
> break from time to time, and it would suck if that image were broken
> for a whole week until its next build).
Let me get this straight... It's ok that I can't install it using the
old kernel for 4 months, but it would suck to use the testing kernel
because it might break the image for a *whole week*?
As I said earlier, there shouldn't be an arbitrary line between the
installer and the packages. People aren't installing "Etch the
installer" or "Etch the packages", they're installing "Etch the
release". Test both parts simultaneously, as a single unit, because
that's how your users are going to use them.
Mat
Reply to: