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

[Bagas Sanjaya]

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