workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thorsten Leemhuis <linux@leemhuis.info>
To: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Cc: helpdesk@kernel.org, Greg KH <gregkh@linuxfoundation.org>,
	"workflows@vger.kernel.org" <workflows@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Please create the email alias do-not-apply-to-stable@kernel.org -> /dev/null
Date: Wed, 17 Apr 2024 15:21:12 +0200	[thread overview]
Message-ID: <e7318984-7ef4-48cd-aae4-1deda3d711a5@leemhuis.info> (raw)
In-Reply-To: <20240417-lively-zebu-of-tact-efc8f3@lemur>

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

  parent reply	other threads:[~2024-04-17 13:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-17  7:48 Thorsten Leemhuis
2024-04-17  7:55 ` Greg KH
2024-04-17  8:09 ` Mauro Carvalho Chehab
2024-04-17  8:16   ` Greg KH
2024-04-17  8:48     ` Willy Tarreau
2024-04-17 17:13       ` Florian Fainelli
2024-04-17 16:56     ` Mauro Carvalho Chehab
2024-04-17 12:52 ` Konstantin Ryabitsev
2024-04-17 13:15   ` Vlastimil Babka
2024-04-17 13:21   ` Thorsten Leemhuis [this message]
2024-04-17 13:25     ` Konstantin Ryabitsev
2024-04-17 13:38     ` Greg KH
2024-04-17 13:55       ` Konstantin Ryabitsev
2024-04-18  7:04       ` Thorsten Leemhuis
2024-04-18 13:20         ` Greg KH
2024-04-22 15:49           ` Thorsten Leemhuis
2024-04-22 19:25             ` Konstantin Ryabitsev
2024-04-22 21:46               ` Mauro Carvalho Chehab
2024-04-22 22:04                 ` Greg KH
2024-04-22 22:15                   ` Mauro Carvalho Chehab
2024-04-23  7:28                     ` Thorsten Leemhuis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e7318984-7ef4-48cd-aae4-1deda3d711a5@leemhuis.info \
    --to=linux@leemhuis.info \
    --cc=gregkh@linuxfoundation.org \
    --cc=helpdesk@kernel.org \
    --cc=konstantin@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=workflows@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox