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

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

[Thorsten Leemhuis]

Hi kernel.org helpdesk!

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?

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.

The goal is to have a tag that developers can use in Linux kenrel
commits that have a Fixes: tag, but nevertheless should not be
backported by the stable-team without explicit request. The thread
linked above explains this in more detail. Once the address exists I'll
resubmit the patches in question that will document the tag.

Is asking for this here like this the right way? If I need to file a
ticket somewhere or some ack from a higher authority, just let me know!

Ciao, Thorsten

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

[Greg KH]

On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
> Hi kernel.org helpdesk!
> 
> 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?
> 
> 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.
> 
> The goal is to have a tag that developers can use in Linux kenrel
> commits that have a Fixes: tag, but nevertheless should not be
> backported by the stable-team without explicit request. The thread
> linked above explains this in more detail. Once the address exists I'll
> resubmit the patches in question that will document the tag.
> 
> Is asking for this here like this the right way? If I need to file a
> ticket somewhere or some ack from a higher authority, just let me know!

I approve this message :)

thanks,

greg k-h

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

[Mauro Carvalho Chehab]

Em Wed, 17 Apr 2024 09:48:18 +0200
Thorsten Leemhuis <linux@leemhuis.info> escreveu:

> Hi kernel.org helpdesk!
> 
> 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?  
> 
> 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.

Heh, a shorter name would make it a lot easier to remember, specially
since not wanting a patch to go to stable is an exception... I bet
I'll never remember the right syntax, needing to look at the docs
every time it would be used.

IMO, something like:
	no-stable
or
	nostable

would do the trick and would be a lot easier to remember.

Btw, IMO, it won't hurt accepting more than one variant that
could be allowed, e. g. using a regular expression like:

	(do)?[-_]?(nt|not?).*stable

at the scripts used by stable developers - and maybe at the ML server - to
catch different variations won't hurt, as it sounds likely that people will
end messing up with a big name like "do-not-apply-to-stable", typing
instead things like:

	do_not_apply_to_stable
	dont-apply-to-stable

and other variants.

Just my 2 cents.

Regards,
Mauro

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

[Greg KH]

On Wed, Apr 17, 2024 at 09:09:26AM +0100, Mauro Carvalho Chehab wrote:
> Em Wed, 17 Apr 2024 09:48:18 +0200
> Thorsten Leemhuis <linux@leemhuis.info> escreveu:
> 
> > Hi kernel.org helpdesk!
> > 
> > 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?  
> > 
> > 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.
> 
> Heh, a shorter name would make it a lot easier to remember, specially
> since not wanting a patch to go to stable is an exception... I bet
> I'll never remember the right syntax, needing to look at the docs
> every time it would be used.
> 
> IMO, something like:
> 	no-stable
> or
> 	nostable
> 
> would do the trick and would be a lot easier to remember.
> 
> Btw, IMO, it won't hurt accepting more than one variant that
> could be allowed, e. g. using a regular expression like:
> 
> 	(do)?[-_]?(nt|not?).*stable

That's not going to work at the mailing list server, or with my scripts,
sorry.

> at the scripts used by stable developers - and maybe at the ML server - to
> catch different variations won't hurt, as it sounds likely that people will
> end messing up with a big name like "do-not-apply-to-stable", typing
> instead things like:
> 
> 	do_not_apply_to_stable
> 	dont-apply-to-stable
> 
> and other variants.

I want this very explicit that someone does not want this applied, and
that it has a reason to do so.  And if getting the email right to do so
is the issue with that, that's fine.  This is a very rare case that
almost no one should normally hit.

