Skip to content

Commit

Permalink
docs: stable-kernel-rules: make rule section more straight forward
Browse files Browse the repository at this point in the history
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 upstream" 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.
* drop the 'In short, something critical' from one of those notes: it
  contradicts the "real bug that bothers people" aspect somewhat and does
  not really add anything

CC: Greg KH <[email protected]>
CC: Sasha Levin <[email protected]>
CC: Jonathan Corbet <[email protected]>
Signed-off-by: Thorsten Leemhuis <[email protected]>
Link: https://lore.kernel.org/r/f83e812879caa978a51a1a7cae7c359f29fc093c.1689056247.git.linux@leemhuis.info
Signed-off-by: Greg Kroah-Hartman <[email protected]>
  • Loading branch information
knurd authored and gregkh committed Aug 5, 2023
1 parent d0bde9c commit 3356855
Showing 1 changed file with 18 additions and 20 deletions.
38 changes: 18 additions & 20 deletions Documentation/process/stable-kernel-rules.rst
Original file line number Diff line number Diff line change
Expand Up @@ -6,31 +6,29 @@ 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.
- 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
----------------------------------------------------
Expand Down

0 comments on commit 3356855

Please sign in to comment.