How to report bugs in bugzilla

Submitted by Wan Shuang, updated on 16 Nov 2009

Create account

The http://bugzilla.moblin.org authentication system is integrated with the http://moblin.org authentication system, so the same account is used both for mobin.org and bugzilla.moblin.org. Select the link "Create/Manage user account" from the http://bugzilla.moblin.org home page to open the moblin.org registration page. To register a new account, you must confirm your account by following the link you received in your email and changing your password on moblin.org, before attempting to log into bugzilla.

Bugzilla Field Definition

Usage (Hardware/Platform)

The "Usage" field is one of the most important fields for bug reporting because we use one bugzilla product to track Moblin distribution bugs for all usage models. Select the usage where you found the bug, such as MID, netbook, nettop, IVI or Embedded.

Version

Version field describes bugs found in which version. Currently 4 version names are defined: 2.0, 2.1, 2.1 Update, 2.2.

Target Milestone

Used by Developers, QA and other bug submitter to propose which version this bug is expected to be fixed.

  • --- Undecided
  • 2.1 Propose bug is expected to be fixed in 2.1
  • 2.1 Update Propose bug is expected to be fixed in 2.1 Update
  • 2.2 Propose bug is expected to be fixed in 2.2

Severity

The "Severity" field describes the impact of a bug, and the options include:

  • Critical: crashes, other components are affected
  • Major: major loss of own function
  • Normal: regular issue, some loss of functionality under specific circumstances
  • Minor: minor loss of function, or other problem, where an easy workaround is present
  • Enhancement: request for enhancement

Bug Life Cycle

Considering that the community users are the main bug submitters, we can put the lifecycle graph at https://bugzilla.moblin.org/docs/en/html/using.html

Bug Reporting Guideline

  1. Each bug report is for only one issue. If you find several issues in one test, please separate them into several bugs.
  2. Write a precise summary (bug title). A good summary should be straightforward and precise, to clearly identify the issue.
  3. List the exact steps to reproduce the bug (bash commands, results after executing the commands etc, instead of only paraphrasing). For example, instead of paraphrasing commands by saying:

    4. "suspend the system or put system to S3"

    we prefer to see the following exact commands as steps to reproduce the bug:

    # % echo mem >/sys/power/state

  4. Reproducibility. For bugs which are not 100% reproducible, please provide the steps to reproduce the bug, along with an estimate of the probability of reproduction.
  5. Impact to system or user. Provide a description of the impact to the system or user.