From 370750a72649ec000b2480bb951006a4f99b4cc5 Mon Sep 17 00:00:00 2001 From: Koichiro Den Date: Tue, 3 Dec 2024 21:19:30 +0900 Subject: [PATCH 1/7] stable-patch-format: migrate from ubuntu wiki https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat Signed-off-by: Koichiro Den --- docs/reference/index.md | 1 + docs/reference/stable-patch-format.rst | 333 +++++++++++++++++++++++++ 2 files changed, 334 insertions(+) create mode 100644 docs/reference/stable-patch-format.rst diff --git a/docs/reference/index.md b/docs/reference/index.md index 7dfc83e..941ae5a 100644 --- a/docs/reference/index.md +++ b/docs/reference/index.md @@ -23,6 +23,7 @@ oem-kernels :maxdepth: 1 :caption: Kernel patch guidelines +stable-patch-format patch-acceptance-criteria ``` diff --git a/docs/reference/stable-patch-format.rst b/docs/reference/stable-patch-format.rst new file mode 100644 index 0000000..e5ee1f7 --- /dev/null +++ b/docs/reference/stable-patch-format.rst @@ -0,0 +1,333 @@ +Stable Patch Format +=================== + +Destination +----------- + +Stable patches must be sent to: kernel-team@lists.ubuntu.com + +.. important:: + + please subscribe `here `__ + to the mailing list before sending your first patch. Messages from + non-subscribers will be sent to a queue waiting for an admin approval. You + can also manage your subscription and access the mailing list archive on + https://lists.ubuntu.com/mailman/listinfo/kernel-team. + +Subject Line +------------ + +#. 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 + + .. note:: + + * If the patch has to be applied to multiple releases and the subject + becomes to hard to follows, you can feel free to drop some of the + brackets. For example:: + + [SRU][B][F][J][PATCH 0/1] UBUNTU: [Config]: Add support for modifying LDT + + can easily become:: + + [SRU][B,F,J][PATCH 0/1] UBUNTU: [Config]: Add support for modifying LDT + + * If the patch has to be applied to a specific derivative for multiple + release this is the recommended format:: + + [SRU][B,F:linux-kvm] [PATCH 0/1] UBUNTU: [Config] kvm: Add support for modifying LDT + +#. If the patch requested doesn't come from upstream it must contain one of + the following on the Subject line after the release name string + described previously: + + .. list-table:: Example table + :header-rows: 1 + + * - Descriptor + - Meaning + * - UBUNTU: + - This is a patch to the Ubuntu Packaging, including 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./config directory. Please check + ``debian.master/config/README.rst`` or `here + `__ + for more information about the config format. + * - UBUNTU: ubuntu + - This is an update to an Ubuntu specific driver in the ubuntu/ + directory. + * - UBUNTU: SAUCE: + - This is a patch to the kernel code that has not been applied on + mainline (Linus' tree). This category covers the following cases: + + #. The submitter has either authored the patch or obtained the + patch from a non-upstream source. + #. The patch has been applied to an upstream tree but not yet + merged on mainline. + #. The patch is never expected to be submitted upstream but is of + enough value for Ubuntu to carry it in our tree. + #. The patch has been submitted to upstream but is of enough + value for Ubuntu to carry it in our tree regardless of + upstream acceptance. + + * - UBUNTU: [Debian] + - This patch changes the debian rules files (``debian/rules, + debian*/rules.d/*`` and possibly ``debian*/control`` and + ``debian*/control.d/*``). + + Example:: + + [SRU][FOCAL][PATCH 2/2] UBUNTU: SAUCE: shiftfs: prevent ESTALE for LOOKUP_JUMP lookups + +Comment Body +------------ + +#. Every patch 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: + + #. A blank line. + #. 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/" where is the + bug number of the associated Launchpad bug. + #. 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: + + .. code-block:: none + :linenos: + + Subject: [PATCH 1/1][SRU][B] UBUNTU: SAUCE: platform/x86: dell-uart-backlight: add get_display_mode command + + BugLink: https://bugs.launchpad.net/bugs/1865402 + BugLink: https://bugs.launchpad.net/bugs/1234567 + + [...] + +#. 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 + Signed-off-by: Linus Torvalds + (backported from commit 5620ae29f1eabe655f44335231b580a78c8364ea) + Signed-off-by: Manoj Iyer + +#. 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 members of the Ubuntu Kernel Team. + + Example:: + + Signed-off-by: Adam Jackson + Signed-off-by: Eric Anholt + Signed-off-by: Greg Kroah-Hartman + (cherry picked from commit d4e0018e3e4dd685af25d300fd26a0d5a984482e 2.6.34.y) + Signed-off-by: Manoj Iyer + Acked-by: Tim Gardner + Acked-by: Brad Figg + Acked-by: Steve Conklin + +#. 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 and applied cleanly or not and + who finally applied it to an official Ubuntu source tree. Cherry-picked from + vs backported from: + + If the patch required changes (it did not apply cleanly), 'backported-from + ' has to be used i.e:: + + (backported from commit ) + + Please note that the opening and closing parenthesis are required. There + must be a brief explanation immediately after the "(backported from ...)" + block, between square brackets, with the name of the person who introduced + the change:: + + (backported from commit ) + [roxanan: Had to adjust the context due to missing commit ] + + If the patch is a simple cherry-pick from an upstream repo and it applies + cleanly, that **must** also be spelled out in the provenance section in the + form by using 'cherry-picked from':: + + (cherry picked from commit ) + + The opening and closing parenthesis are required here as well. + + .. note:: + + "" should be omitted if the patch comes from the + mainline tree. + + Example:: + + Signed-off-by: Adam Jackson + Signed-off-by: Eric Anholt + Signed-off-by: Greg Kroah-Hartman + (cherry picked from commit d4e0018e3e4dd685af25d300fd26a0d5a984482e 2.6.34.y) + Signed-off-by: Manoj Iyer + Acked-by: Tim Gardner + Acked-by: Brad Figg + Acked-by: Steve Conklin + +#. 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 + + 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 +------------ + +#. 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. + +#. The cover letter **must** contain the "BugLink" or the CVE number like the + patch(es) itself. + +#. The cover letter **must** contain the SRU justification from the launchpad + bug or the CVE fix. See `KernelTeam/KernelUpdates`_. + +#. 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). + +.. _KernelTeam/KernelUpdates: https://wiki.ubuntu.com/KernelTeam/KernelUpdates + +Pull Request +------------ + +When the patch series is relatively large (e.g. more than 5 patches), please +consider sending a git pull request instead of a patch series. A pull request +is usually easier to review than a large number of patches in the same email +thread. For a pull request, please follow these guidelines: + +#. Include the git pull request information in the cover letter email, which + should still contain the information requested above. +#. Please make sure the git repository is public. +#. Add a "[PULL]" tag to the subject line of the cover letter instead of + "[PATCH X/N]". +#. The body of the commits should follow the same rules as for a patch series. +#. The format of the title of the commits contained in the pull request should + be the same as for the patch series, except for the tags at the beginning of + the subject enclosed in "[]" brackets which would be removed by ``git am`` + on application. + +Complete Example +---------------- + +Cover letter +^^^^^^^^^^^^ + +.. code-block:: none + + 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 +^^^^^^^^^ + +.. code-block:: none + + 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 + + BugLink: https://bugs.launchpad.net/bugs/1881096 + + Add CPU measurement counter facility event description for IBM z15. + + Signed-off-by: Thomas Richter + Reviewed-by: Sumanth Korikkar + Signed-off-by: Vasily Gorbik + (cherry picked from commit d68d5d51dc898895b4e15bea52e5668ca9e76180) + Signed-off-by: Frank Heimes + + [...] + +Tips +---- + +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 +-------- + +.. list-table:: + + * - `Kernel Update `_ + - Shows the SRU Justification format to be added to a bug. From 28e2e89627bb452ebb2683f5375e3e2dbc9be7cf Mon Sep 17 00:00:00 2001 From: Koichiro Den Date: Fri, 6 Dec 2024 11:03:59 +0900 Subject: [PATCH 2/7] stable-patch-format: update Signed-off-by: Koichiro Den --- docs/reference/stable-patch-format.rst | 245 ++++++++++++++----------- 1 file changed, 139 insertions(+), 106 deletions(-) diff --git a/docs/reference/stable-patch-format.rst b/docs/reference/stable-patch-format.rst index e5ee1f7..1fa8e3e 100644 --- a/docs/reference/stable-patch-format.rst +++ b/docs/reference/stable-patch-format.rst @@ -1,26 +1,32 @@ -Stable Patch Format +Stable patch format =================== -Destination ------------ +Every Ubuntu LTS release during standard security maintenance period (see +`The Ubuntu lifecycle and release cadence`_) welcomes contributions from +anyone. However, patches must comply with the required format. -Stable patches must be sent to: kernel-team@lists.ubuntu.com +.. _The Ubuntu lifecycle and release cadence: https://ubuntu.com/about/release-cycle + +Prerequisites +------------- -.. important:: +Subscribe `here +`__ to join +kernel-team@lists.ubuntu.com before submitting your first patch. Messages +from non-subscribers will be held in a queue pending admin approval. - please subscribe `here `__ - to the mailing list before sending your first patch. Messages from - non-subscribers will be sent to a queue waiting for an admin approval. You - can also manage your subscription and access the mailing list archive on - https://lists.ubuntu.com/mailman/listinfo/kernel-team. +Preparing commits +----------------- -Subject Line ------------- +Every patch **must** adhere to the following guideline. + +Subject line +^^^^^^^^^^^^ #. 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. + 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. @@ -41,58 +47,61 @@ Subject Line [SRU][B,F,J][PATCH 0/1] UBUNTU: [Config]: Add support for modifying LDT + or:: + + [SRU][B/F/J][PATCH 0/1] UBUNTU: [Config]: Add support for modifying LDT + * If the patch has to be applied to a specific derivative for multiple release this is the recommended format:: - [SRU][B,F:linux-kvm] [PATCH 0/1] UBUNTU: [Config] kvm: Add support for modifying LDT + [SRU][B:linux-kvm,F:linux-kvm] [PATCH 0/1] UBUNTU: [Config] kvm: Add support for modifying LDT #. If the patch requested doesn't come from upstream it must contain one of the following on the Subject line after the release name string described previously: - .. list-table:: Example table + .. list-table:: :header-rows: 1 * - Descriptor - Meaning - * - UBUNTU: - - This is a patch to the Ubuntu Packaging, including the contents - of the various debian* directories (where not covered by a more - specific categorisation) + * - UBUNTU: SAUCE: + - This is a patch to the kernel code that has not been applied on + mainline (Linus' tree). This category covers the following cases: + + #. The submitter has either authored the patch or obtained the + patch from a non-upstream source. + #. The patch has been applied to an upstream tree but not yet + merged on mainline. + #. The patch is never expected to be submitted upstream but is of + enough value for Ubuntu to carry it in our tree. + #. The patch has been submitted to upstream but is of enough + value for Ubuntu to carry it in our tree regardless of + upstream acceptance. + + * - UBUNTU: [Packaging] + - This is an update relevant to Ubuntu Packaging, including the contents + of the various ``debian*/`` directories. * - UBUNTU: [Config] - This is an update to the kernel configuration as recorded in the - debian./config directory. Please check + ``debian./config`` directory. Please check ``debian.master/config/README.rst`` or `here `__ for more information about the config format. * - UBUNTU: ubuntu - This is an update to an Ubuntu specific driver in the ubuntu/ - directory. - * - UBUNTU: SAUCE: - - This is a patch to the kernel code that has not been applied on - mainline (Linus' tree). This category covers the following cases: - - #. The submitter has either authored the patch or obtained the - patch from a non-upstream source. - #. The patch has been applied to an upstream tree but not yet - merged on mainline. - #. The patch is never expected to be submitted upstream but is of - enough value for Ubuntu to carry it in our tree. - #. The patch has been submitted to upstream but is of enough - value for Ubuntu to carry it in our tree regardless of - upstream acceptance. - - * - UBUNTU: [Debian] - - This patch changes the debian rules files (``debian/rules, - debian*/rules.d/*`` and possibly ``debian*/control`` and - ``debian*/control.d/*``). + directory. It is rarely used these days, unless in special cases. + * - UBUNTU: + - This subject line is internally used by some automation scripts. + Avoid using it unless none of the other types are appropriate for + your case. Example:: [SRU][FOCAL][PATCH 2/2] UBUNTU: SAUCE: shiftfs: prevent ESTALE for LOOKUP_JUMP lookups -Comment Body ------------- +Comment body +^^^^^^^^^^^^ #. Every patch 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 @@ -103,13 +112,13 @@ Comment Body #. A blank line. #. 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/" where is the + "https\://bugs.launchpad.net/bugs/" where is the bug number of the associated Launchpad bug. #. 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). + CVE fixes (:ref:`see below `). Example: @@ -157,8 +166,8 @@ Comment Body who finally applied it to an official Ubuntu source tree. Cherry-picked from vs backported from: - If the patch required changes (it did not apply cleanly), 'backported-from - ' has to be used i.e:: + If the patch required changes (it did not apply cleanly), 'backported from + commit ' has to be used i.e:: (backported from commit ) @@ -194,6 +203,8 @@ Comment Body Acked-by: Brad Figg Acked-by: Steve Conklin + .. _comment-body-cve: + #. 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 @@ -202,7 +213,7 @@ Comment Body Example:: - Subject: [SRU B/D] UBUNTU: SAUCE: nbd_genl_status: null check for nla_nest_start + Subject: [SRU][B/D] UBUNTU: SAUCE: nbd_genl_status: null check for nla_nest_start From: Navid Emamdoost @@ -215,8 +226,18 @@ Comment Body out. ... -Patch Series ------------- + +Submission preparation +---------------------- + +In most cases, patches should be submitted as a patch series accompanied by +a cover letter. However, if the patch series is relatively large (e.g. more +than 20 commits), consider sending a git pull request instead. + +Sending as a patch series +^^^^^^^^^^^^^^^^^^^^^^^^^ + +When sending a patch series, please follow these guidelines: #. 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. @@ -229,105 +250,117 @@ Patch Series #. 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). + (PATCH 0/N). See the option "\-\-no-chain-reply-to" from git-send-email(1). .. _KernelTeam/KernelUpdates: https://wiki.ubuntu.com/KernelTeam/KernelUpdates -Pull Request ------------- +Sending as a pull request +^^^^^^^^^^^^^^^^^^^^^^^^^ + +When sending a pull request, please follow these guidelines: + +#. Include the git pull request information in the cover letter email. -When the patch series is relatively large (e.g. more than 5 patches), please -consider sending a git pull request instead of a patch series. A pull request -is usually easier to review than a large number of patches in the same email -thread. For a pull request, please follow these guidelines: +#. The cover letter **must** contain the "BugLink" or the CVE number like the + patch(es) itself. + +#. The cover letter **must** contain the SRU justification from the launchpad + bug or the CVE fix. See `KernelTeam/KernelUpdates`_. + +#. The subject line of the cover letter **must** contain "[PULL]" tag, + instead of "[PATCH X/N]". + +#. The git repository **must** be publicly accessible. -#. Include the git pull request information in the cover letter email, which - should still contain the information requested above. -#. Please make sure the git repository is public. -#. Add a "[PULL]" tag to the subject line of the cover letter instead of - "[PATCH X/N]". #. The body of the commits should follow the same rules as for a patch series. + #. The format of the title of the commits contained in the pull request should be the same as for the patch series, except for the tags at the beginning of the subject enclosed in "[]" brackets which would be removed by ``git am`` on application. -Complete Example +Submit +------ + +Stable patches must be sent to: kernel-team@lists.ubuntu.com + +Complete example ---------------- -Cover letter -^^^^^^^^^^^^ +Here is an example of a patch series that adheres to the guidelines. -.. code-block:: none +* 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 + .. code-block:: none - Buglink: https://bugs.launchpad.net/bugs/1881096 + 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 - SRU Justification: + Buglink: https://bugs.launchpad.net/bugs/1881096 - [Impact] + SRU Justification: - * With perf from Ubuntu 20.04 on IBM z15 hardware, some counters reported with lscpumf are not usable with 'perf stat -e'. - [...] + [Impact] - [Fix] + With perf from Ubuntu 20.04 on IBM z15 hardware, some counters + reported with lscpumf are not usable with 'perf stat -e'. + [...] - * d68d5d51dc898895b4e15bea52e5668ca9e76180 d68d5d51dc898895b "s390/cpum_cf: Add new extended counters for IBM z15" + [Fix] - [Test Plan] + Cherry-pick upstream commit: + d68d5d51dc89 ("s390/cpum_cf: Add new extended counters for IBM z15") - * Requires the fix/patch of the perf tool, as mentioned in the bug, too. - [...] + [Test Plan] - [Where problems could occur] + Requires the fix/patch of the perf tool, as mentioned in the bug, too. + [...] - * The regression can be considered as low, since: - [...] + [Where problems could occur] - [Other Info] + The regression can be considered as low, since: + [...] - * This requires a patch to be included into the perf itself, too - please see bug description for more details. - [...] + [Other Info] -Patch 1/1 -^^^^^^^^^ + This requires a patch to be included into the perf itself, too - please + see bug description for more details. + [...] -.. code-block:: none +* 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 + .. code-block:: none - From: Thomas Richter + 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 - BugLink: https://bugs.launchpad.net/bugs/1881096 + From: Thomas Richter - Add CPU measurement counter facility event description for IBM z15. + BugLink: https://bugs.launchpad.net/bugs/1881096 - Signed-off-by: Thomas Richter - Reviewed-by: Sumanth Korikkar - Signed-off-by: Vasily Gorbik - (cherry picked from commit d68d5d51dc898895b4e15bea52e5668ca9e76180) - Signed-off-by: Frank Heimes + Add CPU measurement counter facility event description for IBM z15. - [...] + Signed-off-by: Thomas Richter + Reviewed-by: Sumanth Korikkar + Signed-off-by: Vasily Gorbik + (cherry picked from commit d68d5d51dc898895b4e15bea52e5668ca9e76180) + Signed-off-by: Frank Heimes + + [...] Tips ---- -When sending patches with git-send-email, use the option "--suppress-cc=all" in +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 +See also -------- -.. list-table:: - - * - `Kernel Update `_ - - Shows the SRU Justification format to be added to a bug. +* `Kernel Update `_: + shows the SRU Justification format to be added to a bug. From fc19c882526d7d02428b2ed6a772aca4bf39f345 Mon Sep 17 00:00:00 2001 From: Koichiro Den Date: Mon, 9 Dec 2024 12:25:46 +0900 Subject: [PATCH 3/7] patch-acceptance-criteria: update reference to Stable Patch Format doc Signed-off-by: Koichiro Den --- docs/reference/patch-acceptance-criteria.rst | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/docs/reference/patch-acceptance-criteria.rst b/docs/reference/patch-acceptance-criteria.rst index 433f269..62ab870 100644 --- a/docs/reference/patch-acceptance-criteria.rst +++ b/docs/reference/patch-acceptance-criteria.rst @@ -30,12 +30,10 @@ Usually, cherry-picks have the biggest rate of approval if it’s done correctly Backports and SAUCE patches are a bit tricky. In general, we avoid merging those as much as possible. -For a detailed description on how to format patches before submission, see this -`guideline document`_, while here is a quick (and far from complete) +For a detailed description on how to format patches before submission, see +:doc:`./stable-patch-format`, while here is a quick (and far from complete) introduction. -.. _guideline document: https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat - All patches ----------- From 735f923d7ff016bec0ae668c3a1b6110a71f1a19 Mon Sep 17 00:00:00 2001 From: Koichiro Den Date: Mon, 9 Dec 2024 12:26:26 +0900 Subject: [PATCH 4/7] stable-release-updates: update reference to Stable Patch Format doc Signed-off-by: Koichiro Den --- docs/explanation/stable-release-updates.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/docs/explanation/stable-release-updates.md b/docs/explanation/stable-release-updates.md index d194c88..6169667 100644 --- a/docs/explanation/stable-release-updates.md +++ b/docs/explanation/stable-release-updates.md @@ -46,8 +46,8 @@ may be subject to change. ## SRU patch submission and review process All updates that are applied to stable kernels go through the following patch -submission and review process. More details can be found at [Ubuntu Wiki - -Stable Patch Format]. +submission and review process. More details can be found at +:doc:`./stable-patch-format`. ### Patch creation @@ -123,7 +123,6 @@ model. % LINKS [Ubuntu Kernel Team]: https://kernel.ubuntu.com/ -[Ubuntu Wiki - Stable Patch Format]: https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat [Ubuntu Wiki - Kernel Updates]: https://wiki.ubuntu.com/KernelTeam/KernelUpdates [Ubuntu archive has a single proposed pocket]: https://canonical-ubuntu-packaging-guide.readthedocs-hosted.com/en/latest/explanation/archive/#archivepockets [Discourse - Ubuntu Kernel 4/2 SRU Cycle Announcement]: https://discourse.ubuntu.com/t/ubuntu-kernel-4-2-sru-cycle-announcement/37478 From cadce2c8aa8a8ff6dd428b21b9058f48994fc52b Mon Sep 17 00:00:00 2001 From: Koichiro Den Date: Fri, 13 Dec 2024 22:51:24 +0900 Subject: [PATCH 5/7] stable-patch-format: add link to ubuntu-check-commit Signed-off-by: Koichiro Den --- docs/reference/stable-patch-format.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/reference/stable-patch-format.rst b/docs/reference/stable-patch-format.rst index 1fa8e3e..8f54242 100644 --- a/docs/reference/stable-patch-format.rst +++ b/docs/reference/stable-patch-format.rst @@ -364,3 +364,6 @@ See also * `Kernel Update `_: shows the SRU Justification format to be added to a bug. +* `ubuntu-check-commit + `_: + script to check commits against Ubuntu submission rules. From bd8a3dd9e3b6fc0c4030181c560ba3767c290101 Mon Sep 17 00:00:00 2001 From: annecyh Date: Fri, 13 Dec 2024 15:15:03 +0800 Subject: [PATCH 6/7] docs(ref/spf): suggested edits Signed-off-by: annecyh --- docs/reference/stable-patch-format.rst | 448 ++++++++++++++----------- 1 file changed, 246 insertions(+), 202 deletions(-) diff --git a/docs/reference/stable-patch-format.rst b/docs/reference/stable-patch-format.rst index 8f54242..eedf8e5 100644 --- a/docs/reference/stable-patch-format.rst +++ b/docs/reference/stable-patch-format.rst @@ -1,11 +1,11 @@ Stable patch format =================== -Every Ubuntu LTS release during standard security maintenance period (see -`The Ubuntu lifecycle and release cadence`_) welcomes contributions from -anyone. However, patches must comply with the required format. +Every Ubuntu LTS release during standard security maintenance period welcomes +contributions from anyone. +However, patches must comply with the required format. -.. _The Ubuntu lifecycle and release cadence: https://ubuntu.com/about/release-cycle +See `The Ubuntu lifecycle and release cadence`_ for more information. Prerequisites ------------- @@ -18,102 +18,124 @@ from non-subscribers will be held in a queue pending admin approval. Preparing commits ----------------- -Every patch **must** adhere to the following guideline. +Every patch **must** adhere to the following guidelines. Subject line ^^^^^^^^^^^^ -#. 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. +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. + +The release name **must** be enclosed in "[ ]" brackets and can be +abbreviated using the first letter of the release name (e.g. "B" for +"Bionic"). For example: + +.. code-block:: none + + [SRU][Focal][PULL] Focal update: v5.4.56 upstream stable release - Examples:: +* If a patch is to be applied to multiple releases, a list of release names + must be provided. For example: + + .. code-block:: none - [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 - .. note:: +* If the patch has to be applied to multiple releases, you can drop some of + the square brackets and use the comma "," or forward slash "/" character + to separate the releases. - * If the patch has to be applied to multiple releases and the subject - becomes to hard to follows, you can feel free to drop some of the - brackets. For example:: + For example, if the patch has to be applied to the "Bionic, "Focal", and + "Jammy" release, change from this: - [SRU][B][F][J][PATCH 0/1] UBUNTU: [Config]: Add support for modifying LDT + .. code-block:: none + + [SRU][B][F][J][PATCH 0/1] UBUNTU: [Config]: Add support for modifying LDT + + To a comma- or forward slash-separated list: - can easily become:: + .. code-block:: none + + [SRU][B,F,J][PATCH 0/1] UBUNTU: [Config]: Add support for modifying LDT - [SRU][B,F,J][PATCH 0/1] UBUNTU: [Config]: Add support for modifying LDT + [SRU][B/F/J][PATCH 0/1] UBUNTU: [Config]: Add support for modifying LDT - or:: +* If the patch has to be applied to a specific derivative for multiple + releases, indicate the derivative after the release. For example: - [SRU][B/F/J][PATCH 0/1] UBUNTU: [Config]: Add support for modifying LDT + .. code-block:: none - * If the patch has to be applied to a specific derivative for multiple - release this is the recommended format:: + [SRU][B:linux-kvm,F:linux-kvm] [PATCH 0/1] UBUNTU: [Config] kvm: Add support for modifying LDT - [SRU][B:linux-kvm,F:linux-kvm] [PATCH 0/1] UBUNTU: [Config] kvm: Add support for modifying LDT +Subject line for non-upstream patches +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -#. If the patch requested doesn't come from upstream it must contain one of - the following on the Subject line after the release name string - described previously: +.. note:: - .. list-table:: - :header-rows: 1 + Upstream patches refer to patches that only include commits that already + reside in Linus's mainline tree. - * - Descriptor - - Meaning - * - UBUNTU: SAUCE: - - This is a patch to the kernel code that has not been applied on - mainline (Linus' tree). This category covers the following cases: +If the patch requested doesn't come from upstream, it must contain one of the +following on the subject line after the release name and patch number. - #. The submitter has either authored the patch or obtained the - patch from a non-upstream source. - #. The patch has been applied to an upstream tree but not yet - merged on mainline. - #. The patch is never expected to be submitted upstream but is of - enough value for Ubuntu to carry it in our tree. - #. The patch has been submitted to upstream but is of enough - value for Ubuntu to carry it in our tree regardless of - upstream acceptance. +.. list-table:: + :header-rows: 1 - * - UBUNTU: [Packaging] - - This is an update relevant to Ubuntu Packaging, including the contents - of the various ``debian*/`` directories. - * - UBUNTU: [Config] - - This is an update to the kernel configuration as recorded in the - ``debian./config`` directory. Please check - ``debian.master/config/README.rst`` or `here - `__ - for more information about the config format. - * - UBUNTU: ubuntu - - This is an update to an Ubuntu specific driver in the ubuntu/ - directory. It is rarely used these days, unless in special cases. - * - UBUNTU: - - This subject line is internally used by some automation scripts. - Avoid using it unless none of the other types are appropriate for - your case. + * - Descriptor + - Meaning + * - UBUNTU\: SAUCE\: + - This is a patch to the kernel code that has not been applied on mainline + (Linus' tree). This category covers the following cases: - Example:: + #. The submitter has either authored the patch or obtained the patch from + a non-upstream source. + #. The patch has been applied to an upstream tree but not yet merged on + mainline. + #. The patch is never expected to be submitted upstream but is of enough + value for Ubuntu to carry it in our tree. + #. The patch has been submitted to upstream but is of enough value for + Ubuntu to carry it in our tree regardless of upstream acceptance. + + * - UBUNTU: [Packaging] + - This is an update relevant to Ubuntu Packaging, including the contents + of the various ``debian*/`` directories. + * - UBUNTU: [Config] + - This is an update to the kernel configuration as recorded in the + ``debian./config`` directory. + + See the ``debian.master/config/README.rst`` or + `Discourse - Kernel configuration in Ubuntu`_ for more information about + the config format. + * - UBUNTU: ubuntu + - This is an update to an Ubuntu specific driver in the ``ubuntu/`` + directory. This category is rarely used anymore except in special cases. + * - UBUNTU: + - This subject line is internally used by some automation scripts. + Avoid using it unless none of the other categories are appropriate for + your patch. + +For example, for a patch that falls under the "UBUNTU: SAUCE:" category: + +.. code-block:: none + + [SRU][FOCAL][PATCH 2/2] UBUNTU: SAUCE: shiftfs: prevent ESTALE for LOOKUP_JUMP lookups - [SRU][FOCAL][PATCH 2/2] UBUNTU: SAUCE: shiftfs: prevent ESTALE for LOOKUP_JUMP lookups Comment body ^^^^^^^^^^^^ -#. Every patch 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: +#. Every patch 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: #. A blank line. - #. 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/" where is the - bug number of the associated Launchpad bug. + #. One or more lines containing "BugLink:" and a URL to the Launchpad bug. + The URL must be of the format: + "https\://bugs.launchpad.net/bugs/", where is the + bug number of the associated Launchpad bug tracker. #. Another blank line. Every stable patch **must** have an associated Launchpad bug for @@ -123,7 +145,7 @@ Comment body Example: .. code-block:: none - :linenos: + :emphasize-lines: 2-5 Subject: [PATCH 1/1][SRU][B] UBUNTU: SAUCE: platform/x86: dell-uart-backlight: add get_display_mode command @@ -132,103 +154,120 @@ Comment body [...] -#. 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. +#. Every patch **must** have a "Signed-off-by" line for the person submitting + the patch. The "Signed-off-by" line **must** follow all other provenance + lines and should be the last line in the commit comment. + + Example: - Example:: + .. code-block:: none + :emphasize-lines: 4 - Signed-off-by: Jesse Barnes - Signed-off-by: Linus Torvalds - (backported from commit 5620ae29f1eabe655f44335231b580a78c8364ea) - Signed-off-by: Manoj Iyer + Signed-off-by: Jesse Barnes + Signed-off-by: Linus Torvalds + (backported from commit 5620ae29f1eabe655f44335231b580a78c8364ea) + Signed-off-by: Manoj Iyer -#. Where acks are needed they should be placed in the provenance block. - Every patch against Development releases following Kernel freeze and +#. 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 members of the Ubuntu Kernel Team. - Example:: + Example: + + .. code-block:: none + :emphasize-lines: 6-8 - Signed-off-by: Adam Jackson - Signed-off-by: Eric Anholt - Signed-off-by: Greg Kroah-Hartman - (cherry picked from commit d4e0018e3e4dd685af25d300fd26a0d5a984482e 2.6.34.y) - Signed-off-by: Manoj Iyer - Acked-by: Tim Gardner - Acked-by: Brad Figg - Acked-by: Steve Conklin + Signed-off-by: Adam Jackson + Signed-off-by: Eric Anholt + Signed-off-by: Greg Kroah-Hartman + (cherry picked from commit d4e0018e3e4dd685af25d300fd26a0d5a984482e 2.6.34.y) + Signed-off-by: Manoj Iyer + Acked-by: Tim Gardner + Acked-by: Brad Figg + Acked-by: Steve Conklin #. 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 and applied cleanly or not and - who finally applied it to an official Ubuntu source tree. Cherry-picked from - vs backported from: + who finally applied it to an official Ubuntu source tree. + + Backported patches: - If the patch required changes (it did not apply cleanly), 'backported from - commit ' has to be used i.e:: + - If the patch required changes (e.g. it did not apply cleanly), use + "backported from commit " between brackets "()". For example: - (backported from commit ) + .. code-block:: none - Please note that the opening and closing parenthesis are required. There - must be a brief explanation immediately after the "(backported from ...)" - block, between square brackets, with the name of the person who introduced - the change:: + (backported from commit ) - (backported from commit ) - [roxanan: Had to adjust the context due to missing commit ] + There must be a brief explanation immediately after the "(backported from + ...)" block, between square brackets, with the name of the person who + introduced the change. - If the patch is a simple cherry-pick from an upstream repo and it applies - cleanly, that **must** also be spelled out in the provenance section in the - form by using 'cherry-picked from':: + .. code-block:: none - (cherry picked from commit ) + (backported from commit ) + [roxanan: Had to adjust the context due to missing commit ] - The opening and closing parenthesis are required here as well. + Cherry-picked patches: + - If the patch is a simple cherry-pick from an upstream repo and it applies + cleanly, that **must** also be spelled out in the provenance section in the + format "backported from commit " between brackets "()". For example: + + .. code-block:: none + + (cherry picked from commit ) + .. note:: - "" should be omitted if the patch comes from the - mainline tree. + Omit the "" if the patch comes from the mainline tree. + + Example: - Example:: + .. code-block:: none + :emphasize-lines: 4 - Signed-off-by: Adam Jackson - Signed-off-by: Eric Anholt - Signed-off-by: Greg Kroah-Hartman - (cherry picked from commit d4e0018e3e4dd685af25d300fd26a0d5a984482e 2.6.34.y) - Signed-off-by: Manoj Iyer - Acked-by: Tim Gardner - Acked-by: Brad Figg - Acked-by: Steve Conklin + Signed-off-by: Adam Jackson + Signed-off-by: Eric Anholt + Signed-off-by: Greg Kroah-Hartman + (cherry picked from commit d4e0018e3e4dd685af25d300fd26a0d5a984482e 2.6.34.y) + Signed-off-by: Manoj Iyer + Acked-by: Tim Gardner + Acked-by: Brad Figg + Acked-by: Steve Conklin .. _comment-body-cve: - #. 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. + the first part of the body of the comment. - Example:: + 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. - Subject: [SRU][B/D] UBUNTU: SAUCE: nbd_genl_status: null check for nla_nest_start + Example: + + .. code-block:: none + :emphasize-lines: 5-11 - From: Navid Emamdoost + Subject: [SRU][B/D] UBUNTU: SAUCE: nbd_genl_status: null check for nla_nest_start - CVE-2019-16089 + From: Navid Emamdoost - 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. - ... + 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. + [...] -Submission preparation ----------------------- +Preparing to submit patches +--------------------------- In most cases, patches should be submitted as a patch series accompanied by a cover letter. However, if the patch series is relatively large (e.g. more @@ -237,8 +276,6 @@ than 20 commits), consider sending a git pull request instead. Sending as a patch series ^^^^^^^^^^^^^^^^^^^^^^^^^ -When sending a patch series, please follow these guidelines: - #. 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. @@ -246,28 +283,34 @@ When sending a patch series, please follow these guidelines: patch(es) itself. #. The cover letter **must** contain the SRU justification from the launchpad - bug or the CVE fix. See `KernelTeam/KernelUpdates`_. + bug or the CVE fix. + See `KernelTeam/KernelUpdates`_ wiki for more information about the SRU + justification format to be added to a bug. #. 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). + (PATCH 0/N). -.. _KernelTeam/KernelUpdates: https://wiki.ubuntu.com/KernelTeam/KernelUpdates + .. tip:: + + 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. Sending as a pull request ^^^^^^^^^^^^^^^^^^^^^^^^^ -When sending a pull request, please follow these guidelines: - #. Include the git pull request information in the cover letter email. #. The cover letter **must** contain the "BugLink" or the CVE number like the patch(es) itself. #. The cover letter **must** contain the SRU justification from the launchpad - bug or the CVE fix. See `KernelTeam/KernelUpdates`_. + bug or the CVE fix. + See `KernelTeam/KernelUpdates`_ wiki for more information about the SRU + justification format to be added to a bug. -#. The subject line of the cover letter **must** contain "[PULL]" tag, +#. The subject line of the cover letter **must** contain the "[PULL]" tag, instead of "[PATCH X/N]". #. The git repository **must** be publicly accessible. @@ -279,91 +322,92 @@ When sending a pull request, please follow these guidelines: the subject enclosed in "[]" brackets which would be removed by ``git am`` on application. -Submit ------- +Submitting the patch +-------------------- -Stable patches must be sent to: kernel-team@lists.ubuntu.com +Stable patches must be sent to . -Complete example ----------------- +Patch series example +-------------------- -Here is an example of a patch series that adheres to the guidelines. - -* Cover letter - - .. code-block:: none +Here is an excerpt from an example patch series that adheres to the guidelines. - 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 +Cover letter (PATCH 0/1) +^^^^^^^^^^^^^^^^^^^^^^^^^ - Buglink: https://bugs.launchpad.net/bugs/1881096 +.. code-block:: none - SRU Justification: + 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 - [Impact] + BugLink: https://bugs.launchpad.net/bugs/1881096 - With perf from Ubuntu 20.04 on IBM z15 hardware, some counters - reported with lscpumf are not usable with 'perf stat -e'. - [...] + SRU Justification: - [Fix] + [Impact] - Cherry-pick upstream commit: - d68d5d51dc89 ("s390/cpum_cf: Add new extended counters for IBM z15") + With perf from Ubuntu 20.04 on IBM z15 hardware, some counters + reported with lscpumf are not usable with 'perf stat -e'. + [...] - [Test Plan] + [Fix] - Requires the fix/patch of the perf tool, as mentioned in the bug, too. - [...] + Cherry-pick upstream commit: + d68d5d51dc89 ("s390/cpum_cf: Add new extended counters for IBM z15") - [Where problems could occur] + [Test Plan] - The regression can be considered as low, since: - [...] + Requires the fix/patch of the perf tool, as mentioned in the bug, too. + [...] - [Other Info] + [Where problems could occur] - This requires a patch to be included into the perf itself, too - please - see bug description for more details. - [...] + The regression can be considered as low, since: + [...] -* Patch 1/1 + [Other Info] - .. code-block:: none + This requires a patch to be included into the perf itself, too - please + see bug description for more details. + [...] - 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 +Patch 1/1 +^^^^^^^^^ - From: Thomas Richter +.. code-block:: none - BugLink: https://bugs.launchpad.net/bugs/1881096 + 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 - Add CPU measurement counter facility event description for IBM z15. + From: Thomas Richter - Signed-off-by: Thomas Richter - Reviewed-by: Sumanth Korikkar - Signed-off-by: Vasily Gorbik - (cherry picked from commit d68d5d51dc898895b4e15bea52e5668ca9e76180) - Signed-off-by: Frank Heimes + BugLink: https://bugs.launchpad.net/bugs/1881096 - [...] + Add CPU measurement counter facility event description for IBM z15. -Tips ----- + Signed-off-by: Thomas Richter + Reviewed-by: Sumanth Korikkar + Signed-off-by: Vasily Gorbik + (cherry picked from commit d68d5d51dc898895b4e15bea52e5668ca9e76180) + Signed-off-by: Frank Heimes -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 --------- +Related topics +-------------- -* `Kernel Update `_: +* `KernelTeam/KernelUpdates`_: shows the SRU Justification format to be added to a bug. -* `ubuntu-check-commit - `_: +* `ubuntu-check-commit`_: script to check commits against Ubuntu submission rules. + +.. LINKS + +.. _The Ubuntu lifecycle and release cadence: https://ubuntu.com/about/release-cycle +.. _Discourse - Kernel configuration in Ubuntu: https://discourse.ubuntu.com/t/kernel-configuration-in-ubuntu/35857 +.. _KernelTeam/KernelUpdates: https://wiki.ubuntu.com/KernelTeam/KernelUpdates +.. _ubuntu-check-commit: https://kernel.ubuntu.com/gitea/actions/ubuntu-check-commit/src/branch/main/ubuntu-check-commit From 5256b9ecd917a39e7d5e074e5e675dbbd9aba2d4 Mon Sep 17 00:00:00 2001 From: annecyh Date: Thu, 19 Dec 2024 16:47:36 +0800 Subject: [PATCH 7/7] WIP Signed-off-by: annecyh --- docs/reference/stable-patch-format.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/reference/stable-patch-format.rst b/docs/reference/stable-patch-format.rst index eedf8e5..15c6468 100644 --- a/docs/reference/stable-patch-format.rst +++ b/docs/reference/stable-patch-format.rst @@ -325,7 +325,7 @@ Sending as a pull request Submitting the patch -------------------- -Stable patches must be sent to . +Stable patches must be sent to kernel-team@lists.ubuntu.com. Patch series example --------------------