Re: Fixed tag magic: was: Re: [PATCH v2 1/4] sys_info: add helper for callers that handle all_bt

[Petr Mladek]

On Thu 2026-06-25 16:31:47, Bradley Morgan wrote:
> On June 25, 2026 4:30:15 PM GMT+01:00, Petr Mladek <pmladek@xxxxxxxx>
> wrote:
> >On Wed 2026-06-24 13:34:19, Andrew Morton wrote:
> >> On Tue, 23 Jun 2026 15:34:58 +0000 Bradley Morgan <include@xxxxxxxxx>
> >wrote:
> >> 
> >> > Some callers handle SYS_INFO_ALL_BT themselves before calling
> >sys_info().
> >> > Add a helper that strips that bit without turning an all_bt only mask
> >into
> >> > a kernel_sys_info fallback.
> >> 
> >> I assume this patch wants a Fixes: and a cc:stable also.
> >> 
> >> It would be nice to have the conventional [0/N] cover letter to tell
> >> readers what this is all about.
> >> 
> >> The patches all have different Fixes: targets.  This risks inviting the
> >> -stable maintainers to merge only some of the patches into some
> >> kernels, resulting in an untested combination and which might break
> >> things.
> >
> >I do not agree here. The Fixes tag should should point to a commit
> >which introduced the regression into the given code. And finding
> >some magic common point beause there is some magic undocumented
> >process for maintaining stable kernels sounds like a way to hell
> >to me.
> >
> >Best Regards,
> >Petr
> 
> 
> oh no.
> I added the generic tag to V4, no worries, it is the earliest possible
> fixes tag. But I really don't wanna be doing a V5 just to revert my
> fixes tags.

This is the risk when sending 4 versions of a fix within 5 days.
A good practice is to wait at least one week before sending another
version. It gives people chance to react and helps the discussion
to settle.

That said, I am not going to block this because of the fixes tags.
But I suggest to wait longer next time.

Best Regards,
Petr