From: Greg Kroah-Hartman Date: Wed, 5 Jul 2017 12:43:46 +0000 (+0200) Subject: delete rules.txt: It's not needed X-Git-Tag: v4.9.37~48 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=0542d210954661ba4bd72b92fb2f1b12df25e53c;p=thirdparty%2Fkernel%2Fstable-queue.git delete rules.txt: It's not needed The "real" list is in Documentation/process/stable-kernel-rules.txt in the kernel source tree, so just use that instead of this one. Signed-off-by: Greg Kroah-Hartman --- diff --git a/rules.txt b/rules.txt deleted file mode 100644 index b0714d8f678..00000000000 --- a/rules.txt +++ /dev/null @@ -1,95 +0,0 @@ -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 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 Documentation/SubmittingPatches rules. - - It or an equivalent fix must already exist in Linus' tree (upstream). - - -Procedure for submitting patches to the -stable tree: - - - Send the patch, after verifying that it follows the above rules, to - stable@vger.kernel.org. You must note the upstream commit ID in the - changelog of your submission, as well as the kernel version you wish - it to be applied to. - - To have the patch automatically included in the stable tree, add the tag - Cc: stable@vger.kernel.org - in the sign-off area. Once the patch is merged it will be applied to - the stable tree without anything else needing to be done by the author - or subsystem maintainer. - - If the patch requires other patches as prerequisites which can be - cherry-picked than this can be specified in the following format in - the sign-off area: - - Cc: # 3.3.x: a1f84a3: sched: Check for idle - Cc: # 3.3.x: 1b9508f: sched: Rate-limit newidle - Cc: # 3.3.x: fd21073: sched: Fix affinity logic - Cc: # 3.3.x - Signed-off-by: Ingo Molnar - - The tag sequence has the meaning of: - git cherry-pick a1f84a3 - git cherry-pick 1b9508f - git cherry-pick fd21073 - git cherry-pick - - - The sender will receive an ACK when the patch has been accepted into the - queue, or a NAK if the patch is rejected. This response might take a few - days, according to the developer's schedules. - - If accepted, the patch will be added to the -stable queue, for review by - other developers and by the relevant subsystem maintainer. - - Security patches should not be sent to this alias, but instead to the - documented security@kernel.org address. - - -Review cycle: - - - When the -stable maintainers decide for a review cycle, the patches will be - sent to the review committee, and the maintainer of the affected area of - the patch (unless the submitter is the maintainer of the area) and CC: to - the linux-kernel mailing list. - - The review committee has 48 hours in which to ACK or NAK the patch. - - If the patch is rejected by a member of the committee, or linux-kernel - members object to the patch, bringing up issues that the maintainers and - members did not realize, the patch will be dropped from the queue. - - At the end of the review cycle, the ACKed patches will be added to the - latest -stable release, and a new -stable release will happen. - - Security patches will be accepted into the -stable tree directly from the - security kernel team, and not go through the normal review cycle. - Contact the kernel security team for more details on this procedure. - -Trees: - - - The queues of patches, for both completed versions and in progress - versions can be found at: - http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git - - The finalized and tagged releases of all stable kernels can be found - in separate branches per version at: - http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git - - -Review committee: - - - This is made up of a number of kernel developers who have volunteered for - this task, and a few that haven't.