On 5/23/07, Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> 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-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
