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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx> escreveu:
> 
> > Hi kernel.org helpdesk!
> > 
> > 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?  
> > 
> > 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




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux