StablePatchFormat

Differences between revisions 6 and 28 (spanning 22 versions)
Revision 6 as of 2010-08-06 17:02:37
Size: 6171
Editor: pool-98-108-155-157
Comment:
Revision 28 as of 2022-07-07 08:36:42
Size: 9739
Editor: kleber-souza
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Line 4: Line 3:
=== Destination ===

Stable patches must be sent to:
kernel-team@lists.ubuntu.com
Line 6: Line 10:
 1. Every stable 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
 }}}

 1. 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 that the submitter has authored and is not yet upstream. The patch has been submitted to upstream but is of enough value for Ubuntu to carry it in our tree regardelss of upstream acceptance. ||
    || UBUNTU SAUCE || 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. ||

    '''Example:'''
    {{{
    [Lucid][pull request] (pre-stable) Blank screen with KMS on Thinkpad X201 with Arrandale (i915)
    }}}
 1. Every patch submitted to a stable kernel '''must''' have have its subject line starting with "[SRU]" followed by the release name against which the patch is targeted. That release name '''must''' be enclosed in "[ ]" brackets and '''can''' be abbreviated using the first letter of the release name (e.g. "B" for "Bionic"). If a patch is to be applied to multiple releases a list of release names can be provided.

 '''Examples:'''
 {{{
 [SRU][Focal][PULL] Focal update: v5.4.56 upstream stable release
 [SRU][B][F][PATCH 1/1] KVM: fix overflow of zero page refcount with ksm running
 }}}

 1. If the patch requested doesn't come from the mainline tree it '''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 regardless 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. ||
 || UBUNTU: [Debian] || This patch changes the debian rules files (debian/rules, debian*/rules.d/* and possibly debian*/control and debian*/control.d/*). ||
 || (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. ||

 '''Example:'''
 {{{
 [SRU][FOCAL][PATCH 2/2] UBUNTU: SAUCE: shiftfs: prevent ESTALE for LOOKUP_JUMP lookups
 }}}
Line 27: Line 37:
 1. Every stable patch '''must''' have an associated Launchpad bug and that bug should be part of 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. 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:
Line 29: Line 39:
   1. A line 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.    1. One or more lines containing "BugLink:" and a url to the launchpad bug. That url '''must''' be of the format: "https://bugs.launchpad.net/bugs/<bug-id>" where <bug-id> is the bug number of the associated Launchpad bug.
Line 32: Line 42:
    '''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:
   
}}}

 1. Every stable 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>
    }}}

 1. Every stable patch '''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>
    }}}
 Every stable patch '''must''' have an associated Launchpad bug for tracking by the kernel stable and SRU teams. Exceptions are patches for CVE fixes (see below).

 '''Example:'''
{{{
 1: Subject: [PATCH 1/1][SRU][B] UBUNTU: SAUCE: platform/x86: dell-uart-backlight: add get_display_mode command
 2:
 3: Bug
Link: https://bugs.launchpad.net/bugs/1865402
 4: BugLink: https://bugs.launchpad.net/bugs/1234
567
 5:
}}}

 1. 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 provenance 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)
 Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
 }}}

 1. Where acks are needed they should be placed in the provenance block. Every patch against Development releases following Kernel freeze and '''all''' patches against released kernels '''must''' have two "Acked-by" replies by "senior" members of the Ubuntu Kernel Team.

 '''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>
 }}}
Line 71: Line 79:
    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>
    }}}
 If the patch required backporting or changes, 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.

 There should be a brief explanation immediately after the "(backported from ...)" block, between square brackets, with the name of the person which introduced the change.

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

 {{{
 (cherry picked from commit <sha1> <upstream repo name>)
 }}}

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

 "<upstream repo name>" can be omitted if the patch comes from the mainline tree.

'''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>
 }}}

 1. Every '''CVE''' patch '''must''' contain a line at the beginning of the commit message that specifies the CVE number(s) related to the patch. This must be the first part of the body of the comment. There is the comment subject line, a blank line, the CVE number, a blank line and then the rest of the comment body. A "BugLink" is optional for CVE patches.

 '''Example:'''
 {{{
Subject: [SRU B/D] UBUNTU: SAUCE: nbd_genl_status: null check for nla_nest_start

From: Navid Emamdoost <navid.emamdoost@gmail.com>

CVE-2019-16089

nla_nest_start may fail and return NULL. The check is inserted, and
errno is selected based on other call sites within the same source code.
Update: removed extra new line.
v3 Update: added release reply, thanks to Michal Kubecek for pointing
out.
...
 }}}

=== Patch Series ===

 1. Every patch submitted to a stable kernel '''must''' be sent in a patch series with a cover letter, even if the patch series contains a single patch.

 1. The cover letter '''must''' contain the "BugLink" or the CVE number like the patch(es) itself.

 1. The cover letter '''must''' contain the SRU justification from the launchpad bug or the CVE fix. See KernelTeam/KernelUpdates.

 1. All the emails in the patch series '''must''' be numbered (e.g. "[PATCH 0/3]", "[PATCH 1/3]", etc.) and all the patches sent in reply to the cover letter (PATCH 0/N). See the option "--no-chain-reply-to" from git-send-email(1).
Line 102: Line 140:
{{{
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>
}}}

===== Cover letter =====
 {{{
Subject: [SRU][F][PATCH 0/1] s390/cpum_cf: Add new extended counters for IBM z15 (LP: 1881096)
From: frank.heimes@canonical.com
Date: 24.06.20, 22:11
To: kernel-team@lists.ubuntu.com

Buglink: https://bugs.launchpad.net/bugs/1881096

SRU Justification:

[Impact]

* With perf from Ubuntu 20.04 on IBM z15 hardware, some counters reported with lscpumf are not usable with 'perf stat -e'.
[...]

[Fix]

* d68d5d51dc898895b4e15bea52e5668ca9e76180 d68d5d51dc898895b "s390/cpum_cf: Add new extended counters for IBM z15"

[Test Plan]

* Requires the fix/patch of the perf tool, as mentioned in the bug, too.
[...]

[Where problems could occur]

* The regression can be considered as low, since:
[...]

[Other Info]

* This requires a patch to be included into the perf itself, too - please see bug description for more details.
[...]
 }}}

===== Patch 1/1 =====

 {{{
Subject: [SRU][F][PATCH 1/1] s390/cpum_cf: Add new extended counters for IBM z15
From: frank.heimes@canonical.com
Date: 24.06.20, 22:11
To: kernel-team@lists.ubuntu.com

From: Thomas Richter <tmricht@linux.ibm.com>

BugLink: https://bugs.launchpad.net/bugs/1881096

Add CPU measurement counter facility event description for IBM z15.

Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
Reviewed-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
(cherry picked from commit d68d5d51dc898895b4e15bea52e5668ca9e76180)
Signed-off-by: Frank Heimes <frank.heimes@canonical.com>

[...]
 }}}

=== Tips ===

1. When sending patches with git-send-email, use the option "--suppress-cc=all" in order to prevent adding the original author of the patch and other people from the provenance block as CC.

=== See Also ===
 || [[ KernelTeam/KernelUpdates | Kernel Updates ]] || Shows the SRU Justification format to be added to a bug. ||

Stable Patch Format

Destination

Stable patches must be sent to: kernel-team@lists.ubuntu.com

Subject Line

  1. Every patch submitted to a stable kernel must have have its subject line starting with "[SRU]" followed by the release name against which the patch is targeted. That release name must be enclosed in "[ ]" brackets and can be abbreviated using the first letter of the release name (e.g. "B" for "Bionic"). If a patch is to be applied to multiple releases a list of release names can be provided.

    Examples:

     [SRU][Focal][PULL] Focal update: v5.4.56 upstream stable release
     [SRU][B][F][PATCH 1/1] KVM: fix overflow of zero page refcount with ksm running
  2. If the patch requested doesn't come from the mainline tree it 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 regardless 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.

    UBUNTU: [Debian]

    This patch changes the debian rules files (debian/rules, debian*/rules.d/* and possibly debian*/control and debian*/control.d/*).

    (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.

    Example:

     [SRU][FOCAL][PATCH 2/2] UBUNTU: SAUCE: shiftfs: prevent ESTALE for LOOKUP_JUMP lookups

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: "https://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. Exceptions are patches for CVE fixes (see below).

    Example:

     1: Subject: [PATCH 1/1][SRU][B] UBUNTU: SAUCE: platform/x86: dell-uart-backlight: add get_display_mode command
     2:
     3: BugLink: https://bugs.launchpad.net/bugs/1865402
     4: BugLink: https://bugs.launchpad.net/bugs/1234567
     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 provenance 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)
     Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
  3. Where acks are needed they should be placed in the provenance block. Every patch against Development releases following Kernel freeze and all patches against released kernels must have two "Acked-by" replies by "senior" members of the Ubuntu Kernel Team.

    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 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. There should be a brief explanation immediately after the "(backported from ...)" block, between square brackets, with the name of the person which introduced the change.

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

     (cherry picked from commit <sha1> <upstream repo name>)
    And the opening and closing parenthesis are required here as well.

    "<upstream repo name>" can be omitted if the patch comes from the mainline tree.

    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>
  5. Every CVE patch must contain a line at the beginning of the commit message that specifies the CVE number(s) related to the patch. This must be the first part of the body of the comment. There is the comment subject line, a blank line, the CVE number, a blank line and then the rest of the comment body. A "BugLink" is optional for CVE patches.

    Example:

    Subject: [SRU B/D] UBUNTU: SAUCE: nbd_genl_status: null check for nla_nest_start
    
    From: Navid Emamdoost <navid.emamdoost@gmail.com>
    
    CVE-2019-16089
    
    nla_nest_start may fail and return NULL. The check is inserted, and
    errno is selected based on other call sites within the same source code.
    Update: removed extra new line.
    v3 Update: added release reply, thanks to Michal Kubecek for pointing
    out.
    ...

Patch Series

  1. Every patch submitted to a stable kernel must be sent in a patch series with a cover letter, even if the patch series contains a single patch.

  2. The cover letter must contain the "BugLink" or the CVE number like the patch(es) itself.

  3. The cover letter must contain the SRU justification from the launchpad bug or the CVE fix. See KernelTeam/KernelUpdates.

  4. All the emails in the patch series must be numbered (e.g. "[PATCH 0/3]", "[PATCH 1/3]", etc.) and all the patches sent in reply to the cover letter (PATCH 0/N). See the option "--no-chain-reply-to" from git-send-email(1).

Complete Example

Cover letter
  • Subject: [SRU][F][PATCH 0/1] s390/cpum_cf: Add new extended counters for IBM z15 (LP: 1881096)
    From: frank.heimes@canonical.com
    Date: 24.06.20, 22:11
    To: kernel-team@lists.ubuntu.com
    
    Buglink: https://bugs.launchpad.net/bugs/1881096
    
    SRU Justification:
    
    [Impact]
    
    * With perf from Ubuntu 20.04 on IBM z15 hardware, some counters reported with lscpumf are not usable with 'perf stat -e'.
    [...]
    
    [Fix]
    
    * d68d5d51dc898895b4e15bea52e5668ca9e76180 d68d5d51dc898895b "s390/cpum_cf: Add new extended counters for IBM z15"
    
    [Test Plan]
    
    * Requires the fix/patch of the perf tool, as mentioned in the bug, too.
    [...]
    
    [Where problems could occur]
    
    * The regression can be considered as low, since:
    [...]
    
    [Other Info]
    
    * This requires a patch to be included into the perf itself, too - please see bug description for more details.
    [...]

Patch 1/1
  • Subject: [SRU][F][PATCH 1/1] s390/cpum_cf: Add new extended counters for IBM z15
    From: frank.heimes@canonical.com
    Date: 24.06.20, 22:11
    To: kernel-team@lists.ubuntu.com
    
    From: Thomas Richter <tmricht@linux.ibm.com>
    
    BugLink: https://bugs.launchpad.net/bugs/1881096
    
    Add CPU measurement counter facility event description for IBM z15.
    
    Signed-off-by: Thomas Richter <tmricht@linux.ibm.com>
    Reviewed-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
    Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
    (cherry picked from commit d68d5d51dc898895b4e15bea52e5668ca9e76180)
    Signed-off-by: Frank Heimes <frank.heimes@canonical.com>
    
    [...]

Tips

1. When sending patches with git-send-email, use the option "--suppress-cc=all" in order to prevent adding the original author of the patch and other people from the provenance block as CC.

See Also

  • Kernel Updates

    Shows the SRU Justification format to be added to a bug.

Kernel/Dev/StablePatchFormat (last edited 2022-07-07 08:36:42 by kleber-souza)