And again, if maintainers don't want their tree to have Fixes: and
AUTOBOT run on them, we can easily add that to our lists.  That's the
simpler and more explicit thing to do for those that do not want to have
anything backported they do not explicitly mark as such (some subsystems
do this already, like kvm and -mm and xfs, it's fine!).  This all is
here because of maintainers who do NOT want to do that.

thanks,

greg k-h

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

[Willy Tarreau]

On Wed, Apr 17, 2024 at 10:16:26AM +0200, Greg KH wrote:
> > at the scripts used by stable developers - and maybe at the ML server - to
> > catch different variations won't hurt, as it sounds likely that people will
> > end messing up with a big name like "do-not-apply-to-stable", typing
> > instead things like:
> > 
> > 	do_not_apply_to_stable
> > 	dont-apply-to-stable
> > 
> > and other variants.
> 
> I want this very explicit that someone does not want this applied, and
> that it has a reason to do so.  And if getting the email right to do so
> is the issue with that, that's fine.  This is a very rare case that
> almost no one should normally hit.

For using a comparable approach in haproxy on a daily basis, I do see
the value in this. We just mark a lot of fixes "no backport needed" or
"no backport needed unless blablabla" for everything that is only
relevant to the dev tree, and that's a huge time saver for those working
on the backports later.

Maybe "not-for-stable" would be both shorter and easier to remember BTW ?

Regards,
Willy

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

[Florian Fainelli]

On 4/17/24 01:48, Willy Tarreau wrote:
> On Wed, Apr 17, 2024 at 10:16:26AM +0200, Greg KH wrote:
>>> at the scripts used by stable developers - and maybe at the ML server - to
>>> catch different variations won't hurt, as it sounds likely that people will
>>> end messing up with a big name like "do-not-apply-to-stable", typing
>>> instead things like:
>>>
>>> 	do_not_apply_to_stable
>>> 	dont-apply-to-stable
>>>
>>> and other variants.
>>
>> I want this very explicit that someone does not want this applied, and
>> that it has a reason to do so.  And if getting the email right to do so
>> is the issue with that, that's fine.  This is a very rare case that
>> almost no one should normally hit.
> 
> For using a comparable approach in haproxy on a daily basis, I do see
> the value in this. We just mark a lot of fixes "no backport needed" or
> "no backport needed unless blablabla" for everything that is only
> relevant to the dev tree, and that's a huge time saver for those working
> on the backports later.
> 
> Maybe "not-for-stable" would be both shorter and easier to remember BTW ?

Yes, "not-for-stable" looks like a good name to me.
-- 
Florian

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

[Mauro Carvalho Chehab]

Em Wed, 17 Apr 2024 10:16:26 +0200
Greg KH <gregkh@linuxfoundation.org> escreveu:

> On Wed, Apr 17, 2024 at 09:09:26AM +0100, Mauro Carvalho Chehab wrote:
> > Em Wed, 17 Apr 2024 09:48:18 +0200
> > Thorsten Leemhuis <linux@leemhuis.info> escreveu:
> >   
> > > Hi kernel.org helpdesk!
> > > 
> > > 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?    
> > > 
> > > 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.  
> > 
> > Heh, a shorter name would make it a lot easier to remember, specially
> > since not wanting a patch to go to stable is an exception... I bet
> > I'll never remember the right syntax, needing to look at the docs
> > every time it would be used.
> > 
> > IMO, something like:
> > 	no-stable
> > or
> > 	nostable
> > 
> > would do the trick and would be a lot easier to remember.
> > 
> > Btw, IMO, it won't hurt accepting more than one variant that
> > could be allowed, e. g. using a regular expression like:
> > 
> > 	(do)?[-_]?(nt|not?).*stable  
> 
> That's not going to work at the mailing list server, or with my scripts,
> sorry.

A setting like that would likely be at exim (or similar). Most smtp servers
allow some sort of wildcards, as those are used to pass or not e-mails to
list servers and/or handle custom mail forward rules.

At client level, one could use dovecot with pigeonhole to have sieve
rules to filter e-mails. That's what I do here.
 
> > at the scripts used by stable developers - and maybe at the ML server - to
> > catch different variations won't hurt, as it sounds likely that people will
> > end messing up with a big name like "do-not-apply-to-stable", typing
> > instead things like:
> > 
> > 	do_not_apply_to_stable
> > 	dont-apply-to-stable
> > 
> > and other variants.  
> 
> I want this very explicit that someone does not want this applied, and
> that it has a reason to do so.  And if getting the email right to do so
> is the issue with that, that's fine.  This is a very rare case that
> almost no one should normally hit.

Yeah, agreed: those are very rare exceptions. I remember just one or 
two cases where a media fix patch couldn't be queued to stable. 
The already-existing workflow worked for those.

> And again, if maintainers don't want their tree to have Fixes: and
> AUTOBOT run on them, we can easily add that to our lists.  That's the
> simpler and more explicit thing to do for those that do not want to have
> anything backported they do not explicitly mark as such (some subsystems
> do this already, like kvm and -mm and xfs, it's fine!).  This all is
> here because of maintainers who do NOT want to do that.

From my side, I'm fine with whatever-explicit-long-filter-email.

Regards,
Mauro

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

[Konstantin Ryabitsev]

On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
> Hi kernel.org helpdesk!
> 
> 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?

That would make it into actual commits and probably irk maintainers and 
Linus, no? 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.

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.

> 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. :)

-K

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

[Vlastimil Babka]

On 4/17/24 2:52 PM, Konstantin Ryabitsev wrote:
> On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
>> Hi kernel.org helpdesk!
>> 
>> 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?
> 
> That would make it into actual commits and probably irk maintainers and 
> Linus, no? 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.
> 
> 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.

But isn't it the actual commit what the stable tooling parses?

>> 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. :)
> 
> -K
> 

