[PATCH v1 0/4] docs: stable-kernel-rules: fine-tuning and 'no semi-automatic backport'

[PATCH v1 0/4] docs: stable-kernel-rules: fine-tuning and 'no semi-automatic backport'

[Thorsten Leemhuis]

After a recent discussion regarding "do we need a 'nobackport' tag" I
set out to create one change for stable-kernel-rules.rst.  This is now
the second patch in the series, which links to that discussion; the
other stuff is fine-tuning that happened along the way.

Ciao, Thorsten

Thorsten Leemhuis (4):
  docs: stable-kernel-rules: reduce redundancy
  docs: stable-kernel-rules: mention "no semi-automatic backport"
  docs: stable-kernel-rules: call mainline by its name and change
    example
  docs: stable-kernel-rules: remove code-labels tags

 Documentation/process/stable-kernel-rules.rst | 50 +++++++------------
 1 file changed, 18 insertions(+), 32 deletions(-)


base-commit: 3f86ed6ec0b390c033eae7f9c487a3fea268e027
-- 
2.44.0

[PATCH v1 1/4] docs: stable-kernel-rules: reduce redundancy

[Thorsten Leemhuis]

Explain the general concept once in the intro to keep things somewhat
shorter in the individual points.

Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
 Documentation/process/stable-kernel-rules.rst | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
index 41f1e07abfdfa7..7bb16d42a51833 100644
--- a/Documentation/process/stable-kernel-rules.rst
+++ b/Documentation/process/stable-kernel-rules.rst
@@ -79,10 +79,9 @@ stable tree without anything else needing to be done by the author or
 subsystem maintainer.
 
 To sent additional instructions to the stable team, use a shell-style inline
-comment:
+comment to pass arbitrary or predefined notes:
 
- * To specify any additional patch prerequisites for cherry picking use the
-   following format in the sign-off area:
+ * Specify any additional patch prerequisites for cherry picking:
 
    .. code-block:: none
 
@@ -101,8 +100,7 @@ comment:
      git cherry-pick fd21073
      git cherry-pick <this commit>
 
- * For patches that may have kernel version prerequisites specify them using
-   the following format in the sign-off area:
+ * Point out kernel version prerequisites:
 
    .. code-block:: none
 
@@ -119,14 +117,13 @@ comment:
    Note, such tagging is unnecessary if the stable team can derive the
    appropriate versions from Fixes: tags.
 
- * To delay pick up of patches, use the following format:
+ * Delay pick up of patches:
 
    .. code-block:: none
 
      Cc: <stable@vger.kernel.org> # after 4 weeks in mainline
 
- * For any other requests, just add a note to the stable tag. This for example
-   can be used to point out known problems:
+ * Point out known problems:
 
    .. code-block:: none
 
-- 
2.44.0

Re: [PATCH v1 1/4] docs: stable-kernel-rules: reduce redundancy

[Greg Kroah-Hartman]

On Thu, Apr 11, 2024 at 07:25:03AM +0200, Thorsten Leemhuis wrote:
> Explain the general concept once in the intro to keep things somewhat
> shorter in the individual points.
> 
> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"

[Thorsten Leemhuis]

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.0

