---------- Forwarded message ----------
From: Marcin Letyns <[email protected]>
Date: 2010/7/12
Subject: Re: stable? quality assurance?
To: David Newall <[email protected]>
2010/7/12 David Newall <[email protected]>:
>
> I don't know if Ted intended to be snide, but that is how he sounded. ?And
> yet, his comment was a fair reflection of how core developers seem to feel
> about stability, namely that a stable kernel is obsolete and therefore not
> particularly desirable. ?(I use the word "stable" in it's common English
> meaning, not the almost inexplicable Tux variation.)
What about a bsd variation? Last time I tried freebsd it wasn't
stable. It had problems with my hard drive controler. There are many
regressions introduced in newer releases. I see you don't want Linux
to be developed rapidly (remember your lame slow down please?).
> I think the truth is that linux kernels are only ever stable as released by
> distributions, and then only the more conservative of them. ?What comes
> direct from kernel.org, I mean those called "latest stable", are an exercise
> in dissembling. ?It's stable because someone calls it stable, even though it
> crashes and has regressions? ?That's not stable, that's just misleading.
Show me a "stable" kernel. Windows, *bsd, solaris, os x? There's none.
I've never had problems with the newest mainline kernels, because
they're rock stable and rock solid for me. Why don't go at freebsd.com
and why don't you complain they should stop calling some of the
freebsd releases a stable ones? There are regressions, ?crashes, but I
guess it's a *bsd variation of a "stable" term.
> Stable kernels *could* be stable. ?Debian succeeds. ?If it takes them a long
> time, that is only because the core developers fail to release reasonable
> quality kernels. ?Don't sneer at them because they do the right thing; do
> the right thing yourself so that they can produce more timely updates.
While there's Debian with the stable kernel then what the hell do you
want? :> I don't want Debian with its old user space and with the old
kernel. If this is what you want then what are you complaining here
about? You want everyone to choose a Debian's way? Btw. it takes
Debian developers a long time to make a release, mainly because of the
user space...
> I don't expect fair consideration of these comments; why change when
> shooting the messenger is so much more satisfying?
You missed the point, so what do you expect? Btw. slowing down would
be very stupid. If you don't know why, it's because you're missing the
point.
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
On Mon, Jul 12, 2010 at 3:35 PM, Marcin Letyns <[email protected]> wrote:
> Last time I tried freebsd it wasn't stable. It had problems with my hard
> drive controler.
This thread needs more anecdotal evidence.
On Mon, 12 Jul 2010 15:42:32 +0300, Alexey Dobriyan said:
> On Mon, Jul 12, 2010 at 3:35 PM, Marcin Letyns <[email protected]> wrote:
> > Last time I tried freebsd it wasn't stable. It had problems with my hard
> > drive controler.
>
> This thread needs more anecdotal evidence.
To be fair, the continual re-appearance of this thread is *always* anecdotal.
It's always somebody who has trouble getting it to work on *their* hardware, or
with *their* software, and insisting that stuff doesn't get shipped unless it
works properly on everything. Apparently, having it work on 99.997% of the
gear out there isn't good enough for them. Then there's the inevitable call
for "no shipping with blocker bugs" - never with a good objective definition of
what constitutes a "blocker" bug.
Ted had it right - you insist on fixing *everything*, you end up with
Debian Obsolete. It's the nature of the beast - you *will* detect regressions
at something resembling an exponential-decay curve. The only question that remains is
how close to zero it has to decay before the ship date - and there's no single
answer for that which fits everybody. One point to note is that if you ship
earlier, the decay rate increases because of wider deployment. As a result,
it's quite probable that you get to some objective level of "stable" faster
by releasing early and then releasing a half-dozen dot releases, instead of
waiting for the 3 or 4 dozen people testing it before release to shake out all
the bugs (which obviously won't happen due to things like access to hardware).