[PATCH 0/4] Stable kernel release process update

[PATCH 0/4] Stable kernel release process update

[Bagas Sanjaya]

The stable release process documented in stable-kernel-rules.rst needs
to be updated to reflect current procedure.

Patch 1 is merely reorganizing three submission option lists to be
subsection of the procedure section.

Patch 2 contains the actual process documentation update.

Patch 3 and 4 updates "Tree" section by adding stable -rc tree link and
correcting link for stable tree, respectively.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: stable@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

Bagas Sanjaya (4):
  Documentation: make option lists subsection of "Procedure for
    submitting patches to the -stable tree" in stable-kernel-rules.rst
  Documentation: update stable review cycle documentation
  Documentation: add link to stable release candidate tree
  Documentation: update stable tree link

 Documentation/process/stable-kernel-rules.rst | 31 ++++++++++++++-----
 1 file changed, 24 insertions(+), 7 deletions(-)


base-commit: ffb217a13a2eaf6d5bd974fc83036a53ca69f1e2
-- 
An old man doll... just what I always wanted! - Clara

[PATCH 1/4] Documentation: make option lists subsection of "Procedure for submitting patches to the -stable tree" in stable-kernel-rules.rst

[Bagas Sanjaya]

The table of contents generated for stable-kernel-rules.rst contains
"For all other submissions..." section, that includes options
subsections. These options subsections should have been subsections of
"Procedure for submitting patches..." section. Remove the redundant
section.

Also, convert note about security patches to use `.. note::` block.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: stable@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
---
 Documentation/process/stable-kernel-rules.rst | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
index 003c865e9c2..d8ce4c0c775 100644
--- a/Documentation/process/stable-kernel-rules.rst
+++ b/Documentation/process/stable-kernel-rules.rst
@@ -35,12 +35,13 @@ Rules on what kind of patches are accepted, and which ones are not, into the
 Procedure for submitting patches to the -stable tree
 ----------------------------------------------------
 
