linux-kernel - Re: Please create the email alias do-not-apply-to-stable@...nel.org -> /dev/null

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e7318984-7ef4-48cd-aae4-1deda3d711a5@leemhuis.info>
Date: Wed, 17 Apr 2024 15:21:12 +0200
From: Thorsten Leemhuis <linux@...mhuis.info>
To: Konstantin Ryabitsev <konstantin@...uxfoundation.org>
Cc: helpdesk@...nel.org, Greg KH <gregkh@...uxfoundation.org>,
 "workflows@...r.kernel.org" <workflows@...r.kernel.org>,
 LKML <linux-kernel@...r.kernel.org>
Subject: Re: Please create the email alias do-not-apply-to-stable@...nel.org
 -> /dev/null

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@...nel.org which redirects all mail to /dev/null,
>> just like stable@...nel.org 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@...nel.org> # Reason goes here, and must be present
>>>
>>> and we can make that address be routed to /dev/null just like
>>> <stable@...nel.org> 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@leemhuis.info/

Ciao, Thorsten