On Thu 2026-06-25 16:31:47, Bradley Morgan wrote: > On June 25, 2026 4:30:15 PM GMT+01:00, Petr Mladek <[email protected]> > wrote: > >On Wed 2026-06-24 13:34:19, Andrew Morton wrote: > >> On Tue, 23 Jun 2026 15:34:58 +0000 Bradley Morgan <[email protected]> > >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
