[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: