From e5fd91f1ef340da553f7a79da9540c3db711c937 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Fabian=20Silva=20Delgado?= Date: Tue, 8 Sep 2015 01:01:14 -0300 Subject: Linux-libre 4.2-gnu --- Documentation/stable_kernel_rules.txt | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) (limited to 'Documentation/stable_kernel_rules.txt') diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt index 58d0ac4df..3049a6122 100644 --- a/Documentation/stable_kernel_rules.txt +++ b/Documentation/stable_kernel_rules.txt @@ -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 it to be applied to. -Option 1 is probably the easiest and most common. Options 2 and 3 are more -useful if the patch isn't deemed worthy at the time it is applied to a public -git tree (for instance, because it deserves more regression testing first). -Option 3 is especially useful if the patch needs some special handling to apply -to an older kernel (e.g., if API's have changed in the meantime). +Option 1 is *strongly* preferred, is the easiest and most common. Options 2 and +3 are more useful if the patch isn't deemed worthy at the time it is applied to +a public git tree (for instance, because it deserves more regression testing +first). Option 3 is especially useful if the patch needs some special handling +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 upstream. Additionally, some patches submitted via Option 1 may have additional patch prerequisites which can be cherry-picked. This can be specified in the following -- cgit v1.2.3