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
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 <[email protected]>
---
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: <[email protected]> # after 4 weeks in mainline
+ Cc: <[email protected]> # after 6 weeks in a stable mainline release
* Point out known problems:
--
2.44.0
Explain the general concept once in the intro to keep things somewhat
shorter in the individual points.
Signed-off-by: Thorsten Leemhuis <[email protected]>
---
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: <[email protected]> # 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
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 <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
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 <[email protected]>
> ---
> 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: <[email protected]> # after 4 weeks in mainline
> + Cc: <[email protected]> # 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: <[email protected]> # after 4 weeks in mainline
>> + Cc: <[email protected]> # 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
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: <[email protected]> # after 4 weeks in mainline
> >> + Cc: <[email protected]> # 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: <[email protected]> # wait until -rc3
Cc: <[email protected]> # wait until 6.1 is released
Cc: <[email protected]> # 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 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: <[email protected]> # after 4 weeks in mainline
> >>>> + Cc: <[email protected]> # 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: <[email protected]> # wait until -rc3
> > Cc: <[email protected]> # wait until 6.1 is released
> > Cc: <[email protected]> # 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: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: <[email protected]> # after 4 weeks in mainline
>>>> + Cc: <[email protected]> # 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: <[email protected]> # wait until -rc3
> Cc: <[email protected]> # wait until 6.1 is released
> Cc: <[email protected]> # 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 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: <[email protected]> # after 4 weeks in mainline
>>>>>> + Cc: <[email protected]> # 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