Ubuntu Wiki

Stable Patch Format

Subject Line

1. Every patch must have the release name against which the patch is targeted in it's subject line. That release name must be the first string in the subject line and must be enclosed in "[ ]" brackets.

   Example:

    [Lucid][pull request] Update to 2.6.32.16 Stable Kernel

2. Every patch request must contain one of the following on the Subject line after the release name string described previously:

   Descriptor	Meaning
   UBUNTU:	This is a patch to the Ubuntu Packaging this includes the contents of the various debian directories (where not covered by a more specific categorisation)
   UBUNTU: [Config]	This is an update to the kernel configuration as recorded in the debian.<branch>/config directory
   UBUNTU: ubuntu:	This is an update to an Ubuntu specific driver in the ubuntu directory.
   UBUNTU: SAUCE:	This is a patch that the submitter has authored and is not yet upstream. The patch likely has been submitted to upstream but is of enough value for Ubuntu to carry it in our tree regardeless of upstream acceptance.
   UBUNTU: SAUCE: (no-up)	This patch is never expected to go upstream but is of enough value for Ubuntu to carry it in our tree. It is very unlikely that any stable patches will have this.
   (pre-stable)	This patch is taken from the stable queue and is expected to eventually be replaced by a patch from a stable release.
   (upstream)	This patch is either developed by an Ubuntu kernel developer or is taken from an upstream maintainers tree and is expected to eventually be replaced by a patch from a mainline tree.

   Notes:

   1. The UBUNTU: prefix triggers the commit to be listed by author in the changelog, can be thought of as meaning submitted by the author

   Example:

    [Lucid][pull request] (pre-stable) Blank screen with KMS on Thinkpad X201 with Arrandale (i915)

Comment Body

1. Every patch which is associated with a launchpad bug must have a link to the bug in the commit's comment section in the form of a "BugLink" block. A "BugLink" block must immediately follow the subject line and be the first text in the body of the commit comment. A "BugLink" block consists of:

   1. A blank line.

   2. One or more lines containing "BugLink:" and a url to the launchpad bug. That url must be of the format: "http://bugs.launchpad.net/bugs/<bug-id>" where <bug-id> is the bug number of the associated Launchpad bug.

   3. Another blank line.

   Every stable patch must have an associated Launchpad bug for tracking by the kernel stable and SRU teams.

   Example:

    1: Subject: [PATCH] UBUNTU: SAUCE: Add thinkpad-acpi to modules in the ALSA subpackage
    2:
    3: BugLink: http://bugs.launchpad.net/bugs/599527
    4: BugLink: http://bugs.launchpad.net/bugs/123456
    5:

2. Every patch must have a "Signed-off-by" line for the person that is submitting the patch. This "Signed-off-by" line must follow all other provinence lines and should be the last line in the commit comment.

   Example:

    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    (backported from commit 5620ae29f1eabe655f44335231b580a78c8364ea upstream)
    Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>

3. Where acks are needed they should be placed in the provinence block. Every patch against Development releases following Kernel freeze and all patches against released kernels must have two "Ack-by" replies by "senior" members of the Ubuntu Kernel Team. "Senior" members of the kernel team are the members of the kernel_cdev group on zinc.

    $ getent group kernel_cdev
    kernel_cdev:x:2616:rtg,amitk,ogasawara,smb,cking,sconklin,apw

   Example:

    Signed-off-by: Adam Jackson <ajax@redhat.com>
    Signed-off-by: Eric Anholt <eric@anholt.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    (cherry-picked from commit d4e0018e3e4dd685af25d300fd26a0d5a984482e 2.6.34.y)
    Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
    Acked-by: Tim Gardner <tim.gardner@canonical.com>
    Acked-by: Brad Figg <brad.figg@canonical.com>
    Acked-by: Steve Conklin <sconklin@canonical.com>

4. Every patch must display the provenance of the patch. We want to preserve where the patch came from, who signed off on it, who ack'd it, whether it was cherry-picked from upstream or backported from an upstream commit and who finally applied it to an official Ubuntu source tree.

   If the patch required backporting or changes, there should be a brief explanation immediately preceeding the original commit text and immediately after the "BugLink" block. There must also be a line in the provenance section in the format:

    (backported from commit <sha1> <upstream repo name>)

   Please note that the opening and closing parenthesis are required.

   If tthe patch is a simple cherry-pick from an upstream repo that must also be spelled out in the provenance section in the form:

    (cherry-pick from commit <sha1> <upstream repo name>)

   And the opening and closing parenthesis are required here as well.

   Example:

    Signed-off-by: Adam Jackson <ajax@redhat.com>
    Signed-off-by: Eric Anholt <eric@anholt.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    (cherry-picked from commit d4e0018e3e4dd685af25d300fd26a0d5a984482e 2.6.34.y)
    Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
    Acked-by: Tim Gardner <tim.gardner@canonical.com>
    Acked-by: Brad Figg <brad.figg@canonical.com>
    Acked-by: Steve Conklin <sconklin@canonical.com>

Complete Example

•  From f71ea7e15129435a07c4e4d0bc08be19e2d0415c Mon Sep 17 00:00:00 2001
   From: Steve Conklin <sconklin@canonical.com>
   Date: Thu, 29 Jul 2010 16:43:14 -0500
   Subject: (pre-stable) drm/i915: make sure eDP panel is turned on
   
   BugLink: http://bugs.launchpad.net/bugs/578673
   
   Small modifications needed because of avariable rename.
   
   When enabling the eDP port, we need to make sure the panel is turned on
   after training the link.  If we don't, it likely won't come back after
   suspend or may not come up at all.
   
   For unknown reasons, unlocking the panel regs before initiating a power
   on sequence is necessary.  There are known bugs in the PCH panel
   sequencing logic, apparently this is one possible workaround.
   
   Fixes https://bugs.freedesktop.org/show_bug.cgi?id=28739.
   
   OriginalAuthor: Jesse Barnes <jbarnes@virtuousgeek.org>
   Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
   Tested-by: "Paulo J. S. Silva" <pjssilva@gmail.com>
   Signed-off-by: Eric Anholt <eric@anholt.net>
   (backported from commit c9fcc5d269949a0fbd46ffbea6cc83741e61c05f upstream)
   Acked-by: Brad Figg <brad.figg@canonical.com>
   Acked-by: Steve Conklin <sconklin@canonical.com>
   Signed-off-by: Steve Conklin <sconklin@canonical.com>