* [PATCH v1 0/4] docs: stable-kernel-rules: fine-tuning and 'no semi-automatic backport'
@ 2024-04-11 5:25 Thorsten Leemhuis
2024-04-11 5:25 ` [PATCH v1 1/4] docs: stable-kernel-rules: reduce redundancy Thorsten Leemhuis
` (3 more replies)
0 siblings, 4 replies; 22+ messages in thread
From: Thorsten Leemhuis @ 2024-04-11 5:25 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sasha Levin
Cc: Jonathan Corbet, stable, workflows, linux-doc, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH v1 1/4] docs: stable-kernel-rules: reduce redundancy
2024-04-11 5:25 [PATCH v1 0/4] docs: stable-kernel-rules: fine-tuning and 'no semi-automatic backport' Thorsten Leemhuis
@ 2024-04-11 5:25 ` Thorsten Leemhuis
2024-04-11 5:27 ` Greg Kroah-Hartman
2024-04-11 5:25 ` [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport" Thorsten Leemhuis
` (2 subsequent siblings)
3 siblings, 1 reply; 22+ messages in thread
From: Thorsten Leemhuis @ 2024-04-11 5:25 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sasha Levin
Cc: Jonathan Corbet, stable, workflows, linux-doc, linux-kernel
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
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"
2024-04-11 5:25 [PATCH v1 0/4] docs: stable-kernel-rules: fine-tuning and 'no semi-automatic backport' Thorsten Leemhuis
2024-04-11 5:25 ` [PATCH v1 1/4] docs: stable-kernel-rules: reduce redundancy Thorsten Leemhuis
@ 2024-04-11 5:25 ` Thorsten Leemhuis
2024-04-11 5:29 ` Greg Kroah-Hartman
2024-04-11 5:25 ` [PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example Thorsten Leemhuis
2024-04-11 5:25 ` [PATCH v1 4/4] docs: stable-kernel-rules: remove code-labels tags Thorsten Leemhuis
3 siblings, 1 reply; 22+ messages in thread
From: Thorsten Leemhuis @ 2024-04-11 5:25 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sasha Levin
Cc: Jonathan Corbet, stable, workflows, linux-doc, linux-kernel
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
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example
2024-04-11 5:25 [PATCH v1 0/4] docs: stable-kernel-rules: fine-tuning and 'no semi-automatic backport' Thorsten Leemhuis
2024-04-11 5:25 ` [PATCH v1 1/4] docs: stable-kernel-rules: reduce redundancy Thorsten Leemhuis
2024-04-11 5:25 ` [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport" Thorsten Leemhuis
@ 2024-04-11 5:25 ` Thorsten Leemhuis
2024-04-11 5:30 ` Greg Kroah-Hartman
2024-04-11 5:25 ` [PATCH v1 4/4] docs: stable-kernel-rules: remove code-labels tags Thorsten Leemhuis
3 siblings, 1 reply; 22+ messages in thread
From: Thorsten Leemhuis @ 2024-04-11 5:25 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sasha Levin
Cc: Jonathan Corbet, stable, workflows, linux-doc, linux-kernel
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
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH v1 4/4] docs: stable-kernel-rules: remove code-labels tags
2024-04-11 5:25 [PATCH v1 0/4] docs: stable-kernel-rules: fine-tuning and 'no semi-automatic backport' Thorsten Leemhuis
` (2 preceding siblings ...)
2024-04-11 5:25 ` [PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example Thorsten Leemhuis
@ 2024-04-11 5:25 ` Thorsten Leemhuis
2024-04-11 5:31 ` Greg Kroah-Hartman
3 siblings, 1 reply; 22+ messages in thread
From: Thorsten Leemhuis @ 2024-04-11 5:25 UTC (permalink / raw)
To: Greg Kroah-Hartman, Sasha Levin
Cc: Jonathan Corbet, stable, workflows, linux-doc, linux-kernel
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
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH v1 1/4] docs: stable-kernel-rules: reduce redundancy
2024-04-11 5:25 ` [PATCH v1 1/4] docs: stable-kernel-rules: reduce redundancy Thorsten Leemhuis
@ 2024-04-11 5:27 ` Greg Kroah-Hartman
0 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-04-11 5:27 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Sasha Levin, Jonathan Corbet, stable, workflows, linux-doc, linux-kernel
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>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"
2024-04-11 5:25 ` [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport" Thorsten Leemhuis
@ 2024-04-11 5:29 ` Greg Kroah-Hartman
2024-04-11 6:59 ` Thorsten Leemhuis
0 siblings, 1 reply; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-04-11 5:29 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Sasha Levin, Jonathan Corbet, stable, workflows, linux-doc, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example
2024-04-11 5:25 ` [PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example Thorsten Leemhuis
@ 2024-04-11 5:30 ` Greg Kroah-Hartman
2024-04-11 5:50 ` Thorsten Leemhuis
0 siblings, 1 reply; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-04-11 5:30 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Sasha Levin, Jonathan Corbet, stable, workflows, linux-doc, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v1 4/4] docs: stable-kernel-rules: remove code-labels tags
2024-04-11 5:25 ` [PATCH v1 4/4] docs: stable-kernel-rules: remove code-labels tags Thorsten Leemhuis
@ 2024-04-11 5:31 ` Greg Kroah-Hartman
0 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-04-11 5:31 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Sasha Levin, Jonathan Corbet, stable, workflows, linux-doc, linux-kernel
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>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example
2024-04-11 5:30 ` Greg Kroah-Hartman
@ 2024-04-11 5:50 ` Thorsten Leemhuis
2024-04-11 6:10 ` Greg Kroah-Hartman
0 siblings, 1 reply; 22+ messages in thread
From: Thorsten Leemhuis @ 2024-04-11 5:50 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Sasha Levin, Jonathan Corbet, stable, workflows, linux-doc, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example
2024-04-11 5:50 ` Thorsten Leemhuis
@ 2024-04-11 6:10 ` Greg Kroah-Hartman
2024-04-11 6:50 ` Thorsten Leemhuis
0 siblings, 1 reply; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-04-11 6:10 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Sasha Levin, Jonathan Corbet, stable, workflows, linux-doc, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example
2024-04-11 6:10 ` Greg Kroah-Hartman
@ 2024-04-11 6:50 ` Thorsten Leemhuis
2024-04-11 6:56 ` Greg Kroah-Hartman
0 siblings, 1 reply; 22+ messages in thread
From: Thorsten Leemhuis @ 2024-04-11 6:50 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Sasha Levin, Jonathan Corbet, stable, workflows, linux-doc, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example
2024-04-11 6:50 ` Thorsten Leemhuis
@ 2024-04-11 6:56 ` Greg Kroah-Hartman
2024-04-11 7:18 ` Thorsten Leemhuis
0 siblings, 1 reply; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-04-11 6:56 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Sasha Levin, Jonathan Corbet, stable, workflows, linux-doc, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"
2024-04-11 5:29 ` Greg Kroah-Hartman
@ 2024-04-11 6:59 ` Thorsten Leemhuis
2024-04-11 7:40 ` Greg Kroah-Hartman
0 siblings, 1 reply; 22+ messages in thread
From: Thorsten Leemhuis @ 2024-04-11 6:59 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Sasha Levin, Jonathan Corbet, stable, workflows, linux-doc, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example
2024-04-11 6:56 ` Greg Kroah-Hartman
@ 2024-04-11 7:18 ` Thorsten Leemhuis
0 siblings, 0 replies; 22+ messages in thread
From: Thorsten Leemhuis @ 2024-04-11 7:18 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Sasha Levin, Jonathan Corbet, stable, workflows, linux-doc, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"
2024-04-11 6:59 ` Thorsten Leemhuis
@ 2024-04-11 7:40 ` Greg Kroah-Hartman
2024-04-11 7:50 ` Thorsten Leemhuis
0 siblings, 1 reply; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-04-11 7:40 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Sasha Levin, Jonathan Corbet, stable, workflows, linux-doc, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"
2024-04-11 7:40 ` Greg Kroah-Hartman
@ 2024-04-11 7:50 ` Thorsten Leemhuis
2024-04-11 9:13 ` Greg Kroah-Hartman
0 siblings, 1 reply; 22+ messages in thread
From: Thorsten Leemhuis @ 2024-04-11 7:50 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Sasha Levin, Jonathan Corbet, stable, workflows, linux-doc, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"
2024-04-11 7:50 ` Thorsten Leemhuis
@ 2024-04-11 9:13 ` Greg Kroah-Hartman
2024-04-11 9:19 ` Geert Uytterhoeven
0 siblings, 1 reply; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-04-11 9:13 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Sasha Levin, Jonathan Corbet, stable, workflows, linux-doc, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"
2024-04-11 9:13 ` Greg Kroah-Hartman
@ 2024-04-11 9:19 ` Geert Uytterhoeven
2024-04-11 9:53 ` Greg Kroah-Hartman
2024-04-11 9:57 ` Thorsten Leemhuis
0 siblings, 2 replies; 22+ messages in thread
From: Geert Uytterhoeven @ 2024-04-11 9:19 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Thorsten Leemhuis, Sasha Levin, Jonathan Corbet, stable,
workflows, linux-doc, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"
2024-04-11 9:19 ` Geert Uytterhoeven
@ 2024-04-11 9:53 ` Greg Kroah-Hartman
2024-04-11 9:57 ` Thorsten Leemhuis
1 sibling, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-04-11 9:53 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Thorsten Leemhuis, Sasha Levin, Jonathan Corbet, stable,
workflows, linux-doc, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"
2024-04-11 9:19 ` Geert Uytterhoeven
2024-04-11 9:53 ` Greg Kroah-Hartman
@ 2024-04-11 9:57 ` Thorsten Leemhuis
2024-04-11 15:12 ` Greg Kroah-Hartman
1 sibling, 1 reply; 22+ messages in thread
From: Thorsten Leemhuis @ 2024-04-11 9:57 UTC (permalink / raw)
To: Geert Uytterhoeven, Greg Kroah-Hartman
Cc: Sasha Levin, Jonathan Corbet, stable, workflows, linux-doc, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport"
2024-04-11 9:57 ` Thorsten Leemhuis
@ 2024-04-11 15:12 ` Greg Kroah-Hartman
0 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-04-11 15:12 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Geert Uytterhoeven, Sasha Levin, Jonathan Corbet, stable,
workflows, linux-doc, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2024-04-11 15:12 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-11 5:25 [PATCH v1 0/4] docs: stable-kernel-rules: fine-tuning and 'no semi-automatic backport' Thorsten Leemhuis
2024-04-11 5:25 ` [PATCH v1 1/4] docs: stable-kernel-rules: reduce redundancy Thorsten Leemhuis
2024-04-11 5:27 ` Greg Kroah-Hartman
2024-04-11 5:25 ` [PATCH v1 2/4] docs: stable-kernel-rules: mention "no semi-automatic backport" Thorsten Leemhuis
2024-04-11 5:29 ` Greg Kroah-Hartman
2024-04-11 6:59 ` Thorsten Leemhuis
2024-04-11 7:40 ` Greg Kroah-Hartman
2024-04-11 7:50 ` Thorsten Leemhuis
2024-04-11 9:13 ` Greg Kroah-Hartman
2024-04-11 9:19 ` Geert Uytterhoeven
2024-04-11 9:53 ` Greg Kroah-Hartman
2024-04-11 9:57 ` Thorsten Leemhuis
2024-04-11 15:12 ` Greg Kroah-Hartman
2024-04-11 5:25 ` [PATCH v1 3/4] docs: stable-kernel-rules: call mainline by its name and change example Thorsten Leemhuis
2024-04-11 5:30 ` Greg Kroah-Hartman
2024-04-11 5:50 ` Thorsten Leemhuis
2024-04-11 6:10 ` Greg Kroah-Hartman
2024-04-11 6:50 ` Thorsten Leemhuis
2024-04-11 6:56 ` Greg Kroah-Hartman
2024-04-11 7:18 ` Thorsten Leemhuis
2024-04-11 5:25 ` [PATCH v1 4/4] docs: stable-kernel-rules: remove code-labels tags Thorsten Leemhuis
2024-04-11 5:31 ` Greg Kroah-Hartman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).