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@xxxxxxxxxxxxxxxxxxx> > CC: Sasha Levin <sashal@xxxxxxxxxx> > CC: Jonathan Corbet <corbet@xxxxxxx> > Signed-off-by: Thorsten Leemhuis <linux@xxxxxxxxxxxxx> > --- > 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