Re: Please create the email alias do-not-apply-to-stable@kernel.org -> /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@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

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

[Konstantin Ryabitsev]

On Wed, Apr 17, 2024 at 03:21:12PM +0200, Thorsten Leemhuis wrote:
> > 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?

Ah, okay, my assumption was wrong, then.

How about meeting things halfway, then:

    Cc: stable+noautosel@kernel.org # Reason

-K

Re: Please create the email alias do-not-apply-to-stable@kernel.org -> /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@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?

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@leemhuis.info/

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

But in the end, your proposal seems to imply:

	cc: stable@kernel.org	# 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

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

[Konstantin Ryabitsev]

On Wed, Apr 17, 2024 at 03:38:28PM +0200, Greg KH wrote:
> > 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?

Our current way of doing it is going by patch-id, and it's not great 
either, because there is more than one way to create a patch from a git 
commit. We've discovered this when Linus recommended that people send 
patches with the --histogram algorithm, which broke a bunch of our 
stuff. :)

E.g. here's a recent commit that has a Fixes:

  git show c0297e7dd50795d559f3534887a6de1756b35d0f | git patch-id --stable | cut -d' ' -f1
  c2f5c42a5a3bc05ffacd9679dd367e4a2207b018

it successfully maps to the patch:
https://lore.kernel.org/all/?q=patchid%3Ac2f5c42a5a3bc05ffacd9679dd367e4a2207b018

I only put this here for academic purposes -- I really don't want you to 
go that route, because it's fragile (more fragile than git notes, and 
that's saying something).

-K

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

[Thorsten Leemhuis]

On 17.04.24 15:38, Greg KH wrote:
> 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@kernel.org which redirects all mail to /dev/null,
>>>> just like stable@kernel.org does?
>>>>
>>>> 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?
>>
>> 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/
> 
> If you can pick a better string, possibly, yes.

What did you think of Konstantin's

Cc: stable+noautosel@kernel.org # Reason

That looked like a good solution -- and I wondered why I did not come up
with that idea myself. Sure, "autosel" would also imply/mean "the
scripts/tools that look out for Fixes: tags", but does that matter?

> But in the end, your proposal seems to imply:
> 
> 	cc: stable@kernel.org	# 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?

It started with various minor reasons -- and after some "this would be
nice to have" feedback it felt wrong to give up. It also looked like we
had some agreement already before a new discussion began.

Ciao, Thorsten

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

[Greg KH]

