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

[Thorsten Leemhuis]

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?

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.

>> 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/

Ciao, Thorsten