Em Wed, 17 Apr 2024 10:16:26 +0200 Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> 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@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. 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
