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

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 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: <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

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

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

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