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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YixqnPTe0Wr6E1G3@kroah.com>
Date:   Sat, 12 Mar 2022 10:40:44 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Bagas Sanjaya <bagasdotme@...il.com>
Cc:     linux-doc@...r.kernel.org, Sasha Levin <sashal@...nel.org>,
        Jonathan Corbet <corbet@....net>, stable@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [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 <gregkh@...uxfoundation.org>
> Cc: Sasha Levin <sashal@...nel.org>
> Cc: Jonathan Corbet <corbet@....net>
> Cc: stable@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org
> Signed-off-by: Bagas Sanjaya <bagasdotme@...il.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