On Tue, Apr 14, 2020 at 05:38:32PM +0300, Or Gerlitz wrote:
On Tue, Apr 14, 2020 at 2:09 PM Greg KH gregkh@linuxfoundation.org wrote:
On Tue, Apr 14, 2020 at 01:22:59PM +0300, Or Gerlitz wrote:
IMHO - I think it should be the other way around, you should get approval from sub-system maintainers to put their code in charge into auto-selection, unless there's kernel summit decision that says otherwise, is this documented anywhere?
No, we can't get make this a "only take if I agree" as there are _many_ subsystem maintainers who today never mark anything for stable trees, as they just can't be bothered. And that's fine, stable trees should not take up any extra maintainer time if they do not want to do so. So it's simpler to do an opt-out when asked for.
OK, but I must say I am worried from the comment made here:
"I'm not sure what a fixes tag has to do with inclusion in a stable tree"
This patch
(A) was pushed to -next and not -rc kernel
Fixes can (and should) come in during a merge window as well. They are not put on hold until the -rc releases.
(B) doesn't have fixes tag
In the 4.19 stable tree there are 3962 commits explicitly tagged for stable, only 2382 of them have a fixes tag.
(C) the change log state clearly that what's being "fixed" can't be reproduced on any earlier kernel [..] "only possible to reproduce with next commit in this series"
but it was selected for -stable -- at least if the fixes tag was used as gating criteria, this wrong stable inclusion could have been eliminated
Are you suggesting that a commit without a fixes tag is never a fix?