- - Security patches should not be handled (solely) by the -stable review
+.. note::
+
+   Security patches should not be handled (solely) by the -stable review
    process but should follow the procedures in
    :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`.
 
-For all other submissions, choose one of the following procedures
------------------------------------------------------------------
+There are three options:
 
 .. _option_1:
 
-- 
An old man doll... just what I always wanted! - Clara

[PATCH 2/4] Documentation: update stable review cycle documentation

[Bagas Sanjaya]

In recent times, the review cycle for stable releases have been changed.
In particular, there is release candidate phase between ACKing patches
and new stable release. Also, in case of failed submissions (fail to
apply to stable tree), manual backport (Option 3) have to be submitted
instead.

Update the release cycle documentation on stable-kernel-rules.rst to
reflect the above.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: stable@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
---
 Documentation/process/stable-kernel-rules.rst | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
index d8ce4c0c775..c0c87d87f7d 100644
--- a/Documentation/process/stable-kernel-rules.rst
+++ b/Documentation/process/stable-kernel-rules.rst
@@ -139,6 +139,9 @@ Following the submission:
    days, according to the developer's schedules.
  - If accepted, the patch will be added to the -stable queue, for review by
    other developers and by the relevant subsystem maintainer.
+ - Some submitted patches may fail to apply to -stable tree. When this is the
+   case, the maintainer will reply to the sender requesting the backport.
+   If no backport is made, the submission will be ignored.
 
 
 Review cycle
@@ -147,13 +150,22 @@ Review cycle
  - When the -stable maintainers decide for a review cycle, the patches will be
    sent to the review committee, and the maintainer of the affected area of
    the patch (unless the submitter is the maintainer of the area) and CC: to
-   the linux-kernel mailing list.
+   the linux-kernel mailing list. Patches are prefixed with either ``[PATCH
+   AUTOSEL]`` (for automatically selected patches) or ``[PATCH MANUALSEL]``
+   for manually backported patches.
  - The review committee has 48 hours in which to ACK or NAK the patch.
  - If the patch is rejected by a member of the committee, or linux-kernel
    members object to the patch, bringing up issues that the maintainers and
    members did not realize, the patch will be dropped from the queue.
- - At the end of the review cycle, the ACKed patches will be added to the
-   latest -stable release, and a new -stable release will happen.
+ - The ACKed patches will be posted again as part of release candidate (-rc)
+   to be tested by developers and users willing to test (testers). When
+   testing all went OK, they can give Tested-by: tag for the -rc. Usually
+   only one -rc release is made, however if there are any outstanding
+   issues, some patches may be modified or dropped or additional patches may
+   be queued. Additional -rc releases are then released and tested until no
+   issues are found.
+ - At the end of the review cycle, the new -stable release will be released
+   containing all the queued and tested patches.
  - Security patches will be accepted into the -stable tree directly from the
    security kernel team, and not go through the normal review cycle.
    Contact the kernel security team for more details on this procedure.
-- 
An old man doll... just what I always wanted! - Clara

[PATCH 3/4] Documentation: add link to stable release candidate tree

[Bagas Sanjaya]

There is also stable release candidate tree. Mention it.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: stable@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
---
 Documentation/process/stable-kernel-rules.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
index c0c87d87f7d..523d2d35127 100644
--- a/Documentation/process/stable-kernel-rules.rst
+++ b/Documentation/process/stable-kernel-rules.rst
@@ -183,6 +183,10 @@ Trees
 
 	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
 
+ - The release candidate of all stable kernel versions can be found at:
+
+        https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
+
 
 Review committee
 ----------------
-- 
An old man doll... just what I always wanted! - Clara

[PATCH 4/4] Documentation: update stable tree link

[Bagas Sanjaya]

The link to stable tree is redirected to
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git. Update
accordingly.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Sasha Levin <sashal@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: stable@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
---
 Documentation/process/stable-kernel-rules.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
index 523d2d35127..c242fe1788c 100644
--- a/Documentation/process/stable-kernel-rules.rst
+++ b/Documentation/process/stable-kernel-rules.rst
@@ -181,7 +181,7 @@ Trees
  - The finalized and tagged releases of all stable kernels can be found
    in separate branches per version at:
 
-	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
+	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
 
  - The release candidate of all stable kernel versions can be found at:
 
-- 
An old man doll... just what I always wanted! - Clara

Re: [PATCH 2/4] Documentation: update stable review cycle documentation

[Greg Kroah-Hartman]

On Sat, Mar 12, 2022 at 03:00:41PM +0700, Bagas Sanjaya wrote:
> In recent times, the review cycle for stable releases have been changed.
> In particular, there is release candidate phase between ACKing patches
> and new stable release. Also, in case of failed submissions (fail to
> apply to stable tree), manual backport (Option 3) have to be submitted
> instead.
> 
> Update the release cycle documentation on stable-kernel-rules.rst to
> reflect the above.
> 
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Sasha Levin <sashal@kernel.org>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: stable@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
> ---
>  Documentation/process/stable-kernel-rules.rst | 18 +++++++++++++++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
> index d8ce4c0c775..c0c87d87f7d 100644
> --- a/Documentation/process/stable-kernel-rules.rst
> +++ b/Documentation/process/stable-kernel-rules.rst
> @@ -139,6 +139,9 @@ Following the submission:
>     days, according to the developer's schedules.
>   - If accepted, the patch will be added to the -stable queue, for review by
>     other developers and by the relevant subsystem maintainer.
> + - Some submitted patches may fail to apply to -stable tree. When this is the
> +   case, the maintainer will reply to the sender requesting the backport.

This is tricky, as yes, most of the time this happens, but there are
exceptions.  I would just leave this out for now as I don't think it
helps anyone, right?

> +   If no backport is made, the submission will be ignored.

That's kind of obvious :)


> @@ -147,13 +150,22 @@ Review cycle
>   - When the -stable maintainers decide for a review cycle, the patches will be
>     sent to the review committee, and the maintainer of the affected area of
>     the patch (unless the submitter is the maintainer of the area) and CC: to
> -   the linux-kernel mailing list.
> +   the linux-kernel mailing list. Patches are prefixed with either ``[PATCH
> +   AUTOSEL]`` (for automatically selected patches) or ``[PATCH MANUALSEL]``
> +   for manually backported patches.

These two prefixes are different and not part of the review cycle for
the normal releases.  So that shouldn't go into this list.  Perhaps a
different section?

>   - The review committee has 48 hours in which to ACK or NAK the patch.
>   - If the patch is rejected by a member of the committee, or linux-kernel
>     members object to the patch, bringing up issues that the maintainers and
>     members did not realize, the patch will be dropped from the queue.
> - - At the end of the review cycle, the ACKed patches will be added to the
> -   latest -stable release, and a new -stable release will happen.
> + - The ACKed patches will be posted again as part of release candidate (-rc)

Is this the first place we call it "-rc"?

> +   to be tested by developers and users willing to test (testers). When

No need for "(testers)".

> +   testing all went OK, they can give Tested-by: tag for the -rc. Usually

"testing all went OK" is a bit ackward.  How about this wording instead:
	Responses to the -rc releases can be done on the mailing list by
	sending a "Tested-by:" email with any other testing information
	desired.  The "Tested-by:" tags will be collected and added to
	the release commit.

Thanks for taking this on, it's been a long time since we looked at this
document.

thanks,

greg k-h

Re: [PATCH 4/4] Documentation: update stable tree link

[Greg Kroah-Hartman]

On Sat, Mar 12, 2022 at 03:00:43PM +0700, Bagas Sanjaya wrote:
> The link to stable tree is redirected to
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git. Update
> accordingly.
> 
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Sasha Levin <sashal@kernel.org>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: stable@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
> ---
>  Documentation/process/stable-kernel-rules.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
> index 523d2d35127..c242fe1788c 100644
> --- a/Documentation/process/stable-kernel-rules.rst
> +++ b/Documentation/process/stable-kernel-rules.rst
> @@ -181,7 +181,7 @@ Trees
>   - The finalized and tagged releases of all stable kernels can be found
>     in separate branches per version at:
>  
> -	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> +	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

I should take this change right now as this should have been changed a
while ago.

thanks,

greg k-h

Re: [PATCH 1/4] Documentation: make option lists subsection of "Procedure for submitting patches to the -stable tree" in stable-kernel-rules.rst

[Greg Kroah-Hartman]

On Sat, Mar 12, 2022 at 03:00:40PM +0700, Bagas Sanjaya wrote:
> The table of contents generated for stable-kernel-rules.rst contains
> "For all other submissions..." section, that includes options
> subsections. These options subsections should have been subsections of
> "Procedure for submitting patches..." section. Remove the redundant
> section.

The subject line is really long, was that intentional?

> 
> Also, convert note about security patches to use `.. note::` block.

When you have an "also" that's a huge hint it should be a separate
commit.

thanks,

greg k-h

Re: [PATCH 3/4] Documentation: add link to stable release candidate tree

[Greg Kroah-Hartman]

On Sat, Mar 12, 2022 at 03:00:42PM +0700, Bagas Sanjaya wrote:
> There is also stable release candidate tree. Mention it.
> 
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Sasha Levin <sashal@kernel.org>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: stable@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com>
> ---
>  Documentation/process/stable-kernel-rules.rst | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
> index c0c87d87f7d..523d2d35127 100644
> --- a/Documentation/process/stable-kernel-rules.rst
> +++ b/Documentation/process/stable-kernel-rules.rst
> @@ -183,6 +183,10 @@ Trees
>  
>  	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>  
> + - The release candidate of all stable kernel versions can be found at:
> +
> +        https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
> +

Please add something here that says this tree will be rebased often and
should only be used for testing CI systems to pull from.  It is a
snapshot in time of the stable-queue.git tree and will change
frequently.

In short, I really don't like people using this tree, but have provided
it for those CI systems that don't like dealing with quilt patches only.

I also constantly forget to push the release tags to it, as I'm reminded
frequently :)

thanks,

greg k-h

Re: [PATCH 2/4] Documentation: update stable review cycle documentation

[Bagas Sanjaya]

On 12/03/22 16.40, Greg Kroah-Hartman wrote:
>> diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
>> index d8ce4c0c775..c0c87d87f7d 100644
>> --- a/Documentation/process/stable-kernel-rules.rst
>> +++ b/Documentation/process/stable-kernel-rules.rst
>> @@ -139,6 +139,9 @@ Following the submission:
>>      days, according to the developer's schedules.
>>    - If accepted, the patch will be added to the -stable queue, for review by
>>      other developers and by the relevant subsystem maintainer.
>> + - Some submitted patches may fail to apply to -stable tree. When this is the
>> +   case, the maintainer will reply to the sender requesting the backport.
> 
> This is tricky, as yes, most of the time this happens, but there are
> exceptions.  I would just leave this out for now as I don't think it
> helps anyone, right?
> 

I think wording on option 3 needs to mention backport. Something like: "Option 3
is especially useful if the upstream patch needs to be backported (e.g. needs
special handling due to changed APIs)".

>> @@ -147,13 +150,22 @@ Review cycle
>>    - When the -stable maintainers decide for a review cycle, the patches will be
>>      sent to the review committee, and the maintainer of the affected area of
>>      the patch (unless the submitter is the maintainer of the area) and CC: to
>> -   the linux-kernel mailing list.
>> +   the linux-kernel mailing list. Patches are prefixed with either ``[PATCH
>> +   AUTOSEL]`` (for automatically selected patches) or ``[PATCH MANUALSEL]``
>> +   for manually backported patches.
> 
> These two prefixes are different and not part of the review cycle for
> the normal releases.  So that shouldn't go into this list.  Perhaps a
> different section?
> 

I think these prefixes **are** part of review cycle; in fact these patches
which get ACKed will be part of -rc for stable release.

>>    - The review committee has 48 hours in which to ACK or NAK the patch.
>>    - If the patch is rejected by a member of the committee, or linux-kernel
>>      members object to the patch, bringing up issues that the maintainers and
>>      members did not realize, the patch will be dropped from the queue.
>> - - At the end of the review cycle, the ACKed patches will be added to the
>> -   latest -stable release, and a new -stable release will happen.
>> + - The ACKed patches will be posted again as part of release candidate (-rc)
> 
> Is this the first place we call it "-rc"?

Yes.
> 
>> +   to be tested by developers and users willing to test (testers). When
> 
> No need for "(testers)".
> 

So we can just say "developers and testers", right?

>> +   testing all went OK, they can give Tested-by: tag for the -rc. Usually
> 
> "testing all went OK" is a bit ackward.  How about this wording instead:
> 	Responses to the -rc releases can be done on the mailing list by
> 	sending a "Tested-by:" email with any other testing information
> 	desired.  The "Tested-by:" tags will be collected and added to
> 	the release commit.
> 

OK, will apply.

-- 
An old man doll... just what I always wanted! - Clara

Re: [PATCH 1/4] Documentation: make option lists subsection of "Procedure for submitting patches to the -stable tree" in stable-kernel-rules.rst

[Bagas Sanjaya]

On 12/03/22 16.42, Greg Kroah-Hartman wrote:
> On Sat, Mar 12, 2022 at 03:00:40PM +0700, Bagas Sanjaya wrote:
>> The table of contents generated for stable-kernel-rules.rst contains
>> "For all other submissions..." section, that includes options
>> subsections. These options subsections should have been subsections of
>> "Procedure for submitting patches..." section. Remove the redundant
>> section.
> 
> The subject line is really long, was that intentional?
> 

Yes, because I have to spell the full section name the option lists
I moved to.

>>
>> Also, convert note about security patches to use `.. note::` block.
> 
> When you have an "also" that's a huge hint it should be a separate
> commit.
> 

OK, will split.

-- 
An old man doll... just what I always wanted! - Clara