blob: 9db6ce010c278ca568ce6c0aa6e803d9b913f517 [file] [log] [blame]
Andrew Geissler517393d2023-01-13 08:55:19 -06001.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
2
3Making Changes to the Yocto Project
4***********************************
5
6Because the Yocto Project is an open-source, community-based project,
7you can effect changes to the project. This section presents procedures
8that show you how to submit a defect against the project and how to
9submit a change.
10
11Submitting a Defect Against the Yocto Project
12=============================================
13
14Use the Yocto Project implementation of
15`Bugzilla <https://www.bugzilla.org/about/>`__ to submit a defect (bug)
16against the Yocto Project. For additional information on this
17implementation of Bugzilla see the ":ref:`Yocto Project
18Bugzilla <resources-bugtracker>`" section in the
19Yocto Project Reference Manual. For more detail on any of the following
20steps, see the Yocto Project
21:yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`.
22
23Use the following general steps to submit a bug:
24
25#. Open the Yocto Project implementation of :yocto_bugs:`Bugzilla <>`.
26
27#. Click "File a Bug" to enter a new bug.
28
29#. Choose the appropriate "Classification", "Product", and "Component"
30 for which the bug was found. Bugs for the Yocto Project fall into
31 one of several classifications, which in turn break down into
32 several products and components. For example, for a bug against the
33 ``meta-intel`` layer, you would choose "Build System, Metadata &
34 Runtime", "BSPs", and "bsps-meta-intel", respectively.
35
36#. Choose the "Version" of the Yocto Project for which you found the
37 bug (e.g. &DISTRO;).
38
39#. Determine and select the "Severity" of the bug. The severity
40 indicates how the bug impacted your work.
41
42#. Choose the "Hardware" that the bug impacts.
43
44#. Choose the "Architecture" that the bug impacts.
45
46#. Choose a "Documentation change" item for the bug. Fixing a bug might
47 or might not affect the Yocto Project documentation. If you are
48 unsure of the impact to the documentation, select "Don't Know".
49
50#. Provide a brief "Summary" of the bug. Try to limit your summary to
51 just a line or two and be sure to capture the essence of the bug.
52
53#. Provide a detailed "Description" of the bug. You should provide as
54 much detail as you can about the context, behavior, output, and so
55 forth that surrounds the bug. You can even attach supporting files
56 for output from logs by using the "Add an attachment" button.
57
58#. Click the "Submit Bug" button submit the bug. A new Bugzilla number
59 is assigned to the bug and the defect is logged in the bug tracking
60 system.
61
62Once you file a bug, the bug is processed by the Yocto Project Bug
63Triage Team and further details concerning the bug are assigned (e.g.
64priority and owner). You are the "Submitter" of the bug and any further
65categorization, progress, or comments on the bug result in Bugzilla
66sending you an automated email concerning the particular change or
67progress to the bug.
68
69Submitting a Change to the Yocto Project
70========================================
71
72Contributions to the Yocto Project and OpenEmbedded are very welcome.
73Because the system is extremely configurable and flexible, we recognize
74that developers will want to extend, configure or optimize it for their
75specific uses.
76
77The Yocto Project uses a mailing list and a patch-based workflow that is
78similar to the Linux kernel but contains important differences. In
79general, there is a mailing list through which you can submit patches. You
80should send patches to the appropriate mailing list so that they can be
81reviewed and merged by the appropriate maintainer. The specific mailing
82list you need to use depends on the location of the code you are
83changing. Each component (e.g. layer) should have a ``README`` file that
84indicates where to send the changes and which process to follow.
85
86You can send the patch to the mailing list using whichever approach you
87feel comfortable with to generate the patch. Once sent, the patch is
88usually reviewed by the community at large. If somebody has concerns
89with the patch, they will usually voice their concern over the mailing
90list. If a patch does not receive any negative reviews, the maintainer
91of the affected layer typically takes the patch, tests it, and then
92based on successful testing, merges the patch.
93
94The "poky" repository, which is the Yocto Project's reference build
95environment, is a hybrid repository that contains several individual
96pieces (e.g. BitBake, Metadata, documentation, and so forth) built using
97the combo-layer tool. The upstream location used for submitting changes
98varies by component:
99
100- *Core Metadata:* Send your patch to the
101 :oe_lists:`openembedded-core </g/openembedded-core>`
102 mailing list. For example, a change to anything under the ``meta`` or
103 ``scripts`` directories should be sent to this mailing list.
104
105- *BitBake:* For changes to BitBake (i.e. anything under the
106 ``bitbake`` directory), send your patch to the
107 :oe_lists:`bitbake-devel </g/bitbake-devel>`
108 mailing list.
109
110- *"meta-\*" trees:* These trees contain Metadata. Use the
111 :yocto_lists:`poky </g/poky>` mailing list.
112
113- *Documentation*: For changes to the Yocto Project documentation, use the
114 :yocto_lists:`docs </g/docs>` mailing list.
115
116For changes to other layers hosted in the Yocto Project source
117repositories (i.e. ``yoctoproject.org``) and tools use the
118:yocto_lists:`Yocto Project </g/yocto/>` general mailing list.
119
120.. note::
121
122 Sometimes a layer's documentation specifies to use a particular
123 mailing list. If so, use that list.
124
125For additional recipes that do not fit into the core Metadata, you
126should determine which layer the recipe should go into and submit the
127change in the manner recommended by the documentation (e.g. the
128``README`` file) supplied with the layer. If in doubt, please ask on the
129Yocto general mailing list or on the openembedded-devel mailing list.
130
131You can also push a change upstream and request a maintainer to pull the
132change into the component's upstream repository. You do this by pushing
133to a contribution repository that is upstream. See the
134":ref:`overview-manual/development-environment:git workflows and the yocto project`"
135section in the Yocto Project Overview and Concepts Manual for additional
136concepts on working in the Yocto Project development environment.
137
138Maintainers commonly use ``-next`` branches to test submissions prior to
139merging patches. Thus, you can get an idea of the status of a patch based on
140whether the patch has been merged into one of these branches. The commonly
141used testing branches for OpenEmbedded-Core are as follows:
142
143- *openembedded-core "master-next" branch:* This branch is part of the
144 :oe_git:`openembedded-core </openembedded-core/>` repository and contains
145 proposed changes to the core metadata.
146
147- *poky "master-next" branch:* This branch is part of the
148 :yocto_git:`poky </poky/>` repository and combines proposed
149 changes to BitBake, the core metadata and the poky distro.
150
151Similarly, stable branches maintained by the project may have corresponding
152``-next`` branches which collect proposed changes. For example,
153``&DISTRO_NAME_NO_CAP;-next`` and ``&DISTRO_NAME_NO_CAP_MINUS_ONE;-next``
154branches in both the "openembdedded-core" and "poky" repositories.
155
156Other layers may have similar testing branches but there is no formal
157requirement or standard for these so please check the documentation for the
158layers you are contributing to.
159
160The following sections provide procedures for submitting a change.
161
162Preparing Changes for Submission
163--------------------------------
164
165#. *Make Your Changes Locally:* Make your changes in your local Git
166 repository. You should make small, controlled, isolated changes.
167 Keeping changes small and isolated aids review, makes
168 merging/rebasing easier and keeps the change history clean should
169 anyone need to refer to it in future.
170
171#. *Stage Your Changes:* Stage your changes by using the ``git add``
172 command on each file you changed.
173
174#. *Commit Your Changes:* Commit the change by using the ``git commit``
175 command. Make sure your commit information follows standards by
176 following these accepted conventions:
177
178 - Be sure to include a "Signed-off-by:" line in the same style as
179 required by the Linux kernel. This can be done by using the
180 ``git commit -s`` command. Adding this line signifies that you,
181 the submitter, have agreed to the Developer's Certificate of
182 Origin 1.1 as follows:
183
184 .. code-block:: none
185
186 Developer's Certificate of Origin 1.1
187
188 By making a contribution to this project, I certify that:
189
190 (a) The contribution was created in whole or in part by me and I
191 have the right to submit it under the open source license
192 indicated in the file; or
193
194 (b) The contribution is based upon previous work that, to the best
195 of my knowledge, is covered under an appropriate open source
196 license and I have the right under that license to submit that
197 work with modifications, whether created in whole or in part
198 by me, under the same open source license (unless I am
199 permitted to submit under a different license), as indicated
200 in the file; or
201
202 (c) The contribution was provided directly to me by some other
203 person who certified (a), (b) or (c) and I have not modified
204 it.
205
206 (d) I understand and agree that this project and the contribution
207 are public and that a record of the contribution (including all
208 personal information I submit with it, including my sign-off) is
209 maintained indefinitely and may be redistributed consistent with
210 this project or the open source license(s) involved.
211
212 - Provide a single-line summary of the change and, if more
213 explanation is needed, provide more detail in the body of the
214 commit. This summary is typically viewable in the "shortlist" of
215 changes. Thus, providing something short and descriptive that
216 gives the reader a summary of the change is useful when viewing a
217 list of many commits. You should prefix this short description
218 with the recipe name (if changing a recipe), or else with the
219 short form path to the file being changed.
220
221 - For the body of the commit message, provide detailed information
222 that describes what you changed, why you made the change, and the
223 approach you used. It might also be helpful if you mention how you
224 tested the change. Provide as much detail as you can in the body
225 of the commit message.
226
227 .. note::
228
229 You do not need to provide a more detailed explanation of a
230 change if the change is minor to the point of the single line
231 summary providing all the information.
232
233 - If the change addresses a specific bug or issue that is associated
234 with a bug-tracking ID, include a reference to that ID in your
235 detailed description. For example, the Yocto Project uses a
236 specific convention for bug references --- any commit that addresses
237 a specific bug should use the following form for the detailed
238 description. Be sure to use the actual bug-tracking ID from
239 Bugzilla for bug-id::
240
241 Fixes [YOCTO #bug-id]
242
243 detailed description of change
244
245Using Email to Submit a Patch
246-----------------------------
247
248Depending on the components changed, you need to submit the email to a
249specific mailing list. For some guidance on which mailing list to use,
250see the
251:ref:`list <dev-manual/changes:submitting a change to the yocto project>`
252at the beginning of this section. For a description of all the available
253mailing lists, see the ":ref:`Mailing Lists <resources-mailinglist>`" section in the
254Yocto Project Reference Manual.
255
256Here is the general procedure on how to submit a patch through email
257without using the scripts once the steps in
258:ref:`dev-manual/changes:preparing changes for submission` have been followed:
259
260#. *Format the Commit:* Format the commit into an email message. To
261 format commits, use the ``git format-patch`` command. When you
262 provide the command, you must include a revision list or a number of
263 patches as part of the command. For example, either of these two
264 commands takes your most recent single commit and formats it as an
265 email message in the current directory::
266
267 $ git format-patch -1
268
269 or ::
270
271 $ git format-patch HEAD~
272
273 After the command is run, the current directory contains a numbered
274 ``.patch`` file for the commit.
275
276 If you provide several commits as part of the command, the
277 ``git format-patch`` command produces a series of numbered files in
278 the current directory – one for each commit. If you have more than
279 one patch, you should also use the ``--cover`` option with the
280 command, which generates a cover letter as the first "patch" in the
281 series. You can then edit the cover letter to provide a description
282 for the series of patches. For information on the
283 ``git format-patch`` command, see ``GIT_FORMAT_PATCH(1)`` displayed
284 using the ``man git-format-patch`` command.
285
286 .. note::
287
288 If you are or will be a frequent contributor to the Yocto Project
289 or to OpenEmbedded, you might consider requesting a contrib area
290 and the necessary associated rights.
291
292#. *Send the patches via email:* Send the patches to the recipients and
293 relevant mailing lists by using the ``git send-email`` command.
294
295 .. note::
296
297 In order to use ``git send-email``, you must have the proper Git packages
298 installed on your host.
299 For Ubuntu, Debian, and Fedora the package is ``git-email``.
300
301 The ``git send-email`` command sends email by using a local or remote
302 Mail Transport Agent (MTA) such as ``msmtp``, ``sendmail``, or
303 through a direct ``smtp`` configuration in your Git ``~/.gitconfig``
304 file. If you are submitting patches through email only, it is very
305 important that you submit them without any whitespace or HTML
306 formatting that either you or your mailer introduces. The maintainer
307 that receives your patches needs to be able to save and apply them
308 directly from your emails. A good way to verify that what you are
309 sending will be applicable by the maintainer is to do a dry run and
310 send them to yourself and then save and apply them as the maintainer
311 would.
312
313 The ``git send-email`` command is the preferred method for sending
314 your patches using email since there is no risk of compromising
315 whitespace in the body of the message, which can occur when you use
316 your own mail client. The command also has several options that let
317 you specify recipients and perform further editing of the email
318 message. For information on how to use the ``git send-email``
319 command, see ``GIT-SEND-EMAIL(1)`` displayed using the
320 ``man git-send-email`` command.
321
Andrew Geissler6aa7eec2023-03-03 12:41:14 -0600322The Yocto Project uses a `Patchwork instance <https://patchwork.yoctoproject.org/>`__
Andrew Geissler517393d2023-01-13 08:55:19 -0600323to track the status of patches submitted to the various mailing lists and to
324support automated patch testing. Each submitted patch is checked for common
325mistakes and deviations from the expected patch format and submitters are
326notified by patchtest if such mistakes are found. This process helps to
327reduce the burden of patch review on maintainers.
328
329.. note::
330
331 This system is imperfect and changes can sometimes get lost in the flow.
332 Asking about the status of a patch or change is reasonable if the change
333 has been idle for a while with no feedback.
334
335Using Scripts to Push a Change Upstream and Request a Pull
336----------------------------------------------------------
337
338For larger patch series it is preferable to send a pull request which not
339only includes the patch but also a pointer to a branch that can be pulled
340from. This involves making a local branch for your changes, pushing this
341branch to an accessible repository and then using the ``create-pull-request``
342and ``send-pull-request`` scripts from openembedded-core to create and send a
343patch series with a link to the branch for review.
344
345Follow this procedure to push a change to an upstream "contrib" Git
346repository once the steps in :ref:`dev-manual/changes:preparing changes for submission` have
347been followed:
348
349.. note::
350
351 You can find general Git information on how to push a change upstream
352 in the
353 `Git Community Book <https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows>`__.
354
355#. *Push Your Commits to a "Contrib" Upstream:* If you have arranged for
356 permissions to push to an upstream contrib repository, push the
357 change to that repository::
358
359 $ git push upstream_remote_repo local_branch_name
360
361 For example, suppose you have permissions to push
362 into the upstream ``meta-intel-contrib`` repository and you are
363 working in a local branch named `your_name`\ ``/README``. The following
364 command pushes your local commits to the ``meta-intel-contrib``
365 upstream repository and puts the commit in a branch named
366 `your_name`\ ``/README``::
367
368 $ git push meta-intel-contrib your_name/README
369
370#. *Determine Who to Notify:* Determine the maintainer or the mailing
371 list that you need to notify for the change.
372
373 Before submitting any change, you need to be sure who the maintainer
374 is or what mailing list that you need to notify. Use either these
375 methods to find out:
376
377 - *Maintenance File:* Examine the ``maintainers.inc`` file, which is
378 located in the :term:`Source Directory` at
379 ``meta/conf/distro/include``, to see who is responsible for code.
380
381 - *Search by File:* Using :ref:`overview-manual/development-environment:git`, you can
382 enter the following command to bring up a short list of all
383 commits against a specific file::
384
385 git shortlog -- filename
386
387 Just provide the name of the file for which you are interested. The
388 information returned is not ordered by history but does include a
389 list of everyone who has committed grouped by name. From the list,
390 you can see who is responsible for the bulk of the changes against
391 the file.
392
393 - *Examine the List of Mailing Lists:* For a list of the Yocto
394 Project and related mailing lists, see the ":ref:`Mailing
395 lists <resources-mailinglist>`" section in
396 the Yocto Project Reference Manual.
397
398#. *Make a Pull Request:* Notify the maintainer or the mailing list that
399 you have pushed a change by making a pull request.
400
401 The Yocto Project provides two scripts that conveniently let you
402 generate and send pull requests to the Yocto Project. These scripts
403 are ``create-pull-request`` and ``send-pull-request``. You can find
404 these scripts in the ``scripts`` directory within the
405 :term:`Source Directory` (e.g.
406 ``poky/scripts``).
407
408 Using these scripts correctly formats the requests without
409 introducing any whitespace or HTML formatting. The maintainer that
410 receives your patches either directly or through the mailing list
411 needs to be able to save and apply them directly from your emails.
412 Using these scripts is the preferred method for sending patches.
413
414 First, create the pull request. For example, the following command
415 runs the script, specifies the upstream repository in the contrib
416 directory into which you pushed the change, and provides a subject
417 line in the created patch files::
418
419 $ poky/scripts/create-pull-request -u meta-intel-contrib -s "Updated Manual Section Reference in README"
420
421 Running this script forms ``*.patch`` files in a folder named
422 ``pull-``\ `PID` in the current directory. One of the patch files is a
423 cover letter.
424
425 Before running the ``send-pull-request`` script, you must edit the
426 cover letter patch to insert information about your change. After
427 editing the cover letter, send the pull request. For example, the
428 following command runs the script and specifies the patch directory
429 and email address. In this example, the email address is a mailing
430 list::
431
432 $ poky/scripts/send-pull-request -p ~/meta-intel/pull-10565 -t meta-intel@lists.yoctoproject.org
433
434 You need to follow the prompts as the script is interactive.
435
436 .. note::
437
438 For help on using these scripts, simply provide the ``-h``
439 argument as follows::
440
441 $ poky/scripts/create-pull-request -h
442 $ poky/scripts/send-pull-request -h
443
444Responding to Patch Review
445--------------------------
446
447You may get feedback on your submitted patches from other community members
448or from the automated patchtest service. If issues are identified in your
449patch then it is usually necessary to address these before the patch will be
450accepted into the project. In this case you should amend the patch according
451to the feedback and submit an updated version to the relevant mailing list,
452copying in the reviewers who provided feedback to the previous version of the
453patch.
454
455The patch should be amended using ``git commit --amend`` or perhaps ``git
456rebase`` for more expert git users. You should also modify the ``[PATCH]``
457tag in the email subject line when sending the revised patch to mark the new
458iteration as ``[PATCH v2]``, ``[PATCH v3]``, etc as appropriate. This can be
459done by passing the ``-v`` argument to ``git format-patch`` with a version
460number.
461
462Lastly please ensure that you also test your revised changes. In particular
463please don't just edit the patch file written out by ``git format-patch`` and
464resend it.
465
466Submitting Changes to Stable Release Branches
467---------------------------------------------
468
469The process for proposing changes to a Yocto Project stable branch differs
470from the steps described above. Changes to a stable branch must address
471identified bugs or CVEs and should be made carefully in order to avoid the
472risk of introducing new bugs or breaking backwards compatibility. Typically
473bug fixes must already be accepted into the master branch before they can be
474backported to a stable branch unless the bug in question does not affect the
475master branch or the fix on the master branch is unsuitable for backporting.
476
477The list of stable branches along with the status and maintainer for each
478branch can be obtained from the
479:yocto_wiki:`Releases wiki page </Releases>`.
480
481.. note::
482
483 Changes will not typically be accepted for branches which are marked as
484 End-Of-Life (EOL).
485
486With this in mind, the steps to submit a change for a stable branch are as
487follows:
488
489#. *Identify the bug or CVE to be fixed:* This information should be
490 collected so that it can be included in your submission.
491
492 See :ref:`dev-manual/vulnerabilities:checking for vulnerabilities`
493 for details about CVE tracking.
494
495#. *Check if the fix is already present in the master branch:* This will
496 result in the most straightforward path into the stable branch for the
497 fix.
498
499 #. *If the fix is present in the master branch --- submit a backport request
500 by email:* You should send an email to the relevant stable branch
501 maintainer and the mailing list with details of the bug or CVE to be
502 fixed, the commit hash on the master branch that fixes the issue and
503 the stable branches which you would like this fix to be backported to.
504
505 #. *If the fix is not present in the master branch --- submit the fix to the
506 master branch first:* This will ensure that the fix passes through the
507 project's usual patch review and test processes before being accepted.
508 It will also ensure that bugs are not left unresolved in the master
509 branch itself. Once the fix is accepted in the master branch a backport
510 request can be submitted as above.
511
512 #. *If the fix is unsuitable for the master branch --- submit a patch
513 directly for the stable branch:* This method should be considered as a
514 last resort. It is typically necessary when the master branch is using
515 a newer version of the software which includes an upstream fix for the
516 issue or when the issue has been fixed on the master branch in a way
517 that introduces backwards incompatible changes. In this case follow the
518 steps in :ref:`dev-manual/changes:preparing changes for submission` and
519 :ref:`dev-manual/changes:using email to submit a patch` but modify the subject header of your patch
520 email to include the name of the stable branch which you are
521 targetting. This can be done using the ``--subject-prefix`` argument to
522 ``git format-patch``, for example to submit a patch to the dunfell
523 branch use
524 ``git format-patch --subject-prefix='&DISTRO_NAME_NO_CAP_MINUS_ONE;][PATCH' ...``.
525