Some developers deliberately steer clear of 'Fixes:' tags to prevent
changes from being backported semi-automatically by the stable team.
That somewhat undermines the reason for the existence of the Fixes: tag,
hence point out there is an alternative to reach the same effect.
Link: https://lore.kernel.org/all/dfd87673-c581-4b4b-b37a-1cf5c817240d@leemhuis.info/
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
Documentation/process/stable-kernel-rules.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
index 7bb16d42a51833..ebd57cb9277f7b 100644
--- a/Documentation/process/stable-kernel-rules.rst
+++ b/Documentation/process/stable-kernel-rules.rst
@@ -117,6 +117,12 @@ comment to pass arbitrary or predefined notes:
Note, such tagging is unnecessary if the stable team can derive the
appropriate versions from Fixes: tags.
+ * Prevent semi-automatic backporting of changes carrying a 'Fixes:' tag:
+
+ .. code-block:: none
+
+ Cc: <stable@vger.kernel.org> # no semi-automatic backport
+
* Delay pick up of patches:
.. code-block:: none
--
2.44.0On Thu, Apr 11, 2024 at 07:25:04AM +0200, Thorsten Leemhuis wrote: > Some developers deliberately steer clear of 'Fixes:' tags to prevent > changes from being backported semi-automatically by the stable team. > That somewhat undermines the reason for the existence of the Fixes: tag, > hence point out there is an alternative to reach the same effect. > > Link: https://lore.kernel.org/all/dfd87673-c581-4b4b-b37a-1cf5c817240d@leemhuis.info/ > Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> > --- > Documentation/process/stable-kernel-rules.rst | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst > index 7bb16d42a51833..ebd57cb9277f7b 100644 > --- a/Documentation/process/stable-kernel-rules.rst > +++ b/Documentation/process/stable-kernel-rules.rst > @@ -117,6 +117,12 @@ comment to pass arbitrary or predefined notes: > Note, such tagging is unnecessary if the stable team can derive the > appropriate versions from Fixes: tags. > > + * Prevent semi-automatic backporting of changes carrying a 'Fixes:' tag: > + > + .. code-block:: none > + > + Cc: <stable@vger.kernel.org> # no semi-automatic backport I do not understand, why are you saying "cc: stable" here if you do NOT want it backported? And what do you mean by "semi-automatic"? confused, greg k-h
On 11.04.24 07:29, Greg Kroah-Hartman wrote: > On Thu, Apr 11, 2024 at 07:25:04AM +0200, Thorsten Leemhuis wrote: >> Some developers deliberately steer clear of 'Fixes:' tags to prevent >> changes from being backported semi-automatically by the stable team. >> That somewhat undermines the reason for the existence of the Fixes: tag, >> hence point out there is an alternative to reach the same effect. >> >> Link: https://lore.kernel.org/all/dfd87673-c581-4b4b-b37a-1cf5c817240d@leemhuis.info/ >> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> >> --- >> Documentation/process/stable-kernel-rules.rst | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst >> index 7bb16d42a51833..ebd57cb9277f7b 100644 >> --- a/Documentation/process/stable-kernel-rules.rst >> +++ b/Documentation/process/stable-kernel-rules.rst >> @@ -117,6 +117,12 @@ comment to pass arbitrary or predefined notes: >> Note, such tagging is unnecessary if the stable team can derive the >> appropriate versions from Fixes: tags. >> >> + * Prevent semi-automatic backporting of changes carrying a 'Fixes:' tag: >> + >> + .. code-block:: none >> + >> + Cc: <stable@vger.kernel.org> # no semi-automatic backport > > I do not understand, why are you saying "cc: stable" here if you do NOT > want it backported? Because the only alternative the developers have to make the stable team not pick a single patch[1] is to deliberately omit a Fixes: tag even if the patch normally should have one. Like it was done here: https://lore.kernel.org/all/cover.1712226175.git.antony.antony@secunet.com/ And that somehow felt wrong to me, as discussed earlier in https://lore.kernel.org/all/dfd87673-c581-4b4b-b37a-1cf5c817240d@leemhuis.info/ [1] e.g. if they don't have or want their whole subsystem marked as 'ignore for the AUTOSEL and the "Fixes tag only" tools' https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/ignore_list > And what do you mean by "semi-automatic"? E.g. 'ignore for the AUTOSEL and the "Fixes tag only" tools'. That was the best term I came up with. Ciao, Thorsten
On Thu, Apr 11, 2024 at 08:59:39AM +0200, Thorsten Leemhuis wrote: > On 11.04.24 07:29, Greg Kroah-Hartman wrote: > > On Thu, Apr 11, 2024 at 07:25:04AM +0200, Thorsten Leemhuis wrote: > >> Some developers deliberately steer clear of 'Fixes:' tags to prevent > >> changes from being backported semi-automatically by the stable team. > >> That somewhat undermines the reason for the existence of the Fixes: tag, > >> hence point out there is an alternative to reach the same effect. > >> > >> Link: https://lore.kernel.org/all/dfd87673-c581-4b4b-b37a-1cf5c817240d@leemhuis.info/ > >> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info> > >> --- > >> Documentation/process/stable-kernel-rules.rst | 6 ++++++ > >> 1 file changed, 6 insertions(+) > >> > >> diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst > >> index 7bb16d42a51833..ebd57cb9277f7b 100644 > >> --- a/Documentation/process/stable-kernel-rules.rst > >> +++ b/Documentation/process/stable-kernel-rules.rst > >> @@ -117,6 +117,12 @@ comment to pass arbitrary or predefined notes: > >> Note, such tagging is unnecessary if the stable team can derive the > >> appropriate versions from Fixes: tags. > >> > >> + * Prevent semi-automatic backporting of changes carrying a 'Fixes:' tag: > >> + > >> + .. code-block:: none > >> + > >> + Cc: <stable@vger.kernel.org> # no semi-automatic backport > > > > I do not understand, why are you saying "cc: stable" here if you do NOT > > want it backported? > > Because the only alternative the developers have to make the stable team > not pick a single patch[1] is to deliberately omit a Fixes: tag even if > the patch normally should have one. Like it was done here: > https://lore.kernel.org/all/cover.1712226175.git.antony.antony@secunet.com/ That feels odd, but ok I now see the need for this for some minor set of changes (i.e. this has rarely come up in the past 15+ years) > And that somehow felt wrong to me, as discussed earlier in > https://lore.kernel.org/all/dfd87673-c581-4b4b-b37a-1cf5c817240d@leemhuis.info/ > > [1] e.g. if they don't have or want their whole subsystem marked as > 'ignore for the AUTOSEL and the "Fixes tag only" tools' > https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/ignore_list > > > And what do you mean by "semi-automatic"? > > E.g. 'ignore for the AUTOSEL and the "Fixes tag only" tools'. That was > the best term I came up with. Thinking about it more, I think we need to be much more explicit, and provide the reason why. 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? thanks, greg k-h
On 11.04.24 09:40, Greg Kroah-Hartman wrote: > On Thu, Apr 11, 2024 at 08:59:39AM +0200, Thorsten Leemhuis wrote: >> On 11.04.24 07:29, Greg Kroah-Hartman wrote: >>> On Thu, Apr 11, 2024 at 07:25:04AM +0200, Thorsten Leemhuis wrote: >>>> Some developers deliberately steer clear of 'Fixes:' tags to prevent >>>> changes from being backported semi-automatically by the stable team. >>>> That somewhat undermines the reason for the existence of the Fixes: tag, >>>> hence point out there is an alternative to reach the same effect. > [...] >>> I do not understand, why are you saying "cc: stable" here if you do NOT >>> want it backported? >> Because the only alternative the developers have to make the stable team >> not pick a single patch[1] is to deliberately omit a Fixes: tag even if >> the patch normally should have one. Like it was done here: >> https://lore.kernel.org/all/cover.1712226175.git.antony.antony@secunet.com/ > That feels odd, but ok I now see the need for this for some minor set of > changes (i.e. this has rarely come up in the past 15+ years) > > [...] >> E.g. 'ignore for the AUTOSEL and the "Fixes tag only" tools'. That was >> the best term I came up with. > > Thinking about it more, I think we need to be much more explicit, and > provide the reason why. > > 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? Totally fine with me, but that feels somewhat long and hard to type. How about just 'no-stable@kernel.org' (or 'nostable@kernel.org')? Ciao, Thorsten
On Thu, Apr 11, 2024 at 09:50:24AM +0200, Thorsten Leemhuis wrote: > On 11.04.24 09:40, Greg Kroah-Hartman wrote: > > On Thu, Apr 11, 2024 at 08:59:39AM +0200, Thorsten Leemhuis wrote: > >> On 11.04.24 07:29, Greg Kroah-Hartman wrote: > >>> On Thu, Apr 11, 2024 at 07:25:04AM +0200, Thorsten Leemhuis wrote: > >>>> Some developers deliberately steer clear of 'Fixes:' tags to prevent > >>>> changes from being backported semi-automatically by the stable team. > >>>> That somewhat undermines the reason for the existence of the Fixes: tag, > >>>> hence point out there is an alternative to reach the same effect. > > [...] > >>> I do not understand, why are you saying "cc: stable" here if you do NOT > >>> want it backported? > >> Because the only alternative the developers have to make the stable team > >> not pick a single patch[1] is to deliberately omit a Fixes: tag even if > >> the patch normally should have one. Like it was done here: > >> https://lore.kernel.org/all/cover.1712226175.git.antony.antony@secunet.com/ > > That feels odd, but ok I now see the need for this for some minor set of > > changes (i.e. this has rarely come up in the past 15+ years) > > > > [...] > >> E.g. 'ignore for the AUTOSEL and the "Fixes tag only" tools'. That was > >> the best term I came up with. > > > > Thinking about it more, I think we need to be much more explicit, and > > provide the reason why. > > > > 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? > > Totally fine with me, but that feels somewhat long and hard to type. I want it long and hard to type and very very explicit that this is what the developer/maintainer wants to have happen (again, because this is such a rare occurrence.) > How > about just 'no-stable@kernel.org' (or 'nostable@kernel.org')? More words are better :) thanks, greg k-h
On Thu, Apr 11, 2024 at 11:13 AM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Thu, Apr 11, 2024 at 09:50:24AM +0200, Thorsten Leemhuis wrote:
> > On 11.04.24 09:40, Greg Kroah-Hartman wrote:
> > > On Thu, Apr 11, 2024 at 08:59:39AM +0200, Thorsten Leemhuis wrote:
> > >> On 11.04.24 07:29, Greg Kroah-Hartman wrote:
> > >>> On Thu, Apr 11, 2024 at 07:25:04AM +0200, Thorsten Leemhuis wrote:
> > >>>> Some developers deliberately steer clear of 'Fixes:' tags to prevent
> > >>>> changes from being backported semi-automatically by the stable team.
> > >>>> That somewhat undermines the reason for the existence of the Fixes: tag,
> > >>>> hence point out there is an alternative to reach the same effect.
> > > [...]
> > >>> I do not understand, why are you saying "cc: stable" here if you do NOT
> > >>> want it backported?
> > >> Because the only alternative the developers have to make the stable team
> > >> not pick a single patch[1] is to deliberately omit a Fixes: tag even if
> > >> the patch normally should have one. Like it was done here:
> > >> https://lore.kernel.org/all/cover.1712226175.git.antony.antony@secunet.com/
> > > That feels odd, but ok I now see the need for this for some minor set of
> > > changes (i.e. this has rarely come up in the past 15+ years)
> > >
> > > [...]
> > >> E.g. 'ignore for the AUTOSEL and the "Fixes tag only" tools'. That was
> > >> the best term I came up with.
> > >
> > > Thinking about it more, I think we need to be much more explicit, and
> > > provide the reason why.
> > >
> > > 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?
> >
> > Totally fine with me, but that feels somewhat long and hard to type.
>
> I want it long and hard to type and very very explicit that this is what
> the developer/maintainer wants to have happen (again, because this is
> such a rare occurrence.)
>
> > How
> > about just 'no-stable@kernel.org' (or 'nostable@kernel.org')?
>
> More words are better :)
And after that, someone discovers this turns out to be (a hard
dependency for) a very critical fix that does need backporting?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On 11.04.24 11:19, Geert Uytterhoeven wrote: > On Thu, Apr 11, 2024 at 11:13 AM Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: >> On Thu, Apr 11, 2024 at 09:50:24AM +0200, Thorsten Leemhuis wrote: >>> On 11.04.24 09:40, Greg Kroah-Hartman wrote: >>>> On Thu, Apr 11, 2024 at 08:59:39AM +0200, Thorsten Leemhuis wrote: >>>>> On 11.04.24 07:29, Greg Kroah-Hartman wrote: >>>>>> On Thu, Apr 11, 2024 at 07:25:04AM +0200, Thorsten Leemhuis wrote: >>>>>>> Some developers deliberately steer clear of 'Fixes:' tags to prevent >>>>>>> changes from being backported semi-automatically by the stable team. >>>>>>> That somewhat undermines the reason for the existence of the Fixes: tag, >>>>>>> hence point out there is an alternative to reach the same effect. >>>> [...] >>>>>> I do not understand, why are you saying "cc: stable" here if you do NOT >>>>>> want it backported? >>>>> Because the only alternative the developers have to make the stable team >>>>> not pick a single patch[1] is to deliberately omit a Fixes: tag even if >>>>> the patch normally should have one. Like it was done here: >>>>> https://lore.kernel.org/all/cover.1712226175.git.antony.antony@secunet.com/ >>>> That feels odd, but ok I now see the need for this for some minor set of >>>> changes (i.e. this has rarely come up in the past 15+ years) >>>> >>>> [...] >>>>> E.g. 'ignore for the AUTOSEL and the "Fixes tag only" tools'. That was >>>>> the best term I came up with. >>>> >>>> Thinking about it more, I think we need to be much more explicit, and >>>> provide the reason why. >>>> >>>> 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? >>> >>> Totally fine with me, but that feels somewhat long and hard to type. >> >> I want it long and hard to type and very very explicit that this is what >> the developer/maintainer wants to have happen (again, because this is >> such a rare occurrence.) >> >>> How >>> about just 'no-stable@kernel.org' (or 'nostable@kernel.org')? >> >> More words are better :) > > And after that, someone discovers this turns out to be (a hard > dependency for) a very critical fix that does need backporting? Ask why the tag was set I guess. But yeah, that was among the minor reasons why I had come up with "no semiautomatic stable backport" thing, as it made the intention more clear. Maybe only-manual-stable-backport@kernel.org could help and is even longer. But I might be getting into bikeshedding territory here. :-D Ciao, Thorsten Cioao, Thorsten
On Thu, Apr 11, 2024 at 11:57:04AM +0200, Thorsten Leemhuis wrote: > On 11.04.24 11:19, Geert Uytterhoeven wrote: > > On Thu, Apr 11, 2024 at 11:13 AM Greg Kroah-Hartman > > <gregkh@linuxfoundation.org> wrote: > >> On Thu, Apr 11, 2024 at 09:50:24AM +0200, Thorsten Leemhuis wrote: > >>> On 11.04.24 09:40, Greg Kroah-Hartman wrote: > >>>> On Thu, Apr 11, 2024 at 08:59:39AM +0200, Thorsten Leemhuis wrote: > >>>>> On 11.04.24 07:29, Greg Kroah-Hartman wrote: > >>>>>> On Thu, Apr 11, 2024 at 07:25:04AM +0200, Thorsten Leemhuis wrote: > >>>>>>> Some developers deliberately steer clear of 'Fixes:' tags to prevent > >>>>>>> changes from being backported semi-automatically by the stable team. > >>>>>>> That somewhat undermines the reason for the existence of the Fixes: tag, > >>>>>>> hence point out there is an alternative to reach the same effect. > >>>> [...] > >>>>>> I do not understand, why are you saying "cc: stable" here if you do NOT > >>>>>> want it backported? > >>>>> Because the only alternative the developers have to make the stable team > >>>>> not pick a single patch[1] is to deliberately omit a Fixes: tag even if > >>>>> the patch normally should have one. Like it was done here: > >>>>> https://lore.kernel.org/all/cover.1712226175.git.antony.antony@secunet.com/ > >>>> That feels odd, but ok I now see the need for this for some minor set of > >>>> changes (i.e. this has rarely come up in the past 15+ years) > >>>> > >>>> [...] > >>>>> E.g. 'ignore for the AUTOSEL and the "Fixes tag only" tools'. That was > >>>>> the best term I came up with. > >>>> > >>>> Thinking about it more, I think we need to be much more explicit, and > >>>> provide the reason why. > >>>> > >>>> 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? > >>> > >>> Totally fine with me, but that feels somewhat long and hard to type. > >> > >> I want it long and hard to type and very very explicit that this is what > >> the developer/maintainer wants to have happen (again, because this is > >> such a rare occurrence.) > >> > >>> How > >>> about just 'no-stable@kernel.org' (or 'nostable@kernel.org')? > >> > >> More words are better :) > > > > And after that, someone discovers this turns out to be (a hard > > dependency for) a very critical fix that does need backporting? > > Ask why the tag was set I guess. But yeah, that was among the minor > reasons why I had come up with "no semiautomatic stable backport" thing, > as it made the intention more clear. Maybe > > only-manual-stable-backport@kernel.org > > could help and is even longer. But I might be getting into bikeshedding > territory here. :-D That one would not work as I would then manually backport the commit :) Actually, one can say that all of the commits are manually backported as I review them all that are cc: stable when I apply them. So while bikeshedding is fun, this would mean the opposite of what you intend. thanks, greg k-h
On Thu, Apr 11, 2024 at 11:19:57AM +0200, Geert Uytterhoeven wrote: > On Thu, Apr 11, 2024 at 11:13 AM Greg Kroah-Hartman > <gregkh@linuxfoundation.org> wrote: > > On Thu, Apr 11, 2024 at 09:50:24AM +0200, Thorsten Leemhuis wrote: > > > On 11.04.24 09:40, Greg Kroah-Hartman wrote: > > > > On Thu, Apr 11, 2024 at 08:59:39AM +0200, Thorsten Leemhuis wrote: > > > >> On 11.04.24 07:29, Greg Kroah-Hartman wrote: > > > >>> On Thu, Apr 11, 2024 at 07:25:04AM +0200, Thorsten Leemhuis wrote: > > > >>>> Some developers deliberately steer clear of 'Fixes:' tags to prevent > > > >>>> changes from being backported semi-automatically by the stable team. > > > >>>> That somewhat undermines the reason for the existence of the Fixes: tag, > > > >>>> hence point out there is an alternative to reach the same effect. > > > > [...] > > > >>> I do not understand, why are you saying "cc: stable" here if you do NOT > > > >>> want it backported? > > > >> Because the only alternative the developers have to make the stable team > > > >> not pick a single patch[1] is to deliberately omit a Fixes: tag even if > > > >> the patch normally should have one. Like it was done here: > > > >> https://lore.kernel.org/all/cover.1712226175.git.antony.antony@secunet.com/ > > > > That feels odd, but ok I now see the need for this for some minor set of > > > > changes (i.e. this has rarely come up in the past 15+ years) > > > > > > > > [...] > > > >> E.g. 'ignore for the AUTOSEL and the "Fixes tag only" tools'. That was > > > >> the best term I came up with. > > > > > > > > Thinking about it more, I think we need to be much more explicit, and > > > > provide the reason why. > > > > > > > > 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? > > > > > > Totally fine with me, but that feels somewhat long and hard to type. > > > > I want it long and hard to type and very very explicit that this is what > > the developer/maintainer wants to have happen (again, because this is > > such a rare occurrence.) > > > > > How > > > about just 'no-stable@kernel.org' (or 'nostable@kernel.org')? > > > > More words are better :) > > And after that, someone discovers this turns out to be (a hard > dependency for) a very critical fix that does need backporting? Then we backport it and let the person know like always. thanks, greg k-h
© 2016 - 2026 Red Hat, Inc.