Paul Gortmaker | 2584f52 | 2012-06-05 11:15:50 -0400 | [diff] [blame] | 1 | Everything you ever wanted to know about Linux -stable releases. |
Greg KH | fc185d9 | 2005-07-29 12:14:34 -0700 | [diff] [blame] | 2 | |
Jesper Juhl | e48e990 | 2006-01-09 20:53:59 -0800 | [diff] [blame] | 3 | Rules on what kind of patches are accepted, and which ones are not, into the |
| 4 | "-stable" tree: |
Greg KH | fc185d9 | 2005-07-29 12:14:34 -0700 | [diff] [blame] | 5 | |
| 6 | - It must be obviously correct and tested. |
Matt LaPlante | 84eb8d0 | 2006-10-03 22:53:09 +0200 | [diff] [blame] | 7 | - It cannot be bigger than 100 lines, with context. |
Greg KH | fc185d9 | 2005-07-29 12:14:34 -0700 | [diff] [blame] | 8 | - It must fix only one thing. |
| 9 | - It must fix a real bug that bothers people (not a, "This could be a |
Jesper Juhl | e48e990 | 2006-01-09 20:53:59 -0800 | [diff] [blame] | 10 | problem..." type thing). |
Greg KH | fc185d9 | 2005-07-29 12:14:34 -0700 | [diff] [blame] | 11 | - It must fix a problem that causes a build error (but not for things |
| 12 | marked CONFIG_BROKEN), an oops, a hang, data corruption, a real |
Jesper Juhl | e48e990 | 2006-01-09 20:53:59 -0800 | [diff] [blame] | 13 | security issue, or some "oh, that's not good" issue. In short, something |
| 14 | critical. |
Mel Gorman | 8191e0d | 2012-06-21 11:36:50 +0100 | [diff] [blame] | 15 | - Serious issues as reported by a user of a distribution kernel may also |
| 16 | be considered if they fix a notable performance or interactivity issue. |
| 17 | As these fixes are not as obvious and have a higher risk of a subtle |
| 18 | regression they should only be submitted by a distribution kernel |
| 19 | maintainer and include an addendum linking to a bugzilla entry if it |
| 20 | exists and additional information on the user-visible impact. |
Josh Boyer | 79cd80a | 2008-10-24 10:10:42 -0400 | [diff] [blame] | 21 | - New device IDs and quirks are also accepted. |
Jesper Juhl | e48e990 | 2006-01-09 20:53:59 -0800 | [diff] [blame] | 22 | - No "theoretical race condition" issues, unless an explanation of how the |
| 23 | race can be exploited is also provided. |
Matt LaPlante | 84eb8d0 | 2006-10-03 22:53:09 +0200 | [diff] [blame] | 24 | - It cannot contain any "trivial" fixes in it (spelling changes, |
Jesper Juhl | e48e990 | 2006-01-09 20:53:59 -0800 | [diff] [blame] | 25 | whitespace cleanups, etc). |
Jesper Juhl | e48e990 | 2006-01-09 20:53:59 -0800 | [diff] [blame] | 26 | - It must follow the Documentation/SubmittingPatches rules. |
Stefan Richter | 959fb1c | 2010-04-01 22:01:52 +0200 | [diff] [blame] | 27 | - It or an equivalent fix must already exist in Linus' tree (upstream). |
Greg KH | fc185d9 | 2005-07-29 12:14:34 -0700 | [diff] [blame] | 28 | |
| 29 | |
| 30 | Procedure for submitting patches to the -stable tree: |
| 31 | |
Dave Chiluk | b76fc28 | 2014-06-24 10:11:26 -0500 | [diff] [blame] | 32 | - If the patch covers files in net/ or drivers/net please follow netdev stable |
| 33 | submission guidelines as described in |
| 34 | Documentation/networking/netdev-FAQ.txt |
Brian Norris | 5de61e7 | 2014-12-18 14:55:53 -0800 | [diff] [blame] | 35 | - Security patches should not be handled (solely) by the -stable review |
| 36 | process but should follow the procedures in Documentation/SecurityBugs. |
| 37 | |
| 38 | For all other submissions, choose one of the following procedures: |
| 39 | |
| 40 | --- Option 1 --- |
| 41 | |
| 42 | To have the patch automatically included in the stable tree, add the tag |
Josh Boyer | 5fa2242 | 2011-10-17 21:16:39 -0400 | [diff] [blame] | 43 | Cc: stable@vger.kernel.org |
Sebastian Andrzej Siewior | 8e9b936 | 2009-12-06 12:24:31 +0100 | [diff] [blame] | 44 | in the sign-off area. Once the patch is merged it will be applied to |
| 45 | the stable tree without anything else needing to be done by the author |
| 46 | or subsystem maintainer. |
Brian Norris | 5de61e7 | 2014-12-18 14:55:53 -0800 | [diff] [blame] | 47 | |
| 48 | --- Option 2 --- |
| 49 | |
| 50 | After the patch has been merged to Linus' tree, send an email to |
| 51 | stable@vger.kernel.org containing the subject of the patch, the commit ID, |
| 52 | why you think it should be applied, and what kernel version you wish it to |
| 53 | be applied to. |
| 54 | |
| 55 | --- Option 3 --- |
| 56 | |
| 57 | Send the patch, after verifying that it follows the above rules, to |
| 58 | stable@vger.kernel.org. You must note the upstream commit ID in the |
| 59 | changelog of your submission, as well as the kernel version you wish |
| 60 | it to be applied to. |
| 61 | |
| 62 | Option 1 is probably the easiest and most common. Options 2 and 3 are more |
| 63 | useful if the patch isn't deemed worthy at the time it is applied to a public |
| 64 | git tree (for instance, because it deserves more regression testing first). |
| 65 | Option 3 is especially useful if the patch needs some special handling to apply |
| 66 | to an older kernel (e.g., if API's have changed in the meantime). |
| 67 | |
| 68 | Additionally, some patches submitted via Option 1 may have additional patch |
| 69 | prerequisites which can be cherry-picked. This can be specified in the following |
| 70 | format in the sign-off area: |
Sebastian Andrzej Siewior | 8e9b936 | 2009-12-06 12:24:31 +0100 | [diff] [blame] | 71 | |
Paul Gortmaker | 2584f52 | 2012-06-05 11:15:50 -0400 | [diff] [blame] | 72 | Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle |
| 73 | Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle |
| 74 | Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic |
| 75 | Cc: <stable@vger.kernel.org> # 3.3.x |
Sebastian Andrzej Siewior | 8e9b936 | 2009-12-06 12:24:31 +0100 | [diff] [blame] | 76 | Signed-off-by: Ingo Molnar <mingo@elte.hu> |
| 77 | |
| 78 | The tag sequence has the meaning of: |
| 79 | git cherry-pick a1f84a3 |
| 80 | git cherry-pick 1b9508f |
| 81 | git cherry-pick fd21073 |
| 82 | git cherry-pick <this commit> |
| 83 | |
Brian Norris | 5de61e7 | 2014-12-18 14:55:53 -0800 | [diff] [blame] | 84 | Following the submission: |
| 85 | |
Jesper Juhl | e48e990 | 2006-01-09 20:53:59 -0800 | [diff] [blame] | 86 | - The sender will receive an ACK when the patch has been accepted into the |
| 87 | queue, or a NAK if the patch is rejected. This response might take a few |
| 88 | days, according to the developer's schedules. |
| 89 | - If accepted, the patch will be added to the -stable queue, for review by |
Stefan Richter | 46cdf871 | 2008-02-08 23:26:02 +0100 | [diff] [blame] | 90 | other developers and by the relevant subsystem maintainer. |
Greg KH | fc185d9 | 2005-07-29 12:14:34 -0700 | [diff] [blame] | 91 | |
| 92 | |
| 93 | Review cycle: |
| 94 | |
Jesper Juhl | e48e990 | 2006-01-09 20:53:59 -0800 | [diff] [blame] | 95 | - When the -stable maintainers decide for a review cycle, the patches will be |
| 96 | sent to the review committee, and the maintainer of the affected area of |
| 97 | the patch (unless the submitter is the maintainer of the area) and CC: to |
| 98 | the linux-kernel mailing list. |
| 99 | - The review committee has 48 hours in which to ACK or NAK the patch. |
Greg KH | fc185d9 | 2005-07-29 12:14:34 -0700 | [diff] [blame] | 100 | - If the patch is rejected by a member of the committee, or linux-kernel |
Jesper Juhl | e48e990 | 2006-01-09 20:53:59 -0800 | [diff] [blame] | 101 | members object to the patch, bringing up issues that the maintainers and |
| 102 | members did not realize, the patch will be dropped from the queue. |
| 103 | - At the end of the review cycle, the ACKed patches will be added to the |
| 104 | latest -stable release, and a new -stable release will happen. |
| 105 | - Security patches will be accepted into the -stable tree directly from the |
| 106 | security kernel team, and not go through the normal review cycle. |
Greg KH | fc185d9 | 2005-07-29 12:14:34 -0700 | [diff] [blame] | 107 | Contact the kernel security team for more details on this procedure. |
| 108 | |
Paul Gortmaker | 2584f52 | 2012-06-05 11:15:50 -0400 | [diff] [blame] | 109 | Trees: |
| 110 | |
| 111 | - The queues of patches, for both completed versions and in progress |
| 112 | versions can be found at: |
| 113 | http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git |
| 114 | - The finalized and tagged releases of all stable kernels can be found |
| 115 | in separate branches per version at: |
| 116 | http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git |
| 117 | |
Greg KH | fc185d9 | 2005-07-29 12:14:34 -0700 | [diff] [blame] | 118 | |
Matt LaPlante | 5d3f083 | 2006-11-30 05:21:10 +0100 | [diff] [blame] | 119 | Review committee: |
Greg KH | fc185d9 | 2005-07-29 12:14:34 -0700 | [diff] [blame] | 120 | |
Jesper Juhl | e48e990 | 2006-01-09 20:53:59 -0800 | [diff] [blame] | 121 | - This is made up of a number of kernel developers who have volunteered for |
| 122 | this task, and a few that haven't. |