report-defect.rst 3.1 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667
  1. .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
  2. Reporting a Defect Against the Yocto Project and OpenEmbedded
  3. **************************************************************
  4. You can use the Yocto Project instance of
  5. `Bugzilla <https://www.bugzilla.org/about/>`__ to submit a defect (bug)
  6. against BitBake, OpenEmbedded-Core, against any other Yocto Project component
  7. or for tool issues. For additional information on this implementation of
  8. Bugzilla see the ":ref:`Yocto Project Bugzilla <resources-bugtracker>`" section
  9. in the Yocto Project Reference Manual. For more detail on any of the following
  10. steps, see the Yocto Project
  11. :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`.
  12. Use the following general steps to submit a bug:
  13. #. Open the Yocto Project implementation of :yocto_bugs:`Bugzilla <>`.
  14. #. Click "File a Bug" to enter a new bug.
  15. #. Choose the appropriate "Classification", "Product", and "Component"
  16. for which the bug was found. Bugs for the Yocto Project fall into
  17. one of several classifications, which in turn break down into
  18. several products and components. For example, for a bug against the
  19. ``meta-intel`` layer, you would choose "Build System, Metadata &
  20. Runtime", "BSPs", and "bsps-meta-intel", respectively.
  21. #. Choose the "Version" of the Yocto Project for which you found the
  22. bug (e.g. &DISTRO;).
  23. #. Determine and select the "Severity" of the bug. The severity
  24. indicates how the bug impacted your work.
  25. #. Choose the "Hardware" that the bug impacts.
  26. #. Choose the "Architecture" that the bug impacts.
  27. #. Choose a "Documentation change" item for the bug. Fixing a bug might
  28. or might not affect the Yocto Project documentation. If you are
  29. unsure of the impact to the documentation, select "Don't Know".
  30. #. Provide a brief "Summary" of the bug. Try to limit your summary to
  31. just a line or two and be sure to capture the essence of the bug.
  32. #. Provide a detailed "Description" of the bug. You should provide as
  33. much detail as you can about the context, behavior, output, and so
  34. forth that surrounds the bug. You can even attach supporting files
  35. for output from logs by using the "Add an attachment" button.
  36. #. Click the "Submit Bug" button submit the bug. A new Bugzilla number
  37. is assigned to the bug and the defect is logged in the bug tracking
  38. system.
  39. Once you file a bug, the bug is processed by the Yocto Project Bug
  40. Triage Team and further details concerning the bug are assigned (e.g.
  41. priority and owner). You are the "Submitter" of the bug and any further
  42. categorization, progress, or comments on the bug result in Bugzilla
  43. sending you an automated email concerning the particular change or
  44. progress to the bug.
  45. There are no guarantees about if or when a bug might be worked on since an
  46. open-source project has no dedicated engineering resources. However, the
  47. project does have a good track record of resolving common issues over the
  48. medium and long term. We do encourage people to file bugs so issues are
  49. at least known about. It helps other users when they find somebody having
  50. the same issue as they do, and an issue that is unknown is much less likely
  51. to ever be fixed!