lkml.org 
[lkml]   [2022]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 2/4] Documentation: update stable review cycle documentation
From
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

\
 
 \ /
  Last update: 2022-03-14 07:37    [W:0.039 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site