blob: 53daaf901a74ab7c5b969bbe22bb32c6542354e2 [file] [log] [blame]
Andrew Geissler5082cc72023-09-11 08:41:39 -04001.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
2
3Contributing Changes to a Component
4************************************
5
6Contributions to the Yocto Project and OpenEmbedded are very welcome.
7Because the system is extremely configurable and flexible, we recognize
8that developers will want to extend, configure or optimize it for their
9specific uses.
10
11.. _ref-why-mailing-lists:
12
13Contributing through mailing lists --- Why not using web-based workflows?
14=========================================================================
15
16Both Yocto Project and OpenEmbedded have many key components that are
17maintained by patches being submitted on mailing lists. We appreciate this
18approach does look a little old fashioned when other workflows are available
19through web technology such as GitHub, GitLab and others. Since we are often
20asked this question, we’ve decided to document the reasons for using mailing
21lists.
22
23One significant factor is that we value peer review. When a change is proposed
24to many of the core pieces of the project, it helps to have many eyes of review
25go over them. Whilst there is ultimately one maintainer who needs to make the
26final call on accepting or rejecting a patch, the review is made by many eyes
27and the exact people reviewing it are likely unknown to the maintainer. It is
28often the surprise reviewer that catches the most interesting issues!
29
30This is in contrast to the "GitHub" style workflow where either just a
31maintainer makes that review, or review is specifically requested from
32nominated people. We believe there is significant value added to the codebase
33by this peer review and that moving away from mailing lists would be to the
34detriment of our code.
35
36We also need to acknowledge that many of our developers are used to this
37mailing list workflow and have worked with it for years, with tools and
38processes built around it. Changing away from this would result in a loss
39of key people from the project, which would again be to its detriment.
40
41The projects are acutely aware that potential new contributors find the
42mailing list approach off-putting and would prefer a web-based GUI.
43Since we don’t believe that can work for us, the project is aiming to ensure
44`patchwork <https://patchwork.yoctoproject.org/>`__ is available to help track
45patch status and also looking at how tooling can provide more feedback to users
46about patch status. We are looking at improving tools such as ``patchtest`` to
47test user contributions before they hit the mailing lists and also at better
48documenting how to use such workflows since we recognise that whilst this was
49common knowledge a decade ago, it might not be as familiar now.
50
51Preparing Changes for Submission
52================================
53
54Set up Git
55----------
56
57The first thing to do is to install Git packages. Here is an example
58on Debian and Ubuntu::
59
60 sudo aptitude install git-core git-email
61
62Then, you need to set a name and e-mail address that Git will
63use to identify your commits::
64
65 git config --global user.name "Ada Lovelace"
66 git config --global user.email "ada.lovelace@gmail.com"
67
68Clone the Git repository for the component to modify
69----------------------------------------------------
70
71After identifying the component to modify as described in the
72":doc:`../contributor-guide/identify-component`" section, clone the
73corresponding Git repository. Here is an example for OpenEmbedded-Core::
74
75 git clone https://git.openembedded.org/openembedded-core
76 cd openembedded-core
77
78Create a new branch
79-------------------
80
81Then, create a new branch in your local Git repository
82for your changes, starting from the reference branch in the upstream
83repository (often called ``master``)::
84
85 $ git checkout <ref-branch>
86 $ git checkout -b my-changes
87
88If you have completely unrelated sets of changes to submit, you should even
89create one branch for each set.
90
91Implement and commit changes
92----------------------------
93
94In each branch, you should group your changes into small, controlled and
95isolated ones. Keeping changes small and isolated aids review, makes
96merging/rebasing easier and keeps the change history clean should anyone need
97to refer to it in future.
98
99To this purpose, you should create *one Git commit per change*,
100corresponding to each of the patches you will eventually submit.
101See `further guidance <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#separate-your-changes>`__
102in the Linux kernel documentation if needed.
103
104For example, when you intend to add multiple new recipes, each recipe
105should be added in a separate commit. For upgrades to existing recipes,
106the previous version should usually be deleted as part of the same commit
107to add the upgraded version.
108
109#. *Stage Your Changes:* Stage your changes by using the ``git add``
110 command on each file you modified. If you want to stage all the
111 files you modified, you can even use the ``git add -A`` command.
112
113#. *Commit Your Changes:* This is when you can create separate commits. For
114 each commit to create, use the ``git commit -s`` command with the files
115 or directories you want to include in the commit::
116
117 $ git commit -s file1 file2 dir1 dir2 ...
118
119 To include **a**\ ll staged files::
120
121 $ git commit -sa
122
123 - The ``-s`` option of ``git commit`` adds a "Signed-off-by:" line
124 to your commit message. There is the same requirement for contributing
125 to the Linux kernel. Adding such a line signifies that you, the
126 submitter, have agreed to the `Developer's Certificate of Origin 1.1
127 <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin>`__
128 as follows:
129
130 .. code-block:: none
131
132 Developer's Certificate of Origin 1.1
133
134 By making a contribution to this project, I certify that:
135
136 (a) The contribution was created in whole or in part by me and I
137 have the right to submit it under the open source license
138 indicated in the file; or
139
140 (b) The contribution is based upon previous work that, to the best
141 of my knowledge, is covered under an appropriate open source
142 license and I have the right under that license to submit that
143 work with modifications, whether created in whole or in part
144 by me, under the same open source license (unless I am
145 permitted to submit under a different license), as indicated
146 in the file; or
147
148 (c) The contribution was provided directly to me by some other
149 person who certified (a), (b) or (c) and I have not modified
150 it.
151
152 (d) I understand and agree that this project and the contribution
153 are public and that a record of the contribution (including all
154 personal information I submit with it, including my sign-off) is
155 maintained indefinitely and may be redistributed consistent with
156 this project or the open source license(s) involved.
157
158 - Provide a single-line summary of the change and, if more
159 explanation is needed, provide more detail in the body of the
160 commit. This summary is typically viewable in the "shortlist" of
161 changes. Thus, providing something short and descriptive that
162 gives the reader a summary of the change is useful when viewing a
163 list of many commits. You should prefix this short description
164 with the recipe name (if changing a recipe), or else with the
165 short form path to the file being changed.
166
167 .. note::
168
169 To find a suitable prefix for the commit summary, a good idea
170 is to look for prefixes used in previous commits touching the
171 same files or directories::
172
173 git log --oneline <paths>
174
175 - For the body of the commit message, provide detailed information
176 that describes what you changed, why you made the change, and the
177 approach you used. It might also be helpful if you mention how you
178 tested the change. Provide as much detail as you can in the body
179 of the commit message.
180
181 .. note::
182
183 If the single line summary is enough to describe a simple
184 change, the body of the commit message can be left empty.
185
186 - If the change addresses a specific bug or issue that is associated
187 with a bug-tracking ID, include a reference to that ID in your
188 detailed description. For example, the Yocto Project uses a
189 specific convention for bug references --- any commit that addresses
190 a specific bug should use the following form for the detailed
191 description. Be sure to use the actual bug-tracking ID from
192 Bugzilla for bug-id::
193
194 Fixes [YOCTO #bug-id]
195
196 detailed description of change
197
198#. *Crediting contributors:* By using the ``git commit --amend`` command,
199 you can add some tags to the commit description to credit other contributors
200 to the change:
201
202 - ``Reported-by``: name and email of a person reporting a bug
203 that your commit is trying to fix. This is a good practice
204 to encourage people to go on reporting bugs and let them
205 know that their reports are taken into account.
206
207 - ``Suggested-by``: name and email of a person to credit for the
208 idea of making the change.
209
210 - ``Tested-by``, ``Reviewed-by``: name and email for people having
211 tested your changes or reviewed their code. These fields are
212 usually added by the maintainer accepting a patch, or by
213 yourself if you submitted your patches to early reviewers,
214 or are submitting an unmodified patch again as part of a
215 new iteration of your patch series.
216
217 - ``CC:`` Name and email of people you want to send a copy
218 of your changes to. This field will be used by ``git send-email``.
219
220 See `more guidance about using such tags
221 <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes>`__
222 in the Linux kernel documentation.
223
224Creating Patches
225================
226
227Here is the general procedure on how to create patches to be sent through email:
228
229#. *Describe the Changes in your Branch:* If you have more than one commit
230 in your branch, it's recommended to provide a cover letter describing
231 the series of patches you are about to send.
232
233 For this purpose, a good solution is to store the cover letter contents
234 in the branch itself::
235
236 git branch --edit-description
237
238 This will open a text editor to fill in the description for your
239 changes. This description can be updated when necessary and will
240 be used by Git to create the cover letter together with the patches.
241
242 It is recommended to start this description with a title line which
243 will serve a the subject line for the cover letter.
244
245#. *Generate Patches for your Branch:* The ``git format-patch`` command will
246 generate patch files for each of the commits in your branch. You need
247 to pass the reference branch your branch starts from.
248
249 If you branch didn't need a description in the previous step::
250
251 $ git format-patch <ref-branch>
252
253 If you filled a description for your branch, you will want to generate
254 a cover letter too::
255
256 $ git format-patch --cover-letter --cover-from-description=auto <ref-branch>
257
258 After the command is run, the current directory contains numbered
259 ``.patch`` files for the commits in your branch. If you have a cover
260 letter, it will be in the ``0000-cover-letter.patch``.
261
262 .. note::
263
264 The ``--cover-from-description=auto`` option makes ``git format-patch``
265 use the first paragraph of the branch description as the cover
266 letter title. Another possibility, which is easier to remember, is to pass
267 only the ``--cover-letter`` option, but you will have to edit the
268 subject line manually every time you generate the patches.
269
270 See the `git format-patch manual page <https://git-scm.com/docs/git-format-patch>`__
271 for details.
272
273#. *Review each of the Patch Files:* This final review of the patches
274 before sending them often allows to view your changes from a different
275 perspective and discover defects such as typos, spacing issues or lines
276 or even files that you didn't intend to modify. This review should
277 include the cover letter patch too.
278
279 If necessary, rework your commits as described in
280 ":ref:`contributor-guide/submit-changes:taking patch review into account`".
281
Patrick Williamsac13d5f2023-11-24 18:59:46 -0600282Validating Patches with Patchtest
283=================================
284
285``patchtest`` is available in ``openembedded-core`` as a tool for making
286sure that your patches are well-formatted and contain important info for
287maintenance purposes, such as ``Signed-off-by`` and ``Upstream-Status``
288tags. Currently, it only supports testing patches for
289``openembedded-core`` branches. To setup, perform the following::
290
291 pip install -r meta/lib/patchtest/requirements.txt
292 source oe-init-build-env
293 bitbake-layers add-layer ../meta-selftest
294
295Once these steps are complete and you have generated your patch files,
296you can run ``patchtest`` like so::
297
298 patchtest --patch <patch_name>
299
300Alternatively, if you want ``patchtest`` to iterate over and test
301multiple patches stored in a directory, you can use::
302
303 patchtest --directory <directory_name>
304
305By default, ``patchtest`` uses its own modules' file paths to determine what
306repository and test suite to check patches against. If you wish to test
307patches against a repository other than ``openembedded-core`` and/or use
308a different set of tests, you can use the ``--repodir`` and ``--testdir``
309flags::
310
311 patchtest --patch <patch_name> --repodir <path/to/repo> --testdir <path/to/testdir>
312
313Finally, note that ``patchtest`` is designed to test patches in a standalone
314way, so if your patches are meant to apply on top of changes made by
315previous patches in a series, it is possible that ``patchtest`` will report
316false failures regarding the "merge on head" test.
317
318Using ``patchtest`` in this manner provides a final check for the overall
319quality of your changes before they are submitted for review by the
320maintainers.
321
Andrew Geissler5082cc72023-09-11 08:41:39 -0400322Sending the Patches via Email
323=============================
324
325Using Git to Send Patches
326-------------------------
327
328To submit patches through email, it is very important that you send them
329without any whitespace or HTML formatting that either you or your mailer
330introduces. The maintainer that receives your patches needs to be able
331to save and apply them directly from your emails, using the ``git am``
332command.
333
334Using the ``git send-email`` command is the only error-proof way of sending
335your patches using email since there is no risk of compromising whitespace
336in the body of the message, which can occur when you use your own mail
337client. It will also properly include your patches as *inline attachments*,
338which is not easy to do with standard e-mail clients without breaking lines.
339If you used your regular e-mail client and shared your patches as regular
340attachments, reviewers wouldn't be able to quote specific sections of your
341changes and make comments about them.
342
343Setting up Git to Send Email
344----------------------------
345
346The ``git send-email`` command can send email by using a local or remote
347Mail Transport Agent (MTA) such as ``msmtp``, ``sendmail``, or
348through a direct SMTP configuration in your Git ``~/.gitconfig`` file.
349
350Here are the settings for letting ``git send-email`` send e-mail through your
351regular STMP server, using a Google Mail account as an example::
352
353 git config --global sendemail.smtpserver smtp.gmail.com
354 git config --global sendemail.smtpserverport 587
355 git config --global sendemail.smtpencryption tls
356 git config --global sendemail.smtpuser ada.lovelace@gmail.com
357 git config --global sendemail.smtppass = XXXXXXXX
358
359These settings will appear in the ``.gitconfig`` file in your home directory.
360
361If you neither can use a local MTA nor SMTP, make sure you use an email client
362that does not touch the message (turning spaces in tabs, wrapping lines, etc.).
363A good mail client to do so is Pine (or Alpine) or Mutt. For more
364information about suitable clients, see `Email clients info for Linux
365<https://www.kernel.org/doc/html/latest/process/email-clients.html>`__
366in the Linux kernel sources.
367
368If you use such clients, just include the patch in the body of your email.
369
370Finding a Suitable Mailing List
371-------------------------------
372
373You should send patches to the appropriate mailing list so that they can be
374reviewed by the right contributors and merged by the appropriate maintainer.
375The specific mailing list you need to use depends on the location of the code
376you are changing.
377
378If people have concerns with any of the patches, they will usually voice
379their concern over the mailing list. If patches do not receive any negative
380reviews, the maintainer of the affected layer typically takes them, tests them,
381and then based on successful testing, merges them.
382
383In general, each component (e.g. layer) should have a ``README`` file
384that indicates where to send the changes and which process to follow.
385
386The "poky" repository, which is the Yocto Project's reference build
387environment, is a hybrid repository that contains several individual
388pieces (e.g. BitBake, Metadata, documentation, and so forth) built using
389the combo-layer tool. The upstream location used for submitting changes
390varies by component:
391
392- *Core Metadata:* Send your patches to the
393 :oe_lists:`openembedded-core </g/openembedded-core>`
394 mailing list. For example, a change to anything under the ``meta`` or
395 ``scripts`` directories should be sent to this mailing list.
396
397- *BitBake:* For changes to BitBake (i.e. anything under the
398 ``bitbake`` directory), send your patches to the
399 :oe_lists:`bitbake-devel </g/bitbake-devel>`
400 mailing list.
401
402- *"meta-\*" trees:* These trees contain Metadata. Use the
403 :yocto_lists:`poky </g/poky>` mailing list.
404
405- *Documentation*: For changes to the Yocto Project documentation, use the
406 :yocto_lists:`docs </g/docs>` mailing list.
407
408For changes to other layers and tools hosted in the Yocto Project source
409repositories (i.e. :yocto_git:`git.yoctoproject.org <>`), use the
410:yocto_lists:`yocto </g/yocto/>` general mailing list.
411
412For changes to other layers hosted in the OpenEmbedded source
413repositories (i.e. :oe_git:`git.openembedded.org <>`), use
414the :oe_lists:`openembedded-devel </g/openembedded-devel>`
415mailing list, unless specified otherwise in the layer's ``README`` file.
416
417If you intend to submit a new recipe that neither fits into the core Metadata,
418nor into :oe_git:`meta-openembedded </meta-openembedded/>`, you should
419look for a suitable layer in https://layers.openembedded.org. If similar
420recipes can be expected, you may consider :ref:`dev-manual/layers:creating your own layer`.
421
422If in doubt, please ask on the :yocto_lists:`yocto </g/yocto/>` general mailing list
423or on the :oe_lists:`openembedded-devel </g/openembedded-devel>` mailing list.
424
425Subscribing to the Mailing List
426-------------------------------
427
428After identifying the right mailing list to use, you will have to subscribe to
429it if you haven't done it yet.
430
431If you attempt to send patches to a list you haven't subscribed to, your email
432will be returned as undelivered.
433
434However, if you don't want to be receive all the messages sent to a mailing list,
435you can set your subscription to "no email". You will still be a subscriber able
436to send messages, but you won't receive any e-mail. If people reply to your message,
437their e-mail clients will default to including your email address in the
438conversation anyway.
439
440Anyway, you'll also be able to access the new messages on mailing list archives,
441either through a web browser, or for the lists archived on https://lore.kernelorg,
442through an individual newsgroup feed or a git repository.
443
444Sending Patches via Email
445-------------------------
446
447At this stage, you are ready to send your patches via email. Here's the
448typical usage of ``git send-email``::
449
450 git send-email --to <mailing-list-address> *.patch
451
452Then, review each subject line and list of recipients carefully, and then
453and then allow the command to send each message.
454
455You will see that ``git send-email`` will automatically copy the people listed
456in any commit tags such as ``Signed-off-by`` or ``Reported-by``.
457
458In case you are sending patches for :oe_git:`meta-openembedded </meta-openembedded/>`
459or any layer other than :oe_git:`openembedded-core </openembedded-core/>`,
460please add the appropriate prefix so that it is clear which layer the patch is intended
461to be applied to::
462
463 git send-email --subject-prefix="meta-oe][PATCH" ...
464
465.. note::
466
467 It is actually possible to send patches without generating them
468 first. However, make sure you have reviewed your changes carefully
469 because ``git send-email`` will just show you the title lines of
470 each patch.
471
472 Here's a command you can use if you just have one patch in your
473 branch::
474
475 git send-email --to <mailing-list-address> -1
476
477 If you have multiple patches and a cover letter, you can send
478 patches for all the commits between the reference branch
479 and the tip of your branch::
480
481 git send-email --cover-letter --cover-from-description=auto --to <mailing-list-address> -M <ref-branch>
482
483See the `git send-email manual page <https://git-scm.com/docs/git-send-email>`__
484for details.
485
486Troubleshooting Email Issues
487----------------------------
488
489Fixing your From identity
490~~~~~~~~~~~~~~~~~~~~~~~~~
491
492We have a frequent issue with contributors whose patches are received through
493a ``From`` field which doesn't match the ``Signed-off-by`` information. Here is
494a typical example for people sending from a domain name with :wikipedia:`DMARC`::
495
496 From: "Linus Torvalds via lists.openembedded.org <linus.torvalds=kernel.org@lists.openembedded.org>"
497
498This ``From`` field is used by ``git am`` to recreate commits with the right
499author name. The following will ensure that your e-mails have an additional
500``From`` field at the beginning of the Email body, and therefore that
501maintainers accepting your patches don't have to fix commit author information
502manually::
503
504 git config --global sendemail.from "linus.torvalds@kernel.org"
505
506The ``sendemail.from`` should match your ``user.email`` setting,
507which appears in the ``Signed-off-by`` line of your commits.
508
509Streamlining git send-email usage
510---------------------------------
511
512If you want to save time and not be forced to remember the right options to use
513with ``git send-email``, you can use Git configuration settings.
514
515- To set the right mailing list address for a given repository::
516
517 git config --local sendemail.to openembedded-devel@lists.openembedded.org
518
519- If the mailing list requires a subject prefix for the layer
520 (this only works when the repository only contains one layer)::
521
522 git config --local format.subjectprefix "meta-something][PATCH"
523
524Using Scripts to Push a Change Upstream and Request a Pull
525==========================================================
526
527For larger patch series it is preferable to send a pull request which not
528only includes the patch but also a pointer to a branch that can be pulled
529from. This involves making a local branch for your changes, pushing this
530branch to an accessible repository and then using the ``create-pull-request``
531and ``send-pull-request`` scripts from openembedded-core to create and send a
532patch series with a link to the branch for review.
533
534Follow this procedure to push a change to an upstream "contrib" Git
535repository once the steps in
536":ref:`contributor-guide/submit-changes:preparing changes for submission`"
537have been followed:
538
539.. note::
540
541 You can find general Git information on how to push a change upstream
542 in the
543 `Git Community Book <https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows>`__.
544
545#. *Request Push Access to an "Upstream" Contrib Repository:* Send an email to
546 ``helpdesk@yoctoproject.org``:
547
548 - Attach your SSH public key which usually named ``id_rsa.pub.``.
549 If you don't have one generate it by running ``ssh-keygen -t rsa -b 4096 -C "your_email@example.com"``.
550
551 - List the repositories you're planning to contribute to.
552
553 - Include your preferred branch prefix for ``-contrib`` repositories.
554
555#. *Push Your Commits to the "Contrib" Upstream:* Push your
556 changes to that repository::
557
558 $ git push upstream_remote_repo local_branch_name
559
560 For example, suppose you have permissions to push
561 into the upstream ``meta-intel-contrib`` repository and you are
562 working in a local branch named `your_name`\ ``/README``. The following
563 command pushes your local commits to the ``meta-intel-contrib``
564 upstream repository and puts the commit in a branch named
565 `your_name`\ ``/README``::
566
567 $ git push meta-intel-contrib your_name/README
568
569#. *Determine Who to Notify:* Determine the maintainer or the mailing
570 list that you need to notify for the change.
571
572 Before submitting any change, you need to be sure who the maintainer
573 is or what mailing list that you need to notify. Use either these
574 methods to find out:
575
576 - *Maintenance File:* Examine the ``maintainers.inc`` file, which is
577 located in the :term:`Source Directory` at
578 ``meta/conf/distro/include``, to see who is responsible for code.
579
580 - *Search by File:* Using :ref:`overview-manual/development-environment:git`, you can
581 enter the following command to bring up a short list of all
582 commits against a specific file::
583
584 git shortlog -- filename
585
586 Just provide the name of the file for which you are interested. The
587 information returned is not ordered by history but does include a
588 list of everyone who has committed grouped by name. From the list,
589 you can see who is responsible for the bulk of the changes against
590 the file.
591
592 - *Find the Mailing List to Use:* See the
593 ":ref:`contributor-guide/submit-changes:finding a suitable mailing list`"
594 section above.
595
596#. *Make a Pull Request:* Notify the maintainer or the mailing list that
597 you have pushed a change by making a pull request.
598
599 The Yocto Project provides two scripts that conveniently let you
600 generate and send pull requests to the Yocto Project. These scripts
601 are ``create-pull-request`` and ``send-pull-request``. You can find
602 these scripts in the ``scripts`` directory within the
603 :term:`Source Directory` (e.g.
604 ``poky/scripts``).
605
606 Using these scripts correctly formats the requests without
607 introducing any whitespace or HTML formatting. The maintainer that
608 receives your patches either directly or through the mailing list
609 needs to be able to save and apply them directly from your emails.
610 Using these scripts is the preferred method for sending patches.
611
612 First, create the pull request. For example, the following command
613 runs the script, specifies the upstream repository in the contrib
614 directory into which you pushed the change, and provides a subject
615 line in the created patch files::
616
617 $ poky/scripts/create-pull-request -u meta-intel-contrib -s "Updated Manual Section Reference in README"
618
619 Running this script forms ``*.patch`` files in a folder named
620 ``pull-``\ `PID` in the current directory. One of the patch files is a
621 cover letter.
622
623 Before running the ``send-pull-request`` script, you must edit the
624 cover letter patch to insert information about your change. After
625 editing the cover letter, send the pull request. For example, the
626 following command runs the script and specifies the patch directory
627 and email address. In this example, the email address is a mailing
628 list::
629
630 $ poky/scripts/send-pull-request -p ~/meta-intel/pull-10565 -t meta-intel@lists.yoctoproject.org
631
632 You need to follow the prompts as the script is interactive.
633
634 .. note::
635
636 For help on using these scripts, simply provide the ``-h``
637 argument as follows::
638
639 $ poky/scripts/create-pull-request -h
640 $ poky/scripts/send-pull-request -h
641
642Submitting Changes to Stable Release Branches
643=============================================
644
645The process for proposing changes to a Yocto Project stable branch differs
646from the steps described above. Changes to a stable branch must address
647identified bugs or CVEs and should be made carefully in order to avoid the
648risk of introducing new bugs or breaking backwards compatibility. Typically
649bug fixes must already be accepted into the master branch before they can be
650backported to a stable branch unless the bug in question does not affect the
651master branch or the fix on the master branch is unsuitable for backporting.
652
653The list of stable branches along with the status and maintainer for each
654branch can be obtained from the
655:yocto_wiki:`Releases wiki page </Releases>`.
656
657.. note::
658
659 Changes will not typically be accepted for branches which are marked as
660 End-Of-Life (EOL).
661
662With this in mind, the steps to submit a change for a stable branch are as
663follows:
664
665#. *Identify the bug or CVE to be fixed:* This information should be
666 collected so that it can be included in your submission.
667
668 See :ref:`dev-manual/vulnerabilities:checking for vulnerabilities`
669 for details about CVE tracking.
670
671#. *Check if the fix is already present in the master branch:* This will
672 result in the most straightforward path into the stable branch for the
673 fix.
674
675 #. *If the fix is present in the master branch --- submit a backport request
676 by email:* You should send an email to the relevant stable branch
677 maintainer and the mailing list with details of the bug or CVE to be
678 fixed, the commit hash on the master branch that fixes the issue and
679 the stable branches which you would like this fix to be backported to.
680
681 #. *If the fix is not present in the master branch --- submit the fix to the
682 master branch first:* This will ensure that the fix passes through the
683 project's usual patch review and test processes before being accepted.
684 It will also ensure that bugs are not left unresolved in the master
685 branch itself. Once the fix is accepted in the master branch a backport
686 request can be submitted as above.
687
688 #. *If the fix is unsuitable for the master branch --- submit a patch
689 directly for the stable branch:* This method should be considered as a
690 last resort. It is typically necessary when the master branch is using
691 a newer version of the software which includes an upstream fix for the
692 issue or when the issue has been fixed on the master branch in a way
693 that introduces backwards incompatible changes. In this case follow the
694 steps in ":ref:`contributor-guide/submit-changes:preparing changes for submission`"
695 and in the following sections but modify the subject header of your patch
696 email to include the name of the stable branch which you are
697 targetting. This can be done using the ``--subject-prefix`` argument to
698 ``git format-patch``, for example to submit a patch to the
699 "&DISTRO_NAME_NO_CAP_MINUS_ONE;" branch use::
700
701 git format-patch --subject-prefix='&DISTRO_NAME_NO_CAP_MINUS_ONE;][PATCH' ...
702
703Taking Patch Review into Account
704================================
705
706You may get feedback on your submitted patches from other community members
707or from the automated patchtest service. If issues are identified in your
708patches then it is usually necessary to address these before the patches are
709accepted into the project. In this case you should your commits according
710to the feedback and submit an updated version to the relevant mailing list.
711
712In any case, never fix reported issues by fixing them in new commits
713on the tip of your branch. Always come up with a new series of commits
714without the reported issues.
715
716.. note::
717
718 It is a good idea to send a copy to the reviewers who provided feedback
719 to the previous version of the patch. You can make sure this happens
720 by adding a ``CC`` tag to the commit description::
721
722 CC: William Shakespeare <bill@yoctoproject.org>
723
724A single patch can be amended using ``git commit --amend``, and multiple
725patches can be easily reworked and reordered through an interactive Git rebase::
726
727 git rebase -i <ref-branch>
728
729See `this tutorial <https://hackernoon.com/beginners-guide-to-interactive-rebasing-346a3f9c3a6d>`__
730for practical guidance about using Git interactive rebasing.
731
732You should also modify the ``[PATCH]`` tag in the email subject line when
733sending the revised patch to mark the new iteration as ``[PATCH v2]``,
734``[PATCH v3]``, etc as appropriate. This can be done by passing the ``-v``
735argument to ``git format-patch`` with a version number::
736
737 git format-patch -v2 <ref-branch>
738
739Lastly please ensure that you also test your revised changes. In particular
740please don't just edit the patch file written out by ``git format-patch`` and
741resend it.
742
743Tracking the Status of Patches
744==============================
745
746The Yocto Project uses a `Patchwork instance <https://patchwork.yoctoproject.org/>`__
747to track the status of patches submitted to the various mailing lists and to
748support automated patch testing. Each submitted patch is checked for common
749mistakes and deviations from the expected patch format and submitters are
750notified by ``patchtest`` if such mistakes are found. This process helps to
751reduce the burden of patch review on maintainers.
752
753.. note::
754
755 This system is imperfect and changes can sometimes get lost in the flow.
756 Asking about the status of a patch or change is reasonable if the change
757 has been idle for a while with no feedback.
758
759If your patches have not had any feedback in a few days, they may have already
760been merged. You can run ``git pull`` branch to check this. Note that many if
761not most layer maintainers do not send out acknowledgement emails when they
762accept patches. Alternatively, if there is no response or merge after a few days
763the patch may have been missed or the appropriate reviewers may not currently be
764around. It is then perfectly fine to reply to it yourself with a reminder asking
765for feedback.
766
767.. note::
768
769 Patch reviews for feature and recipe upgrade patches are likely be delayed
770 during a feature freeze because these types of patches aren't merged during
771 at that time --- you may have to wait until after the freeze is lifted.
772
773Maintainers also commonly use ``-next`` branches to test submissions prior to
774merging patches. Thus, you can get an idea of the status of a patch based on
775whether the patch has been merged into one of these branches. The commonly
776used testing branches for OpenEmbedded-Core are as follows:
777
778- *openembedded-core "master-next" branch:* This branch is part of the
779 :oe_git:`openembedded-core </openembedded-core/>` repository and contains
780 proposed changes to the core metadata.
781
782- *poky "master-next" branch:* This branch is part of the
783 :yocto_git:`poky </poky/>` repository and combines proposed
784 changes to BitBake, the core metadata and the poky distro.
785
786Similarly, stable branches maintained by the project may have corresponding
787``-next`` branches which collect proposed changes. For example,
788``&DISTRO_NAME_NO_CAP;-next`` and ``&DISTRO_NAME_NO_CAP_MINUS_ONE;-next``
789branches in both the "openembdedded-core" and "poky" repositories.
790
791Other layers may have similar testing branches but there is no formal
792requirement or standard for these so please check the documentation for the
793layers you are contributing to.
794