summaryrefslogtreecommitdiffstats
path: root/documentation
diff options
context:
space:
mode:
authorPaul Barker <pbarker@konsulko.com>2020-11-23 18:02:18 +0000
committerRichard Purdie <richard.purdie@linuxfoundation.org>2020-11-24 09:07:28 +0000
commit11d216f2af8dffb8165371e74b59de17992507bb (patch)
treecdfa2adfb359ac5d8ce993c6e950f306a009ac22 /documentation
parented36bd89d7b60d69fb94b363ce78eb5720b6429f (diff)
downloadpoky-11d216f2af8dffb8165371e74b59de17992507bb.tar.gz
dev-manual-common-tasks: Describe how to propose changes to stable branches
The documentation on submitting changes to the project should cover the ways in which the process differs for stable branches. These changes add a brief description of the typical policy for handling changes to stable branches and give some steps to follow when proposing changes to these branches. The information is based on my personal experience and on the existing content of the "How to submit a patch to OpenEmbedded" page on the OE wiki. (From yocto-docs rev: 2a835ae0925f4286769fb050b3409732ba79779d) Signed-off-by: Paul Barker <pbarker@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation')
-rw-r--r--documentation/dev-manual/dev-manual-common-tasks.rst57
1 files changed, 57 insertions, 0 deletions
diff --git a/documentation/dev-manual/dev-manual-common-tasks.rst b/documentation/dev-manual/dev-manual-common-tasks.rst
index 4b76217ad3..09f20a2bc9 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.rst
+++ b/documentation/dev-manual/dev-manual-common-tasks.rst
@@ -11004,6 +11004,63 @@ Lastly please ensure that you also test your revised changes. In particular
11004please don't just edit the patch file written out by ``git format-patch`` and 11004please don't just edit the patch file written out by ``git format-patch`` and
11005resend it. 11005resend it.
11006 11006
11007Submitting Changes to Stable Release Branches
11008~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
11009
11010The process for proposing changes to a Yocto Project stable branch differs
11011from the steps described above. Changes to a stable branch must address
11012identified bugs or CVEs and should be made carefully in order to avoid the
11013risk of introducing new bugs or breaking backwards compatibility. Typically
11014bug fixes must already be accepted into the master branch before they can be
11015backported to a stable branch unless the bug in question does not affect the
11016master branch or the fix on the master branch is unsuitable for backporting.
11017
11018The list of stable branches along with the status and maintainer for each
11019branch can be obtained from the
11020:yocto_wiki:`Releases wiki page </wiki/Releases>`.
11021
11022.. note::
11023
11024 Changes will not typically be accepted for branches which are marked as
11025 End-Of-Life (EOL).
11026
11027With this in mind, the steps to submit a change for a stable branch are as
11028follows:
11029
110301. *Identify the bug or CVE to be fixed:* This information should be
11031 collected so that it can be included in your submission.
11032
110332. *Check if the fix is already present in the master branch:* This will
11034 result in the most straightforward path into the stable branch for the
11035 fix.
11036
11037 a. *If the fix is present in the master branch - Submit a backport request
11038 by email:* You should send an email to the relevant stable branch
11039 maintainer and the mailing list with details of the bug or CVE to be
11040 fixed, the commit hash on the master branch that fixes the issue and
11041 the stable branches which you would like this fix to be backported to.
11042
11043 b. *If the fix is not present in the master branch - Submit the fix to the
11044 master branch first:* This will ensure that the fix passes through the
11045 project's usual patch review and test processes before being accepted.
11046 It will also ensure that bugs are not left unresolved in the master
11047 branch itself. Once the fix is accepted in the master branch a backport
11048 request can be submitted as above.
11049
11050 c. *If the fix is unsuitable for the master branch - Submit a patch
11051 directly for the stable branch:* This method should be considered as a
11052 last resort. It is typically necessary when the master branch is using
11053 a newer version of the software which includes an upstream fix for the
11054 issue or when the issue has been fixed on the master branch in a way
11055 that introduces backwards incompatible changes. In this case follow the
11056 steps in :ref:`preparing-changes-for-submissions` and
11057 :ref:`submitting-a-patch` but modify the subject header of your patch
11058 email to include the name of the stable branch which you are
11059 targetting. This can be done using the ``--subject-prefix`` argument to
11060 ``git format-patch``, for example to submit a patch to the dunfell
11061 branch use
11062 ``git format-patch --subject-prefix='&DISTRO_NAME_NO_CAP_MINUS_ONE;][PATCH' ...``.
11063
11007Working With Licenses 11064Working With Licenses
11008===================== 11065=====================
11009 11066