Re: [RFC PATCH v1 2/3] docs: stable-kernel-rules: make rule section more straight forward

Greg KH
2023-07-10T19:45:00Z

On Mon, Jul 10, 2023 at 07:10:12PM +0200, Thorsten Leemhuis wrote:
> Tweak some of the rule text to make things more straight forward, with
> the goal to stick closely to the intend of the old text:
>
> * put the "it or equivalent fix must be ustream" rule at the top, as
> it's one of the most important ones that at the same time often seems
> to be missed by developers.
> * "It must fix only one thing" was dropped, as that is almost always a
> thing that needs to be handled earlier when the change is mainlined.
> Furthermore, this is already indirectly covered by the "Separate your
> changes" section in Documentation/process/submitting-patches.rst which
> the rules already point to.
> * six other rules are in the end one rule with clarifications; structure
> the text accordingly to make it a lot easier to follow and understand
> the intend.
>
> CC: Greg KH <gregkh@linuxfoundation.org>
> CC: Sasha Levin <sashal@kernel.org>
> CC: Jonathan Corbet <corbet@lwn.net>
> Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
> ---
> Documentation/process/stable-kernel-rules.rst | 39 +++++++++----------
> 1 file changed, 19 insertions(+), 20 deletions(-)
>
> diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
> index 6e4026dd6882..85d5d2368034 100644
> --- a/Documentation/process/stable-kernel-rules.rst
> +++ b/Documentation/process/stable-kernel-rules.rst
> @@ -6,31 +6,30 @@ Everything you ever wanted to know about Linux -stable releases
> Rules on what kind of patches are accepted, and which ones are not, into the
> "-stable" tree:
>
> + - It or an equivalent fix must already exist in Linus' tree (upstream).
> - It must be obviously correct and tested.
> - It cannot be bigger than 100 lines, with context.
> - - It must fix only one thing.
> - - It must fix a real bug that bothers people (not a, "This could be a
> - problem..." type thing).
> - - It must fix a problem that causes a build error (but not for things
> - marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
> - security issue, or some "oh, that's not good" issue. In short, something
> - critical.
> - - Serious issues as reported by a user of a distribution kernel may also
> - be considered if they fix a notable performance or interactivity issue.
> - As these fixes are not as obvious and have a higher risk of a subtle
> - regression they should only be submitted by a distribution kernel
> - maintainer and include an addendum linking to a bugzilla entry if it
> - exists and additional information on the user-visible impact.
> - - New device IDs and quirks are also accepted.
> - - No "theoretical race condition" issues, unless an explanation of how the
> - race can be exploited is also provided.
> - - It cannot contain any "trivial" fixes in it (spelling changes,
> - whitespace cleanups, etc).
> - It must follow the
> :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
> rules.
> - - It or an equivalent fix must already exist in Linus' tree (upstream).
> -
> + - It must either fix a real bug that bothers people or just add a device ID.
> + To elaborate on the former:
> +
> + - It fixes a problem like an oops, a hang, data corruption, a real security
> + issue, a hardware quirk, a build error (but not for things marked
> + CONFIG_BROKEN), or some "oh, that's not good" issue. In short, something
> + critical.
> + - Serious issues as reported by a user of a distribution kernel may also
> + be considered if they fix a notable performance or interactivity issue.
> + As these fixes are not as obvious and have a higher risk of a subtle
> + regression they should only be submitted by a distribution kernel
> + maintainer and include an addendum linking to a bugzilla entry if it
> + exists and additional information on the user-visible impact.
> + - No "This could be a problem..." type of things like a "theoretical race
> + condition", unless an explanation of how the bug can be exploited is also
> + provided.
> + - No "trivial" fixes without benefit for users (spelling changes, whitespace
> + cleanups, etc).
>
> Procedure for submitting patches to the -stable tree
> ----------------------------------------------------

Ah, it's nice to see that mainline also enforces the "must do one
thing", I think when I originally wrote this, it didn't :)

Again, all looks great to me, I'll be glad to take it.

thanks,

greg k-h