Doc/stable rules: add new cherry-pick logic
- it is possible to submit patches for the stable queue without sending them directly stable@kernel.org. If the tag (Cc: stable@kernel.org) is available in the sign-off area than hpa's script will filter them into the stable mailbox once it hits Linus' tree. - Patches which require others to be applied first can be also specified. This was discussued in http://lkml.org/lkml/2009/11/9/474 Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Cc: Brandon Philips <brandon@ifup.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This commit is contained in:
parent
9329d1beae
commit
8e9b936226
@ -26,13 +26,33 @@ Procedure for submitting patches to the -stable tree:
|
|||||||
|
|
||||||
- Send the patch, after verifying that it follows the above rules, to
|
- Send the patch, after verifying that it follows the above rules, to
|
||||||
stable@kernel.org.
|
stable@kernel.org.
|
||||||
|
- To have the patch automatically included in the stable tree, add the
|
||||||
|
the tag
|
||||||
|
Cc: stable@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: <stable@kernel.org> # .32.x: a1f84a3: sched: Check for idle
|
||||||
|
Cc: <stable@kernel.org> # .32.x: 1b9508f: sched: Rate-limit newidle
|
||||||
|
Cc: <stable@kernel.org> # .32.x: fd21073: sched: Fix affinity logic
|
||||||
|
Cc: <stable@kernel.org> # .32.x
|
||||||
|
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
||||||
|
|
||||||
|
The tag sequence has the meaning of:
|
||||||
|
git cherry-pick a1f84a3
|
||||||
|
git cherry-pick 1b9508f
|
||||||
|
git cherry-pick fd21073
|
||||||
|
git cherry-pick <this commit>
|
||||||
|
|
||||||
- The sender will receive an ACK when the patch has been accepted into the
|
- 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
|
queue, or a NAK if the patch is rejected. This response might take a few
|
||||||
days, according to the developer's schedules.
|
days, according to the developer's schedules.
|
||||||
- If accepted, the patch will be added to the -stable queue, for review by
|
- If accepted, the patch will be added to the -stable queue, for review by
|
||||||
other developers and by the relevant subsystem maintainer.
|
other developers and by the relevant subsystem maintainer.
|
||||||
- If the stable@kernel.org address is added to a patch, when it goes into
|
|
||||||
Linus's tree it will automatically be emailed to the stable team.
|
|
||||||
- Security patches should not be sent to this alias, but instead to the
|
- Security patches should not be sent to this alias, but instead to the
|
||||||
documented security@kernel.org address.
|
documented security@kernel.org address.
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user