Re: [PATCH v3.1415] Documentation: add documentation summary forrc-series and merge window

[Linus Torvalds]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/