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

[Thorsten Leemhuis <linux@leemhuis.info>]

On 13.06.24 11:59, Jan Kara wrote:
> On Thu 13-06-24 10:42:01, Thorsten Leemhuis 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".
>> Sometimes I wonder if a dedicated tag linking to the submission of a
>> patch could help -- and is something quite a few maintainers already
>> really want and add using a "Link" tag despite Linus dislike for that
>> (IIRC).
> 
> FWIW I (and a few other maintainers) use 'Message-Id' tag to link to
> submission. This is still easily convertible to lore link and unlike 'Link'
> tag it is clear what this tag is about and that it is not just a link to
> related discussion or something like that. AFAIK this also addresses Linus'
> dislike because what he was complaining about is that 'Link' should be
> linking to some useful context for the changelog, not just patch
> submission.

Well, I fine with me. But at the same time this makes me wonder: if we
want to establish a new tag, why not just use something that makes it
more obvious what the tag is about (e.g. "Review:", "Posting:",
"Submission:", or something like that) and then just use a lore link for
consistency, as we deal with those already all the time? Also makes it
easier to follow later for anyone that looks closer at the commit and
wants the bigger picture (e.g. cover letter and a list of related patches).

>> But following that link for each and every patch slated for
>> backporting does not scale for the stable team anyway, so it's likely
>> not worth it.
> 
> Well, what I'd propose is that if 'Message-Id' tag is present and thus it
> can be established (in an automated way using lore) which series this patch
> was part of, then stable maintainers will either pick all patches from the
> start of the series upto this change or nothing.

+1 (and this obviously could work about the same if it was a proper link)

> Because what I see
> happening several times in a year just in subsystems I maintain is that
> stable tree picks up more or less random subset of a patch series
> (depending on what applies and what their algorithms decide to take) and
> that causes issues. Sometimes we catch that during glancing over patches
> flowing into stable (like Amir did last week) but sometimes we don't and
> breakage happens.
> 
> This will require a bit more discipline when creating patch series to put
> more or less independent fixes that should go into stable first but that is
> a good practice anyway and mostly followed at least in the areas of the
> kernel I work in.

+1

Ciao, Thorsten