documentation/dev-manual/dev-manual-newbie.xml: Updates to Bugzilla use
I updated the Bug Tracking section to include rudimentary use of Bugzilla for entering a new bug. Fixes [YOCTO #237] (From yocto-docs rev: 425965d7562f990c1f46901220caf4d79313336a) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
parent
c5bdef5617
commit
fda17235fd
|
@ -542,44 +542,59 @@
|
|||
<title>Tracking Bugs</title>
|
||||
|
||||
<para>
|
||||
The Yocto Project uses <ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink> 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
|
||||
<ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink> 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 <ulink url='http://www.bugzilla.org/about/'>here</ulink>.
|
||||
The home page for the Yocto Project implementation of Bugzilla is
|
||||
<ulink url='http://bugzilla.yoctoproject.org'>http://bugzilla.yoctoproject.org</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
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
|
||||
<ulink url='https://wiki.yoctoproject.org/wiki/Bugzilla_Configuration_and_Bug_Tracking'>here</ulink>.
|
||||
<orderedlist>
|
||||
<listitem><para>Always use the Yocto Project implementation of Bugzilla to submit
|
||||
a bug.</para></listitem>
|
||||
<listitem><para>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.</para></listitem>
|
||||
<listitem><para>Use the bug form to choose the correct Hardware and Architecture
|
||||
for which the bug applies.</para></listitem>
|
||||
<listitem><para>Indicate the Yocto Project version you were using when the issue
|
||||
occurred.</para></listitem>
|
||||
<listitem><para>Be sure to indicate the Severity of the bug.
|
||||
Severity communicates how the bug impacted your work.</para></listitem>
|
||||
<listitem><para>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.</para></listitem>
|
||||
<listitem><para>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.</para></listitem>
|
||||
<listitem><para>Submit the bug by clicking the "Submit Bug" button.</para></listitem>
|
||||
</orderedlist>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The Yocto Project uses its own version of the Bugzilla application.
|
||||
You can find the home page <ulink url='http://bugzilla.yoctoproject.org'>here</ulink>.
|
||||
You need to use this implementation of Bugzilla when logging a defect against anything released
|
||||
by the Yocto Project team.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Here are some things to remember when dealing with bugs against the Yocto Project:
|
||||
<itemizedlist>
|
||||
<listitem><para>The Yocto Project follows a bug-naming convention:
|
||||
<note>
|
||||
Bugs in the Yocto Project Bugzilla follow naming convention:
|
||||
<filename>[YOCTO #<number>]</filename>, where <filename><number></filename> 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 <filename>[YOCTO #1011]</filename>.
|
||||
So, for example, a valid way to refer to a defect would be <filename>[YOCTO #1011]</filename>.
|
||||
This convention becomes important if you are submitting patches against the Yocto Project
|
||||
code itself.
|
||||
See the following section for more information.</para></listitem>
|
||||
<listitem><para>Defects for Yocto Project fall into one of four classifications: Yocto Projects,
|
||||
Infrastructure, Poky, and Yocto Metadata Layers.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</note>
|
||||
</section>
|
||||
|
||||
<section id='how-to-submit-a-change'>
|
||||
|
|
Loading…
Reference in New Issue