On Tue, 23 Jun 2009, Krzysztof Halasa wrote:
>
> I would say, to address regressions and fix bugs. Not only those added
> recently, though obviously older bugs should have already been fixed.
The thing is, I don't take bug fixes late in the -rc just because they are
bug fixes.
And I really shouldn't.
If it's an old bug, and doesn't cause an oops or a security issue, it had
damn well better wait for the next merge window. There is absolutely _no_
reason to just blindly "fix bugs" at the end of the rc stage, because
quite frankly, the risks coming from fixing a bug is often bigger than the
advantage.
Even "obvious bugs" may be things that people depend on, or that other
parts of the kernel simply rely on indirectly. For a recent example of
this, see what happened when we fixed an obvious bug on x86-64 to check
user space addresses properly: it turns out that 'strnlen_user()' depended
on the bug ("misfeature"), and had to be fixed when the bug was fixed.
So no. Regressions really are _different_ from "fixing bugs".
Regressions need to be fixed even if it may even re-introduce another
long-time bug - simply because we're much better off with a _consistent_
set of bugs where people can depend on their machine either working or
not, than with some kind of unstable situation that never gets anywhere
(we found that out the hard way with both ACPI and power management).
So the end result is:
- we always want to fix bugs
- but the primary time to fix bugs is during the merge window
- after the merge window closes, the effort should be on _regressions_,
nothing else.
- security issues and oopses etc catastrophic bugs obviously need to be
handled at any stage.
IOW, "it fixes a bug" is _not_ sufficient. The real issue is "it _really_
can't wait to the next merge window", not "bug or not".
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
