Message-ID: <2023071017-ferocity-chooser-427b@gregkh>
Date:   Mon, 10 Jul 2023 21:44:54 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Thorsten Leemhuis <linux@...mhuis.info>
Cc:     stable@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, Sasha Levin <sashal@...nel.org>,
        Jonathan Corbet <corbet@....net>
Subject: Re: [RFC PATCH v1 2/3] docs: stable-kernel-rules: make rule section
 more straight forward

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@...uxfoundation.org>
> CC: Sasha Levin <sashal@...nel.org>
> CC: Jonathan Corbet <corbet@....net>
> Signed-off-by: Thorsten Leemhuis <linux@...mhuis.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

Powered by blists - more mailing lists