Re: Please create the email alias do-not-apply-to-stable@xxxxxxxxxx -> /dev/null

[Greg KH]

On Wed, Apr 17, 2024 at 03:21:12PM +0200, Thorsten Leemhuis wrote:
> On 17.04.24 14:52, Konstantin Ryabitsev wrote:
> > On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
> >>
> >> Could you please create the email alias
> >> do-not-apply-to-stable@xxxxxxxxxx which redirects all mail to /dev/null,
> >> just like stable@xxxxxxxxxx does?
> >>
> >> That's an idea GregKH brought up a few days ago here:
> >> https://lore.kernel.org/all/2024041123-earthling-primarily-4656@gregkh/
> >>
> >> To quote:
> >>
> >>> How about:
> >>> 	cc: <do-not-apply-to-stable@xxxxxxxxxx> # Reason goes here, and must be present
> >>>
> >>> and we can make that address be routed to /dev/null just like
> >>> <stable@xxxxxxxxxx> is?
> 
> First, many thx for your feedback.
> 
> > That would make it into actual commits and probably irk maintainers and 
> > Linus, no?
> 
> Yup.
> 
> > I also don't really love the idea of overloading email 
> > addresses with additional semantics. Using Cc: stable kinda makes sense, 
> > even if it's not a real email address (but it could become at some 
> > point), but this feels different.
> 
> Okay.
> 
> > In general, I feel this information belongs in the patch basement (the 
> > place where change-id, base-commit, etc goes). E.g.:
> > 
> >     stable-autosel: ignore
> >     [This fix requires a feature that is only present in mainline]
> > 
> > This allows passing along structured information that can be parsed by 
> > automated tooling without putting it into the commit.
> 
> That afaics makes them useless for the stable team (Greg may correct me
> if I'm wrong here), as they deal with the commits and have no easy,
> fast, and reliable way to look up the patch posting to query this. Or is
> the "patch basement" available somehow in git for each commit and I just
> missed that?

You are correct, as-is, that would make it useless for my tools.

BUT I could, if it's possible, just look up the original in lore somehow
and parse that.  If it's there, does anyone have a "simple" way to map a
git commit back to a lore message if it does NOT have a Link: line in
it?

I guess I should look at setting up a local copy of lei to dig through
the git record of lkml?  But what about patches that aren't cc: to lkml,
I don't want to have to hit lore.kernel.org for each query, that's going
to not be nice.

> Guess in a better world we might use "git notes" for this, but we
> currently do not use them because they iirc are somewhat tricky (they
> are easily lost on rebases iirc is one of the reasons ) -- and starting
> to use them just for this is not worth it.

git notes never works for anything, and everyone always mentions it :)

> >> There was some discussion about using something shorter, but in the end
> >> there was no strong opposition and the thread ended a a few days ago.
> > I feel this is a significant change to the workflow, so I would like the 
> > workflows list to have another go at this topic. :)
> 
> FWIW, we could go back to what I initially proposed: use the existing
> stable tag with a pre-defined comment to mark patches that AUTOSEL et.
> al. should not pick up:
> https://lore.kernel.org/all/c0a08b160b286e8c98549eedb37404c6e784cf8a.1712812895.git.linux@xxxxxxxxxxxxx/

If you can pick a better string, possibly, yes.

But in the end, your proposal seems to imply:

	cc: stable@xxxxxxxxxx	# Psych!  Just kidding, never backport this!

but really, that's just mean, and again, this is a VERY rare case you
are trying to automate here.  We have MUCH better and simpler ways for
maintainers to not have their subsystems scanned for stuff like this,
why are we spending all of our time on this topic?

thanks,

greg k-h