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@xxxxxxxxxxxxxxxxxxx> 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?
--
Thanks,
Sasha
