[lkml]   [2022]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/4] Documentation: update stable review cycle documentation
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 <>
> Cc: Sasha Levin <>
> Cc: Jonathan Corbet <>
> Cc:
> Cc:
> Signed-off-by: Bagas Sanjaya <>
> ---
> 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


greg k-h

 \ /
  Last update: 2022-03-12 10:41    [W:0.107 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site