On Thu, Apr 18, 2024 at 09:04:53AM +0200, Thorsten Leemhuis wrote:
> On 17.04.24 15:38, Greg KH wrote:
> > 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@kernel.org which redirects all mail to /dev/null,
> >>>> just like stable@kernel.org does?
> >>>>
> >>>> 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?
> >>
> >> 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/
> > 
> > If you can pick a better string, possibly, yes.
> 
> What did you think of Konstantin's
> 
> Cc: stable+noautosel@kernel.org # Reason
> 
> That looked like a good solution -- and I wondered why I did not come up
> with that idea myself. Sure, "autosel" would also imply/mean "the
> scripts/tools that look out for Fixes: tags", but does that matter?

We can live with this, sure.  That way no need to change anything on any
kernel.org backend.

thanks,

greg k-h

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

[Thorsten Leemhuis]

[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]

[CCing Sasha]

On 18.04.24 15:20, Greg KH wrote:
> On Thu, Apr 18, 2024 at 09:04:53AM +0200, Thorsten Leemhuis wrote:
>> On 17.04.24 15:38, Greg KH wrote:
>>> 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
>>>>>>
>>>>>>> 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?
>>>>
>>>> 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/
>>>
>>> If you can pick a better string, possibly, yes.
>>
>> What did you think of Konstantin's
>>
>> Cc: stable+noautosel@kernel.org # Reason

@Greg, BTW: should this be stable+noautosel@kernel.org or have a 'vger.'
in it, e.g. stable+noautosel@vger.kernel.org? I assume without 'vger.'
is fine, just wanted to be sure, as
Documentation/process/stable-kernel-rules.rst in all other cases
specifies stable@vger.kernel.org, so people are likely to get confused.
:-/ #sigh

>> That looked like a good solution -- and I wondered why I did not come up
>> with that idea myself. Sure, "autosel" would also imply/mean "the
>> scripts/tools that look out for Fixes: tags", but does that matter?
> 
> We can live with this, sure. 

In that case I guess I now also have to fix the scripts to honor that tag.

@Greg: something like the attached for scripts/fixes_search perhaps? Was
that the right one and are there any other scripts that might need
something similar?

@Sasha: are the scripts around autosel online somewhere? They need a
similar change.

Ciao, Thorsten

