diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml
index c85667cdd1..08b4747480 100644
--- a/documentation/dev-manual/dev-manual-newbie.xml
+++ b/documentation/dev-manual/dev-manual-newbie.xml
@@ -542,44 +542,59 @@
Tracking Bugs
- The Yocto Project uses Bugzilla to track bugs.
- This bug-tracking application works well for group development because it tracks bugs and code
+ The Yocto Project uses its own implementation of
+ Bugzilla to track bugs.
+ Implementations of Bugzilla work well for group development because they track bugs and code
changes, can be used to communicate changes and problems with developers, can be used to
- submit and review patches, and can be used to manage quality assurance.
- You can find a good overview of Bugzilla here.
+ submit and review patches, and can be used to manage quality assurance.
+ The home page for the Yocto Project implementation of Bugzilla is
+ http://bugzilla.yoctoproject.org.
Sometimes it is helpful to submit, investigate, or track a bug against the Yocto Project itself
such as when discovering an issue with some component of the build system that acts contrary
to the documentation or your expectations.
- You can find information
- for Bugzilla configuration and bug tracking procedures specific to the Yocto Project
+ Following is the general procedure for submitting a new bug using the Yocto Project
+ Bugzilla.
+ You can find more information on defect management, bug tracking, and feature request
+ processes all accomplished through the Yocto Project Bugzilla on the wiki page
here.
+
+ Always use the Yocto Project implementation of Bugzilla to submit
+ a bug.
+ When submitting a new bug, be sure to choose the appropriate
+ Classification, Product, and Component for which the issue was found.
+ Defects for Yocto Project fall into one of four classifications: Yocto Projects,
+ Infrastructure, Poky, and Yocto Metadata Layers.
+ Each of these Classifications break down into multiple Products and, in some
+ cases, multiple Components.
+ Use the bug form to choose the correct Hardware and Architecture
+ for which the bug applies.
+ Indicate the Yocto Project version you were using when the issue
+ occurred.
+ Be sure to indicate the Severity of the bug.
+ Severity communicates how the bug impacted your work.
+ Provide a brief summary of the issue.
+ Try to limit your summary to just a line or two and be sure to capture the
+ essence of the issue.
+ Provide a detailed description of the issue.
+ You should provide as much detail as you can about the context, behavior, output,
+ and so forth that surround the issue.
+ You can even attach supporting files for output or log by using the "Add an attachment"
+ button.
+ Submit the bug by clicking the "Submit Bug" button.
+
-
-
- The Yocto Project uses its own version of the Bugzilla application.
- You can find the home page here.
- You need to use this implementation of Bugzilla when logging a defect against anything released
- by the Yocto Project team.
-
-
-
- Here are some things to remember when dealing with bugs against the Yocto Project:
-
- The Yocto Project follows a bug-naming convention:
- [YOCTO #<number>], where <number> is the
- assigned defect ID used in Bugzilla.
- So, for example, a valid way to refer to a defect when creating a commit comment
- would be [YOCTO #1011].
- This convention becomes important if you are submitting patches against the Yocto Project
- code itself.
- See the following section for more information.
- Defects for Yocto Project fall into one of four classifications: Yocto Projects,
- Infrastructure, Poky, and Yocto Metadata Layers.
-
-
+
+
+ Bugs in the Yocto Project Bugzilla follow naming convention:
+ [YOCTO #<number>], where <number> is the
+ assigned defect ID used in Bugzilla.
+ So, for example, a valid way to refer to a defect would be [YOCTO #1011].
+ This convention becomes important if you are submitting patches against the Yocto Project
+ code itself.
+