diff options
author | Scott Rifenbark <scott.m.rifenbark@intel.com> | 2011-11-23 10:50:48 -0800 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2011-11-25 15:24:19 +0000 |
commit | 31c4229d3c0452697c7277f61c77294ffb6d6ebb (patch) | |
tree | 377ed151a1e35d75858c321287ab8712a6974479 /documentation | |
parent | ac174aaeba7bd5db2f877650d0e969ac49265ac3 (diff) | |
download | ast2050-yocto-poky-31c4229d3c0452697c7277f61c77294ffb6d6ebb.zip ast2050-yocto-poky-31c4229d3c0452697c7277f61c77294ffb6d6ebb.tar.gz |
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: 8f2702444812c9dc25195340acebbaae15cd59d7)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation')
-rw-r--r-- | documentation/dev-manual/dev-manual-newbie.xml | 75 |
1 files changed, 45 insertions, 30 deletions
diff --git a/documentation/dev-manual/dev-manual-newbie.xml b/documentation/dev-manual/dev-manual-newbie.xml index 0efcbbb..1422384 100644 --- a/documentation/dev-manual/dev-manual-newbie.xml +++ b/documentation/dev-manual/dev-manual-newbie.xml @@ -545,44 +545,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>. + submit and review patches, and can be used to manage quality assurance. + 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>. - </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: - <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>. - 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> + <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> + + <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 would be <filename>[YOCTO #1011]</filename>. + This convention becomes important if you are submitting patches against the Yocto Project + code itself. + </note> </section> <section id='how-to-submit-a-change'> |