> > It seems like this can all be avoided simply by scheduling the
> > automated fixes scans once the upstream kernel is released, not
> > while it is still being stabilised by -rc releases. That way stable
> > kernels get better tested fixes, they still get the same quantity of
> > fixes, and upstream developers have some margin to detect and
> > correct regressions in fixes before they get propagated to users.
>
> So the "magic" -final release from Linus would cause this to happen?
> That means that the world would go for 3 months without some known fixes
> being applied to the tree? That's not acceptable to me, as I started
> doing this because it was needed to be done, not just because I wanted
> to do more work...
>
Nobody was trying to undermine the need for expediting important fixes
into stable kernels. Quite the contrary.
> > It also creates a clear demarcation between fixes and cc: stable for
> > maintainers and developers: only patches with a cc: stable will be
> > backported immediately to stable. Developers know what patches need
> > urgent backports and, unlike developers, the automated fixes scan
> > does not have the subject matter expertise or background to make
> > that judgement....
>
> Some subsystems do not have such clear demarcation at all. Heck, some
> subsystems don't even add a cc: stable to known major fixes. And that's
> ok, the goal of the stable kernel work is to NOT impose additional work
> on developers or maintainers if they don't want to do that work.
>
Greg,
Please acknowledge that there is something to improve.
Saying that some subsystems maintainers don't care is not a great
argument for subsystem maintainers that do care and try to improve the process.
I am speaking here both as a maintainer of a downstream stable kernel,
who cares specifically about xfs fixes and as an upstream developer who
"contributes" patches to stable kernels. And I am not a passive contributor
to stable kernels. I try to take good care of overlayfs and fsnotify patches
being properly routed to stable kernels, as well as prepping the patches
for backport-ability during review and occasional backporting.
I also try to help with auditing the AUTOSEL patch selection of xfs.
The process can improve. This is an indisputable fact, because as contributors
we want to improve the quality of the stable kernels but missing the
tools to do so.
As a downstream user of stable kernels I learned to wait out a few .y releases
after xfs fixes have flowed in. This is possible because xfs stable
fixes are not
flowing that often.
Do you see what happened? You did not make the problem go away, but pushed
it down to your downstream users.
I would not have complained unless I thought that we could do better.
Here is a recent example, where during patch review, I requested NOT to include
any stable backport triggers [1]:
"...We should consider sending this to stable, but maybe let's merge
first and let it
run in master for a while before because it is not a clear and
immediate danger..."
This is just one patch and I put a mental trigger to myself to stop it
during stable
patch review if it gets selected, but you can see how this solution
does not scale.
As a developer and as a reviewer, I wish (as Dave implied) that I had a way to
communicate to AUTOSEL that auto backport of this patch has more risk than
the risk of not backporting. I could also use a way to communicate
that this patch
(although may fix a bug) should be "treated as a feature", meaning that it needs
a full release cycle to stabilize should not see the light of day
before the upstream
.0 release. Some fixes are just like that.
The question is how to annotate these changes.
Thinking out loud:
Cc: stable@xxxxxxxxxxxxxxx#v5.9<<v5.10
Cc: stable@xxxxxxxxxxxxxxx#v5.9<<v5.10-rc5
For patches that need to soak a few cycles in master or need to linger in
master until the .0 release.
Thanks,
Amir.
[1] https://lore.kernel.org/linux-unionfs/CAOQ4uxiUTsXEdQsE275qxTh61tZOB+-wqCp6gaNLkOw5ueUJgw@xxxxxxxxxxxxxx/
