On Tue, Jul 16, 2013 at 11:29:15AM -0700, Linus Torvalds wrote:
> There have been tons of obvious patches that turned out to simply be
> wrong - often for very non-obvious reasons. Even when they are small.
> And the problems seldom get caught in early testing, often exactly
> because of this self-selecting property of testers (and test*ing* -
> when you fix a particular behavior, you tend to test the behavior
> you're trying to fix, you don't test the other cases that the patch
> wasn't about).
I can't agree more, I know it's one of my defaults. I don't count the
number of bugs I have introduced in Haproxy while fixing a bug, and I
know this and care a lot about this. Still shit happens. And I'm sure
I'm not the only one out there !
> Anyway, the point I'm making is that Q&A is limited and often even
> actively misleading ("Hey, I have three tested-by's, so it must be
> fine"), and we might actually want to have a new class of
> "non-critical patch that might be worth backporting to stable, but
> only do so after it's been in a release for some time". Because while
> it might be an "obvious" fix, maybe it's not critical enough that it
> needs to be backported _now_ - maybe it could wait a month or two, and
> get wider testing.
That's what was discussed earlier in this thread, something like not
merging into stable before current kernel is released plus maybe one
.1 stable version to ensure that we've got some bug reports. That
would mean something like "don't backport this before 3.12.1 has
been released" for example. The tag could simply be "Not-Before".
Willy
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html