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

[Bagas Sanjaya <bagasdotme@gmail.com>]

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