[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4611d0fb-c8a2-8f23-ad6d-9c28b216a105@gmail.com>
Date: Mon, 14 Mar 2022 13:37:21 +0700
From: Bagas Sanjaya <bagasdotme@...il.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
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 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
Powered by blists - more mailing lists