Bug 237

Does this warrant an entire manual?  Maybe a wiki page that has Bugzilla guidelines and processes?  This information needs to be documented somewhere.  I am just not convinced yet that it should be under its own cover.

Yes, a wiki page or a section in the manual should be fine. It doesn't need to be a manual in its own right,

changed to enhancement.

I am looking into this bug and I think that if our wiki page at https://wiki.yoctoproject.org/wiki/Bugzilla_Configuration_and_Bug_Tracking was updated (or verified) I could update the existing "Bugzilla" section in the YP Development Manual to provide enough guidance on how to report a bug.

I have made some updates to the wiki page regarding fields for things like releases, projects, etc.  Some stuff I don't have the information to update the page with however, Could someone verify or correct this section in the wiki that has to do with status?  The link for this section in the wiki is:

https://wiki.yoctoproject.org/wiki/Bugzilla_Configuration_and_Bug_Tracking#Bug_Status

---------------

Bug Status

    * Open -- A new reported bug with default assignee.
    * ACCEPTED-- The assigned developer has reviewed and accept the bug.
    * Resolved -- bug is fixed or closed by other resolved method.
          o Fixed -- This is fixed and in the master branch will be set automatically during build
          o NotABug -- This is verified as not a bug
          o WontFix -- We will not fix this bug, possibly because a newer package fixes it
          o Duplicate -- Duplicate of another bug, possibly different failure mode
          o Invalid -- The bug is invalid, sometimes this is used when the author of the bug does not provide accurate information, these will be reviewed by Triage team, and could be changed to NeedInfo
          o Obsolete -- The bug is obsolete, old bug that is no longer appropriate, or a package that is depercated.
          o WorksForMe -- The bug does not appear when tested by engineer, more appropriately, this may be NeedInfo 
    * Verified -- bug is double checked and agreed with the resolved method by original reporter.
    * Reopen: bug can be reopened, if it is in Resolved, Verified or Close stage.
    * NeedInfo: bug needs be set to NeedInfo, if there is important information missing to understand or reproduce bug.
    * WaitForUpstream: The owner does bug analysis and finds this bug comes from upstream. Owner can post a new bug in upstream bugzilla, change status to WaitForUpstream and add the upstream bugzilla URL in comment area. When upstream bug is fixed, put the bug fixing into Yocto repository. After the patch is built into weekly build, change its status to Resolved/FIXED.
    * Close stage is not used in normal bug life. When reported two same bugs by wrongly click button twice, the 2nd one can be closed. Generally it(close stage) is just for keeping wrong bug out of scrub cycle and statistic.

I updated the section in the YP Development Manual titled "Bug Tracking."  This section now overviews the Bugzilla tool, references the wiki page that talks about Bugzilla and how we handle bugs.  The section now also overviews the process for logging a new bug.  This section and the information in the wiki should be adequate for this bug.


NOTE:  Someone familiar with the bug process should go in and update the information on the wiki page.  It is really out of date.  I updated what I could but am not familiar with a lot of the policies.