Hi kernel.org helpdesk!
Could you please create the email alias
[email protected] which redirects all mail to /dev/null,
just like [email protected] 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: <[email protected]> # Reason goes here, and must be present
>
> and we can make that address be routed to /dev/null just like
> <[email protected]> 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
On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
> Hi kernel.org helpdesk!
>
> Could you please create the email alias
> [email protected] which redirects all mail to /dev/null,
> just like [email protected] 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: <[email protected]> # Reason goes here, and must be present
> >
> > and we can make that address be routed to /dev/null just like
> > <[email protected]> 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
Em Wed, 17 Apr 2024 09:48:18 +0200
Thorsten Leemhuis <[email protected]> escreveu:
> Hi kernel.org helpdesk!
>
> Could you please create the email alias
> [email protected] which redirects all mail to /dev/null,
> just like [email protected] 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: <[email protected]> # Reason goes here, and must be present
> >
> > and we can make that address be routed to /dev/null just like
> > <[email protected]> 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
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 <[email protected]> escreveu:
>
> > Hi kernel.org helpdesk!
> >
> > Could you please create the email alias
> > [email protected] which redirects all mail to /dev/null,
> > just like [email protected] 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: <[email protected]> # Reason goes here, and must be present
> > >
> > > and we can make that address be routed to /dev/null just like
> > > <[email protected]> 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
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
On Wed, Apr 17, 2024 at 09:48:18AM +0200, Thorsten Leemhuis wrote:
> Hi kernel.org helpdesk!
>
> Could you please create the email alias
> [email protected] which redirects all mail to /dev/null,
> just like [email protected] 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: <[email protected]> # Reason goes here, and must be present
> >
> > and we can make that address be routed to /dev/null just like
> > <[email protected]> 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
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
>> [email protected] which redirects all mail to /dev/null,
>> just like [email protected] 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: <[email protected]> # Reason goes here, and must be present
>> >
>> > and we can make that address be routed to /dev/null just like
>> > <[email protected]> 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
>
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: [email protected] # Reason
-K
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
>> [email protected] which redirects all mail to /dev/null,
>> just like [email protected] 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: <[email protected]> # Reason goes here, and must be present
>>>
>>> and we can make that address be routed to /dev/null just like
>>> <[email protected]> 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
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
> >> [email protected] which redirects all mail to /dev/null,
> >> just like [email protected] 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: <[email protected]> # Reason goes here, and must be present
> >>>
> >>> and we can make that address be routed to /dev/null just like
> >>> <[email protected]> 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: [email protected] # 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
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
Em Wed, 17 Apr 2024 10:16:26 +0200
Greg KH <[email protected]> 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 <[email protected]> escreveu:
> >
> > > Hi kernel.org helpdesk!
> > >
> > > Could you please create the email alias
> > > [email protected] which redirects all mail to /dev/null,
> > > just like [email protected] 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: <[email protected]> # Reason goes here, and must be present
> > > >
> > > > and we can make that address be routed to /dev/null just like
> > > > <[email protected]> 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
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
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
>>>> [email protected] which redirects all mail to /dev/null,
>>>> just like [email protected] does?
>>>>
>>>> To quote:
>>>>
>>>>> How about:
>>>>> cc: <[email protected]> # Reason goes here, and must be present
>>>>>
>>>>> and we can make that address be routed to /dev/null just like
>>>>> <[email protected]> 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: [email protected] # 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: [email protected] # 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
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
> >>>> [email protected] which redirects all mail to /dev/null,
> >>>> just like [email protected] does?
> >>>>
> >>>> To quote:
> >>>>
> >>>>> How about:
> >>>>> cc: <[email protected]> # Reason goes here, and must be present
> >>>>>
> >>>>> and we can make that address be routed to /dev/null just like
> >>>>> <[email protected]> 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: [email protected] # 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
[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: <[email protected]> # Reason goes here, and must be present
>>>>>>>
>>>>>>> and we can make that address be routed to /dev/null just like
>>>>>>> <[email protected]> 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: [email protected] # Reason
@Greg, BTW: should this be [email protected] or have a 'vger.'
in it, e.g. [email protected]? I assume without 'vger.'
is fine, just wanted to be sure, as
Documentation/process/stable-kernel-rules.rst in all other cases
specifies [email protected], 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
On Mon, Apr 22, 2024 at 05:49:29PM +0200, Thorsten Leemhuis wrote:
> @Greg, BTW: should this be [email protected] or have a
> 'vger.'
No vger, just [email protected].
> in it, e.g. [email protected]? I assume without 'vger.'
> is fine, just wanted to be sure, as
> Documentation/process/stable-kernel-rules.rst in all other cases
> specifies [email protected], so people are likely to get confused.
> :-/ #sigh
These serve two different purposes:
[email protected] (goes into devnull)
[email protected] (actual mailing list)
Confusion happens all the time, unfortunately.
Notably, even if someone uses [email protected], 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
Em Mon, 22 Apr 2024 15:25:18 -0400
Konstantin Ryabitsev <[email protected]> escreveu:
> On Mon, Apr 22, 2024 at 05:49:29PM +0200, Thorsten Leemhuis wrote:
> > @Greg, BTW: should this be [email protected] or have a
> > 'vger.'
>
> No vger, just [email protected].
>
> > in it, e.g. [email protected]? I assume without 'vger.'
> > is fine, just wanted to be sure, as
> > Documentation/process/stable-kernel-rules.rst in all other cases
> > specifies [email protected], so people are likely to get confused.
> > :-/ #sigh
>
> These serve two different purposes:
>
> [email protected] (goes into devnull)
> [email protected] (actual mailing list)
>
> Confusion happens all the time, unfortunately.
Yeah, I did already used [email protected] 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 [email protected], 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
>
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 <[email protected]> escreveu:
>
> > On Mon, Apr 22, 2024 at 05:49:29PM +0200, Thorsten Leemhuis wrote:
> > > @Greg, BTW: should this be [email protected] or have a
> > > 'vger.'
> >
> > No vger, just [email protected].
> >
> > > in it, e.g. [email protected]? I assume without 'vger.'
> > > is fine, just wanted to be sure, as
> > > Documentation/process/stable-kernel-rules.rst in all other cases
> > > specifies [email protected], so people are likely to get confused.
> > > :-/ #sigh
> >
> > These serve two different purposes:
> >
> > [email protected] (goes into devnull)
> > [email protected] (actual mailing list)
> >
> > Confusion happens all the time, unfortunately.
>
> Yeah, I did already used [email protected] 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.
[email protected] 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: [email protected] 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
Em Tue, 23 Apr 2024 00:04:01 +0200
Greg KH <[email protected]> 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 <[email protected]> escreveu:
> >
> > > On Mon, Apr 22, 2024 at 05:49:29PM +0200, Thorsten Leemhuis wrote:
> > > > @Greg, BTW: should this be [email protected] or have a
> > > > 'vger.'
> > >
> > > No vger, just [email protected].
> > >
> > > > in it, e.g. [email protected]? I assume without 'vger.'
> > > > is fine, just wanted to be sure, as
> > > > Documentation/process/stable-kernel-rules.rst in all other cases
> > > > specifies [email protected], so people are likely to get confused.
> > > > :-/ #sigh
> > >
> > > These serve two different purposes:
> > >
> > > [email protected] (goes into devnull)
> > > [email protected] (actual mailing list)
> > >
> > > Confusion happens all the time, unfortunately.
> >
> > Yeah, I did already used [email protected] 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.
>
> [email protected] 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: [email protected] 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
On 23.04.24 00:15, Mauro Carvalho Chehab wrote:
>> [email protected] 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: [email protected] 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: [email protected]
+Use ``Cc: [email protected]`` 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.