mirrors/linux-stable
1
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git synced 2024-09-29 13:53:33 +00:00
Code Issues Releases Wiki Activity

stable: Update documentation to clarify preferred procedure

Browse source 
Clearly specify that "Cc: stable@vger.kernel.org" is strongly preferred so
that developers understand that the other options should only be used when
absolutely required.

Also specify how upstream commit ids should be referenced in patches
submitted directly to stable (I gathered this from looking at the stable
archives), and specify that any modified patches for stable should be
clearly documented in the patch description.

Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Christoffer Dall 2015-05-13 22:01:07 +02:00 committed by Jonathan Corbet
parent cbfa2c5281
commit bde1b29420
1 changed files with 14 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
Documentation/stable_kernel_rules.txt
View file

@ -59,11 +59,20 @@ For all other submissions, choose one of the following procedures:
changelog of your submission, as well as the kernel version you wish changelog of your submission, as well as the kernel version you wish
it to be applied to. it to be applied to.
Option 1 is probably the easiest and most common. Options 2 and 3 are more Option 1 is *strongly* preferred, is the easiest and most common. Options 2 and
useful if the patch isn't deemed worthy at the time it is applied to a public 3 are more useful if the patch isn't deemed worthy at the time it is applied to
git tree (for instance, because it deserves more regression testing first). a public git tree (for instance, because it deserves more regression testing
Option 3 is especially useful if the patch needs some special handling to apply first). Option 3 is especially useful if the patch needs some special handling
to an older kernel (e.g., if API's have changed in the meantime). to apply to an older kernel (e.g., if API's have changed in the meantime).
Note that for Option 3, if the patch deviates from the original upstream patch
(for example because it had to be backported) this must be very clearly
documented and justified in the patch description.
The upstream commit ID must be specified with a separate line above the commit
text, like this:
commit <sha1> upstream.
Additionally, some patches submitted via Option 1 may have additional patch Additionally, some patches submitted via Option 1 may have additional patch
prerequisites which can be cherry-picked. This can be specified in the following prerequisites which can be cherry-picked. This can be specified in the following