Re: [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"

[Greg Kroah-Hartman]

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?

And what do you mean by "semi-automatic"?

confused,

greg k-h

Re: [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"

[Thorsten Leemhuis]

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

Re: [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"

[Greg Kroah-Hartman]

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

Re: [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"

[Thorsten Leemhuis]

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

Re: [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"

[Greg Kroah-Hartman]

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

Re: [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"

[Geert Uytterhoeven]

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

Re: [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"

[Greg Kroah-Hartman]

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

Re: [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"

[Thorsten Leemhuis]

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

Re: [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"

[Greg Kroah-Hartman]

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

[PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example

[Thorsten Leemhuis]

Fine-tuning:

* s/Linus' tree/Linux mainline/, as mainline is the term used elsewhere
  in the document.

* Provide a better example for the 'delayed backporting' case.

Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
 Documentation/process/stable-kernel-rules.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
index ebd57cb9277f7b..3c05f39858c78a 100644
--- a/Documentation/process/stable-kernel-rules.rst
+++ b/Documentation/process/stable-kernel-rules.rst
@@ -6,7 +6,7 @@ Everything you ever wanted to know about Linux -stable releases
 Rules on what kind of patches are accepted, and which ones are not, into the
 "-stable" tree:
 
- - It or an equivalent fix must already exist in Linus' tree (upstream).
+ - It or an equivalent fix must already exist in Linux mainline (upstream).
  - It must be obviously correct and tested.
  - It cannot be bigger than 100 lines, with context.
  - It must follow the
@@ -127,7 +127,7 @@ comment to pass arbitrary or predefined notes:
 
    .. code-block:: none
 
-     Cc: <stable@vger.kernel.org> # after 4 weeks in mainline
+     Cc: <stable@vger.kernel.org> # after 6 weeks in a stable mainline release
 
  * Point out known problems:
 
-- 
2.44.0

Re: [PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example

[Greg Kroah-Hartman]

On Thu, Apr 11, 2024 at 07:25:05AM +0200, Thorsten Leemhuis wrote:
> Fine-tuning:
> 
> * s/Linus' tree/Linux mainline/, as mainline is the term used elsewhere
>   in the document.
> 
> * Provide a better example for the 'delayed backporting' case.
> 
> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
> ---
>  Documentation/process/stable-kernel-rules.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
> index ebd57cb9277f7b..3c05f39858c78a 100644
> --- a/Documentation/process/stable-kernel-rules.rst
> +++ b/Documentation/process/stable-kernel-rules.rst
> @@ -6,7 +6,7 @@ Everything you ever wanted to know about Linux -stable releases
>  Rules on what kind of patches are accepted, and which ones are not, into the
>  "-stable" tree:
>  
> - - It or an equivalent fix must already exist in Linus' tree (upstream).
> + - It or an equivalent fix must already exist in Linux mainline (upstream).
>   - It must be obviously correct and tested.
>   - It cannot be bigger than 100 lines, with context.
>   - It must follow the
> @@ -127,7 +127,7 @@ comment to pass arbitrary or predefined notes:
>  
>     .. code-block:: none
>  
> -     Cc: <stable@vger.kernel.org> # after 4 weeks in mainline
> +     Cc: <stable@vger.kernel.org> # after 6 weeks in a stable mainline release

I do not know what "stable mainline release" means here, sorry.  "after
4 weeks in mainline" means "after in Linus's tree for 4 weeks, but
Linus's tree is not "stable mainline".

thanks,

greg k-h

Re: [PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example

[Thorsten Leemhuis]

On 11.04.24 07:30, Greg Kroah-Hartman wrote:
> On Thu, Apr 11, 2024 at 07:25:05AM +0200, Thorsten Leemhuis wrote:
>>  
>> -     Cc: <stable@vger.kernel.org> # after 4 weeks in mainline
>> +     Cc: <stable@vger.kernel.org> # after 6 weeks in a stable mainline release
> 
> I do not know what "stable mainline release" means here, sorry.  "after
> 4 weeks in mainline" means "after in Linus's tree for 4 weeks, but
> Linus's tree is not "stable mainline".

I meant a proper mainline release like 6.7 or 6.8 to make it obvious
that this does not mean a "pre-release".

I actually had used the term "proper mainline release" earlier in a
draft, but a quick search on the net showed that this is not really used
out there. "stable mainline release" is not popular either, but seemed
to be a better match; I also considered "final mainline release", but
that felt odd.

It feels like there must be some better term my mind just stumbles to
come up with. Please help. :-D

Ciao, Thorsten

Re: [PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example

[Greg Kroah-Hartman]

On Thu, Apr 11, 2024 at 07:50:29AM +0200, Thorsten Leemhuis wrote:
> On 11.04.24 07:30, Greg Kroah-Hartman wrote:
> > On Thu, Apr 11, 2024 at 07:25:05AM +0200, Thorsten Leemhuis wrote:
> >>  
> >> -     Cc: <stable@vger.kernel.org> # after 4 weeks in mainline
> >> +     Cc: <stable@vger.kernel.org> # after 6 weeks in a stable mainline release
> > 
> > I do not know what "stable mainline release" means here, sorry.  "after
> > 4 weeks in mainline" means "after in Linus's tree for 4 weeks, but
> > Linus's tree is not "stable mainline".
> 
> I meant a proper mainline release like 6.7 or 6.8 to make it obvious
> that this does not mean a "pre-release".
> 
> I actually had used the term "proper mainline release" earlier in a
> draft, but a quick search on the net showed that this is not really used
> out there. "stable mainline release" is not popular either, but seemed
> to be a better match; I also considered "final mainline release", but
> that felt odd.
> 
> It feels like there must be some better term my mind just stumbles to
> come up with. Please help. :-D

Well, what is the goal here?  Just put it in words, I have seen stuff
like:
	Cc: <stable@vger.kernel.org> # wait until -rc3
	Cc: <stable@vger.kernel.org> # wait until 6.1 is released
	Cc: <stable@vger.kernel.org> # after -rc2

and so on.

Just pick a specific time/release might be better?  "after X weeks" is
assuming that we all know and remember how many weeks something
happened...

thanks,

greg k-h

Re: [PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example

[Thorsten Leemhuis]

On 11.04.24 08:10, Greg Kroah-Hartman wrote:
> On Thu, Apr 11, 2024 at 07:50:29AM +0200, Thorsten Leemhuis wrote:
>> On 11.04.24 07:30, Greg Kroah-Hartman wrote:
>>> On Thu, Apr 11, 2024 at 07:25:05AM +0200, Thorsten Leemhuis wrote:
>>>>  
>>>> -     Cc: <stable@vger.kernel.org> # after 4 weeks in mainline
>>>> +     Cc: <stable@vger.kernel.org> # after 6 weeks in a stable mainline release
>>>
>>> I do not know what "stable mainline release" means here, sorry.  "after
>>> 4 weeks in mainline" means "after in Linus's tree for 4 weeks, but
>>> Linus's tree is not "stable mainline".
>>
>> I meant a proper mainline release like 6.7 or 6.8 to make it obvious
>> that this does not mean a "pre-release".
>>
>> I actually had used the term "proper mainline release" earlier in a
>> draft, but a quick search on the net showed that this is not really used
>> out there. "stable mainline release" is not popular either, but seemed
>> to be a better match; I also considered "final mainline release", but
>> that felt odd.
>>
>> It feels like there must be some better term my mind just stumbles to
>> come up with. Please help. :-D
> 
> Well, what is the goal here?  Just put it in words, I have seen stuff
> like:
> 	Cc: <stable@vger.kernel.org> # wait until -rc3
> 	Cc: <stable@vger.kernel.org> # wait until 6.1 is released
> 	Cc: <stable@vger.kernel.org> # after -rc2
> 
> and so on.
> 
> Just pick a specific time/release might be better?  "after X weeks" is
> assuming that we all know and remember how many weeks something
> happened...

My reasoning was: a developer that submits a patch has no full control
over when the patch mainlined -- and plans sometimes change, too.

So a patch that was meant to go into 6.1-rc with a tag like "# wait
until 4 weeks after 6.1 is released" might only be mainlined for 6.2-rc1
-- and then the tag does not express the developers intention.

But that might be a corner case that we could ignore. So maybe "# wait
until 4 weeks after 6.1 is released" is the better example (from what
I've heard something like that is what developer would like to have
sometimes).

Ciao, Thorsten

Re: [PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example

[Greg Kroah-Hartman]

On Thu, Apr 11, 2024 at 08:50:19AM +0200, Thorsten Leemhuis wrote:
> On 11.04.24 08:10, Greg Kroah-Hartman wrote:
> > On Thu, Apr 11, 2024 at 07:50:29AM +0200, Thorsten Leemhuis wrote:
> >> On 11.04.24 07:30, Greg Kroah-Hartman wrote:
> >>> On Thu, Apr 11, 2024 at 07:25:05AM +0200, Thorsten Leemhuis wrote:
> >>>>  
> >>>> -     Cc: <stable@vger.kernel.org> # after 4 weeks in mainline
> >>>> +     Cc: <stable@vger.kernel.org> # after 6 weeks in a stable mainline release
> >>>
> >>> I do not know what "stable mainline release" means here, sorry.  "after
> >>> 4 weeks in mainline" means "after in Linus's tree for 4 weeks, but
> >>> Linus's tree is not "stable mainline".
> >>
> >> I meant a proper mainline release like 6.7 or 6.8 to make it obvious
> >> that this does not mean a "pre-release".
> >>
> >> I actually had used the term "proper mainline release" earlier in a
> >> draft, but a quick search on the net showed that this is not really used
> >> out there. "stable mainline release" is not popular either, but seemed
> >> to be a better match; I also considered "final mainline release", but
> >> that felt odd.
> >>
> >> It feels like there must be some better term my mind just stumbles to
> >> come up with. Please help. :-D
> > 
> > Well, what is the goal here?  Just put it in words, I have seen stuff
> > like:
> > 	Cc: <stable@vger.kernel.org> # wait until -rc3
> > 	Cc: <stable@vger.kernel.org> # wait until 6.1 is released
> > 	Cc: <stable@vger.kernel.org> # after -rc2
> > 
> > and so on.
> > 
> > Just pick a specific time/release might be better?  "after X weeks" is
> > assuming that we all know and remember how many weeks something
> > happened...
> 
> My reasoning was: a developer that submits a patch has no full control
> over when the patch mainlined -- and plans sometimes change, too.
> 
> So a patch that was meant to go into 6.1-rc with a tag like "# wait
> until 4 weeks after 6.1 is released" might only be mainlined for 6.2-rc1
> -- and then the tag does not express the developers intention.

I've normally seen patches end up in Linus's tree "too early" more often
(i.e. cc: stable for stuff that has never been in a stable tree yet),
but sure, I can see how changes can also take too long.

> But that might be a corner case that we could ignore. So maybe "# wait
> until 4 weeks after 6.1 is released" is the better example (from what
> I've heard something like that is what developer would like to have
> sometimes).

Yes, referencing off of a fixed point like a release is best as that's
much easier for humans to calculate.

Also because, the original "after 4 weeks", doesn't give me a reference
point to judge what the starting time is easily.  Yes, I have tools for
that, but most people don't.

So how about changing it to use the "fixed point" reference please?  The
phrasing "after -rc3" is probably what most people almost always want
anyway, given the huge churn that -rc1 is.

thanks,

greg k-h

Re: [PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example

[Thorsten Leemhuis]

On 11.04.24 08:56, Greg Kroah-Hartman wrote:
> On Thu, Apr 11, 2024 at 08:50:19AM +0200, Thorsten Leemhuis wrote:
>> On 11.04.24 08:10, Greg Kroah-Hartman wrote:
>>> On Thu, Apr 11, 2024 at 07:50:29AM +0200, Thorsten Leemhuis wrote:
>>>> On 11.04.24 07:30, Greg Kroah-Hartman wrote:
>>>>> On Thu, Apr 11, 2024 at 07:25:05AM +0200, Thorsten Leemhuis wrote:
>>>>>>  
>>>>>> -     Cc: <stable@vger.kernel.org> # after 4 weeks in mainline
>>>>>> +     Cc: <stable@vger.kernel.org> # after 6 weeks in a stable mainline release
> 
> So how about changing it to use the "fixed point" reference please?  The
> phrasing "after -rc3" is probably what most people almost always want
> anyway, given the huge churn that -rc1 is.

Okay, will go with that phrase in v2; people that want to express "four
weeks after the change hit a proper mainline release" (I've seen a few
people want something like that to ensure it gets field testing in a
real release) can then add a version number to it.

Thx! Ciao, Thorsten

[PATCH v1 4/4] docs: stable-kernel-rules: remove code-labels tags

[Thorsten Leemhuis]

Remove the 'code-block:: none' labels and switch to the shorter '::' to
reduce noise.

CC: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
---
Intentionally the last patch in the series to make it easy to skip in
case Jonathan or someone else points out there is a reason for these
tags.
---
 Documentation/process/stable-kernel-rules.rst | 37 +++++--------------
 1 file changed, 10 insertions(+), 27 deletions(-)

diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
index 3c05f39858c78a..0ae38472bb688c 100644
--- a/Documentation/process/stable-kernel-rules.rst
+++ b/Documentation/process/stable-kernel-rules.rst
@@ -68,22 +68,17 @@ Option 1
 ********
 
 To have a patch you submit for mainline inclusion later automatically picked up
-for stable trees, add the tag
-
-.. code-block:: none
+for stable trees, add this tag in the sign-off area::
 
      Cc: stable@vger.kernel.org
 
-in the sign-off area. 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.
+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.
 
 To sent additional instructions to the stable team, use a shell-style inline
 comment to pass arbitrary or predefined notes:
 
- * Specify any additional patch prerequisites for cherry picking:
-
-   .. code-block:: none
+ * Specify any additional patch prerequisites for cherry picking::
 
      Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
      Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
@@ -91,24 +86,18 @@ comment to pass arbitrary or predefined notes:
      Cc: <stable@vger.kernel.org> # 3.3.x
      Signed-off-by: Ingo Molnar <mingo@elte.hu>
 
-   The tag sequence has the meaning of:
-
-   .. code-block:: none
+   The tag sequence has the meaning of::
 
      git cherry-pick a1f84a3
      git cherry-pick 1b9508f
      git cherry-pick fd21073
      git cherry-pick <this commit>
 
- * Point out kernel version prerequisites:
-
-   .. code-block:: none
+ * Point out kernel version prerequisites::
 
      Cc: <stable@vger.kernel.org> # 3.3.x
 
-   The tag has the meaning of:
-
-   .. code-block:: none
+   The tag has the meaning of::
 
      git cherry-pick <this commit>
 
@@ -129,9 +118,7 @@ comment to pass arbitrary or predefined notes:
 
      Cc: <stable@vger.kernel.org> # after 6 weeks in a stable mainline release
 
- * Point out known problems:
-
-   .. code-block:: none
+ * Point out known problems::
 
      Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3
 
@@ -153,15 +140,11 @@ Option 3
 Send the patch, after verifying that it follows the above rules, to
 stable@vger.kernel.org and mention the kernel versions you wish it to be applied
 to. When doing so, you must note the upstream commit ID in the changelog of your
-submission with a separate line above the commit text, like this:
-
-.. code-block:: none
+submission with a separate line above the commit text, like this::
 
     commit <sha1> upstream.
 
-or alternatively:
-
-.. code-block:: none
+Or alternatively::
 
     [ Upstream commit <sha1> ]
 
-- 
2.44.0

Re: [PATCH v1 4/4] docs: stable-kernel-rules: remove code-labels tags

[Greg Kroah-Hartman]

On Thu, Apr 11, 2024 at 07:25:06AM +0200, Thorsten Leemhuis wrote:
> Remove the 'code-block:: none' labels and switch to the shorter '::' to
> reduce noise.
> 
> CC: Jonathan Corbet <corbet@lwn.net>
> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>

Assuming the output is the same as before (I didn't run it to verify):

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>