* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx 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
--
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