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
