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

[Greg KH <gregkh@linuxfoundation.org>]

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