On 5/23/07, Henrique de Moraes Holschuh <[email protected]> wrote:
On Wed, 23 May 2007, Ray Lee wrote:
> Which is the crux of my problem with your statement. I feel we
> shouldn't give the wrong idea to those authors. They need to know that
> the expectation is that 2.6.x is a stable series, and 2.6.x.y is for
> dealing with unavoidable mistakes.
Well, the only case where I feel a regression is justified is one where it
is caused by a bug in the firmware or the hardware.
Here's the problem. Each of the people testing the kernel is a 'canary
in the coalmine.' If one person is having trouble, then it's likely
that there are ten more that will have the same issue. The real
problem here is that those other ten people aren't going to know how
to fix it, other than "it used to work, so obviously the kernel is now
doing something wrong."
This is particularly bad for firmware, where upgrading it may
introduce new regressions. I understand that there are broken
firmwares out there -- I have a laptop with one. But there needs to
be a way to support broken systems and the sane ones simultaneously.
This is a requirement for the ACPI tree, for example, and it seems to
work.
All of this is assuming that the firmware really was at fault. It's
also possible that it's just doing something different than before,
and both behaviors are valid and should be dealt with gracefully.
At which point my personal opinion is that users of firmware/hardware *that
have a fix available* are to be told to apply the fix, unless the problem is
so serious that it could potentially cause extreme damage (loss of human
life, permanent hardware damage, major data loss).
Those are extreme. My point is that if you know who all those people
are, and are willing to contact them, then sure, that's viable.
Otherwise, the bottom line is that the kernel used to deal with a
problem gracefully, and now it doesn't. There's no telling how many
other people will get bit by the same problem, and most of those
people aren't going to know what to do about it, other than to
downgrade the kernel, and wait for it to magically get fixed by
someone else.
If there is no fix the user can apply, then it really depends on how
damaging it is to work around the issue for others: you don't punish those
who have non-broken stuff to avoid problems for those that have broken
stuff.
I understand your point of view, but another way to look at it is that
we always want to make forward progress on the code. If we don't, then
we're never going to have a good metric (measure) of how we're doing.
Fortunately, most of the time one can come up with a fix that causes little
to no loss to those with non-broken hardware/firmware.
And I'm sure those with the Big Brains(tm) can do so again.
Thanks,
Ray
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
