1.. 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 apt 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 282Validating 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 322Sending 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.kernel.org, 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 format-patch --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 795