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