[-- Attachment #2: 0001-scripts-fixes_search-honor-noautosel-tag.patch --]
[-- Type: text/x-patch, Size: 1326 bytes --]

From 1e973a069b07f8c045401a7d3d20ea760a27422f Mon Sep 17 00:00:00 2001
From: Thorsten Leemhuis <linux@leemhuis.info>
Date: Mon, 22 Apr 2024 17:31:01 +0200
Subject: [PATCH] scripts/fixes_search: honor noautosel tag

Ignore commits that contain a soon to be documented tag that is
meant to exclude commits from processing by scripts like
scripts/fixes_search.

Link: https://lore.kernel.org/all/2024041830-karaoke-aspirate-df00@gregkh/ [1]
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
 scripts/fixes_search | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/scripts/fixes_search b/scripts/fixes_search
index aaa12ec..950509f 100755
--- a/scripts/fixes_search
+++ b/scripts/fixes_search
@@ -131,6 +131,13 @@ for commit in $(git rev-list --reverse --no-merges "${git_range}"); do
 	# logn "commit = ${txtgrn}${commit}${txtrst}	"
 	logn "${txtgrn}${commit}${txtrst}	"
 
+	# Check if we are supposed to ignore the commit
+	no_autosel=$(git log -1 --format='%B' "HEAD" | grep -i '^[[:space:]]*[Cc][Cc]:[[:space:]]*<stable+noautosel@')
+	if [ "${no_autosel}" ] ; then
+		log "${txtblu}contains noautosel tag${txtrst}"
+		continue
+	fi
+
 	# Try to find "Fixes" tag in commit
 	fixes_lines=$(git log -1 --format='%B' "${commit}" | grep -i '^[[:space:]]*Fixes:')
 	if [ "${fixes_lines}" == "" ] ; then
-- 
2.44.0

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

[Konstantin Ryabitsev]

On Mon, Apr 22, 2024 at 05:49:29PM +0200, Thorsten Leemhuis wrote:
> @Greg, BTW: should this be stable+noautosel@kernel.org or have a 
> 'vger.'

No vger, just stable+whatever@kernel.org.

> in it, e.g. stable+noautosel@vger.kernel.org? I assume without 'vger.'
> is fine, just wanted to be sure, as
> Documentation/process/stable-kernel-rules.rst in all other cases
> specifies stable@vger.kernel.org, so people are likely to get confused.
> :-/ #sigh

These serve two different purposes:

stable@kernel.org (goes into devnull)
stable@vger.kernel.org (actual mailing list)

Confusion happens all the time, unfortunately.

Notably, even if someone uses stable+noautosel@vger.kernel.org, it won't 
do anything terrible (it won't bounce, it'll just quietly go into 
nowhere because that's not a valid expansion command).

-K

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

[Mauro Carvalho Chehab]

Em Mon, 22 Apr 2024 15:25:18 -0400
Konstantin Ryabitsev <konstantin@linuxfoundation.org> escreveu:

> On Mon, Apr 22, 2024 at 05:49:29PM +0200, Thorsten Leemhuis wrote:
> > @Greg, BTW: should this be stable+noautosel@kernel.org or have a 
> > 'vger.'  
> 
> No vger, just stable+whatever@kernel.org.
> 
> > in it, e.g. stable+noautosel@vger.kernel.org? I assume without 'vger.'
> > is fine, just wanted to be sure, as
> > Documentation/process/stable-kernel-rules.rst in all other cases
> > specifies stable@vger.kernel.org, so people are likely to get confused.
> > :-/ #sigh  
> 
> These serve two different purposes:
> 
> stable@kernel.org (goes into devnull)
> stable@vger.kernel.org (actual mailing list)
> 
> Confusion happens all the time, unfortunately.

Yeah, I did already used stable@kernel.org a few times in the
past. 

IMO, the best would be either for stable to also accept it or for
kernel.org mail server to return an error message (only to the
submitter) warning about the invalid address, eventually with a
hint message pointing to the correct value.

> 
> Notably, even if someone uses stable+noautosel@vger.kernel.org, it won't 
> do anything terrible (it won't bounce, it'll just quietly go into 
> nowhere because that's not a valid expansion command).
> 
> -K
> 

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

[Greg KH]

On Mon, Apr 22, 2024 at 10:46:37PM +0100, Mauro Carvalho Chehab wrote:
> Em Mon, 22 Apr 2024 15:25:18 -0400
> Konstantin Ryabitsev <konstantin@linuxfoundation.org> escreveu:
> 
> > On Mon, Apr 22, 2024 at 05:49:29PM +0200, Thorsten Leemhuis wrote:
> > > @Greg, BTW: should this be stable+noautosel@kernel.org or have a 
> > > 'vger.'  
> > 
> > No vger, just stable+whatever@kernel.org.
> > 
> > > in it, e.g. stable+noautosel@vger.kernel.org? I assume without 'vger.'
> > > is fine, just wanted to be sure, as
> > > Documentation/process/stable-kernel-rules.rst in all other cases
> > > specifies stable@vger.kernel.org, so people are likely to get confused.
> > > :-/ #sigh  
> > 
> > These serve two different purposes:
> > 
> > stable@kernel.org (goes into devnull)
> > stable@vger.kernel.org (actual mailing list)
> > 
> > Confusion happens all the time, unfortunately.
> 
> Yeah, I did already used stable@kernel.org a few times in the
> past. 
> 
> IMO, the best would be either for stable to also accept it or for
> kernel.org mail server to return an error message (only to the
> submitter) warning about the invalid address, eventually with a
> hint message pointing to the correct value.

stable@kernel.org is there to route to /dev/null on purpose so that
developers/maintainers who only want their patches to get picked up when
they hit Linus's tree, will have happen and not notify anyone else.
This is especially good when dealing with security-related things as we
have had MANY people accidentally leak patches way too early by having
 cc: stable@vger.kernel.org in their signed-off-by areas, and forgetting
to tell git send-email to suppress cc: when sending them out for
internal review.

Having that bounce would just be noisy for the developers involved.

thanks,

greg k-h

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

[Mauro Carvalho Chehab]

Em Tue, 23 Apr 2024 00:04:01 +0200
Greg KH <gregkh@linuxfoundation.org> escreveu:

> On Mon, Apr 22, 2024 at 10:46:37PM +0100, Mauro Carvalho Chehab wrote:
> > Em Mon, 22 Apr 2024 15:25:18 -0400
> > Konstantin Ryabitsev <konstantin@linuxfoundation.org> escreveu:
> >   
> > > On Mon, Apr 22, 2024 at 05:49:29PM +0200, Thorsten Leemhuis wrote:  
> > > > @Greg, BTW: should this be stable+noautosel@kernel.org or have a 
> > > > 'vger.'    
> > > 
> > > No vger, just stable+whatever@kernel.org.
> > >   
> > > > in it, e.g. stable+noautosel@vger.kernel.org? I assume without 'vger.'
> > > > is fine, just wanted to be sure, as
> > > > Documentation/process/stable-kernel-rules.rst in all other cases
> > > > specifies stable@vger.kernel.org, so people are likely to get confused.
> > > > :-/ #sigh    
> > > 
> > > These serve two different purposes:
> > > 
> > > stable@kernel.org (goes into devnull)
> > > stable@vger.kernel.org (actual mailing list)
> > > 
> > > Confusion happens all the time, unfortunately.  
> > 
> > Yeah, I did already used stable@kernel.org a few times in the
> > past. 
> > 
> > IMO, the best would be either for stable to also accept it or for
> > kernel.org mail server to return an error message (only to the
> > submitter) warning about the invalid address, eventually with a
> > hint message pointing to the correct value.  
> 
> stable@kernel.org is there to route to /dev/null on purpose so that
> developers/maintainers who only want their patches to get picked up when
> they hit Linus's tree, will have happen and not notify anyone else.
> This is especially good when dealing with security-related things as we
> have had MANY people accidentally leak patches way too early by having
>  cc: stable@vger.kernel.org in their signed-off-by areas, and forgetting
> to tell git send-email to suppress cc: when sending them out for
> internal review.

Nice! didn't know about that. On a quick check, the only place at
documentation mentioning it without vger is at checkpatch.rst.

Perhaps it would make sense to document that as well.

> Having that bounce would just be noisy for the developers involved.
> 
> thanks,
> 
> greg k-h

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

[Thorsten Leemhuis]

On 23.04.24 00:15, Mauro Carvalho Chehab wrote:
>> stable@kernel.org is there to route to /dev/null on purpose so that
>> developers/maintainers who only want their patches to get picked up when
>> they hit Linus's tree, will have happen and not notify anyone else.
>> This is especially good when dealing with security-related things as we
>> have had MANY people accidentally leak patches way too early by having
>>  cc: stable@vger.kernel.org in their signed-off-by areas, and forgetting
>> to tell git send-email to suppress cc: when sending them out for
>> internal review.
> Nice! didn't know about that. On a quick check, the only place at
> documentation mentioning it without vger is at checkpatch.rst.
> 
> Perhaps it would make sense to document that as well.

Maybe something like the below?

Will add that to my next patch set unless I hear complaints. 

Ciao, Thorsten

---

diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
index 727ad7f758e3e0..5a47ed06081e41 100644
--- a/Documentation/process/stable-kernel-rules.rst
+++ b/Documentation/process/stable-kernel-rules.rst
@@ -72,6 +72,10 @@ for stable trees, add this tag in the sign-off area::
 
      Cc: stable@vger.kernel.org
 
+Use ``Cc: stable@kernel.org`` instead when fixing an unpublished vulnerability:
+it reduces the chance of someone exposing the fix to the public by way of
+'git send-email', as mails sent to that address are not delivered anywhere.
+
 Once the patch is mainlined it will be applied to the stable tree without
 anything else needing to be done by the author or subsystem maintainer.