Re: [MAINTAINERS SUMMIT] [4/4] Discuss how to better prevent backports of commits that turn out to cause regressions

[Sasha Levin <sashal@kernel.org>]

On Fri, Jun 14, 2024 at 05:03:17PM +0200, Rafael J. Wysocki wrote:
>On Fri, Jun 14, 2024 at 4:42 PM Jan Kara <jack@suse.cz> wrote:
>>
>> On Thu 13-06-24 14:14:47, Sasha Levin wrote:
>> > On Thu, Jun 13, 2024 at 04:28:47PM +0200, Andrew Lunn wrote:
>> > > > * One cause of regressions that happen in stable trees (and not in
>> > > > mainline) I've seen quite a few times are backports of commits with
>> > > > Fixes: tags that were part of a patch-series and depend on earlier
>> > > > patches from the series. The stable-team afaics has no easy way to spot
>> > > > this, as there is no way to check "was this change part of a series".
>> > >
>> > > This sounds like a tooling issue. git send-email knows a patch is part
>> > > of a patch series. Maybe it should be adding some sort of cross
>> > > reference between patches in a patch series.
>> >
>> > This came up in the past, and we have some machinery to check if a
>> > commit is part of a series or not, but in practice most of the series we
>> > see are actually not ones where patches depend on each other.
>>
>> I'm not sure I understand. Do you say most of the fixes you apply are
>> from single-patch series? Or if the series has multiple patches, how do you
>> decide whether some patch depends on other ones in the series or not?
>> Because judging that sometimes requires rather detailed knowledge of the
>> involved subsystem...
>
>Well, not always.  If the series is of the "clean up this same thing
>all over the place" type, you can easily say that there are no
>dependencies between patches in it.

Few subsystems also use good old patchbombs instead of pull requests,
which leads to patches being part of those series without actually
having anything to do with eachother.

I guess my point is that it's not as simple as looking whether a commit
is in a series or not.

-- 
Thanks,
Sasha