[Ksummit-2013-discuss] When to push bug fixes to mainline

[Ingo Molnar]

* Linus Torvalds <torvalds at linux-foundation.org> wrote:

> [...]
> 
> 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.

The way I typically mark those kinds of fixes is that I don't add a 
stable at vger.kernel.org tag to the commit and wait for explicit complaints 
to come up. I also sometimes remove -stable backport tags from fix 
submissions.

Requests for backports will arrive with a time delay (if at all), which 
gives the perfect opportunity to review its upstream status (whether there 
are followup problems with the patch, etc.) and forward the commit to 
-stable, at which point it's already been upstream for a couple of weeks, 
sometimes months.

I don't think this scenario needs to be or can be automated via a special 
tag: the main problem is that when the fix is applied we rarely know how 
widely users care about it. I think dealing with them 'statistically' 
(i.e. waiting for a backport request) measures that property pretty 
accurately.

The nice thing about it is that it all self-balances if people just add 
-stable backport tags more judiciously.

Thanks,

	Ingo