Differences between revisions 30 and 31
Revision 30 as of 2012-05-12 17:03:09
Size: 3417
Editor: JohnHein
Comment: fix instructions for reporting new bugs
Revision 31 as of 2012-08-14 19:37:28
Size: 3994
Comment:
Deletions are marked like this. Additions are marked like this.
Line 26: Line 26:
Please try to select the most appropriate priority: Please try to select the most appropriate severity:

 * bug - the software isn't working as you expect
 * feature - it's not a bug, it's a feature request, good patches will probably be accepted

Once the bug is filed, there will be a priority associated with it:
Line 30: Line 35:
 * bug - normal priority (bug that's not blocking development)
 * feature - eventually (it's not a bug, it's a feature request, good patches will probably be accepted)
 * normal - medium priority (no data loss involved)
Line 51: Line 55:
 * unread - no one has yet responded
 * chatting - issue is under discussion
 * need-eg - '''more information is required from the submitter''' (e.g.: abbr. of Latin ''exempli gratia'')
 * in-progress - a fix is being developed
 * testing - '''the submitter should test the fix'''
 * resolved - closed, issue is solved
 * done-cbb - closed, issue is not going to be fixed (cbb = could be better / can't be bothered)
 * UNCONFIRMED - no one has yet triaged the report
 * CONFIRMED - a maintainer believes the report is valid, and the issue is under discussion
 * NEED_EXAMPLE - '''more information is required from the submitter''' (e.g.: abbr. of Latin ''exempli gratia'')
 * IN_PROGRESS - a fix is being developed
 * TESTING - '''the submitter should test the fix'''
 * RESOLVED - closed, issue has been fixed or rejected
Line 59: Line 62:
Issues in the need-eg and testing states will get marked resolved if there is no further activity. Issues in the NEED_EXAMPLE and TESTING states will be marked RESOLVED if there is no further activity. If a bug stays "stuck" in some unresolved state for a long time, it may eventually be resolved as WONTFIX.

Resolutions - how a bug is closed out:

 * FIXED - the bug has been fixed or the feature has been implemented
 * INVALID - the issue was rejected, or no progress was made for a long time
 * WONTFIX - the issue might have been valid, but will not be addressed
 * DUPLICATE - a pre-existing issue covers the same topic
 * WORKSFORME - the issue could not be reproduced

Bug Tracker

Using the Mercurial bug tracker.

1. Finding the right bug tracker

Please first check if your issue is caused by a GUI tool or third-party extension. Other bug trackers include:

2. Getting started

Mercurial's bug tracking system is located at http://bz.selenic.com/. It's used for tracking known bugs, requested features, and wishlist items.

Most bug tracker usage will need you to register an account so that you can get updates on your bug reports.

3. Creating a new issue

<!> Before filing a new bug, please use the search form to try to locate similar bugs.

When creating a new issue, put a specific summary of your issue in the title.

3.1. Choosing a priority

Please try to select the most appropriate severity:

  • bug - the software isn't working as you expect
  • feature - it's not a bug, it's a feature request, good patches will probably be accepted

Once the bug is filed, there will be a priority associated with it:

  • critical - top priority (data loss or security issue)
  • urgent - high priority (bug that's blocking development or is a regression)
  • normal - medium priority (no data loss involved)
  • wish - very low priority (it could perhaps be nice to have but is close to a done-cbb resolution)

(A regression is defined as a bug that breaks something that worked in earlier releases.)

3.2. Helpful Information to include in your description

  • The version of Mercurial you're using
  • The operating system you're using
  • Any third-party tools you're using
  • The command you were running
  • The precise traceback or error message you received
  • If you're using Windows, anything unusual about your setup, including but not limited to:
    • VirtualBox

    • CygWin

    • using network shares
    • using an on-access virus scanner

4. The life cycle of a bug

As a bug is tracked, it will go through various states, some of which will demand your attention:

  • UNCONFIRMED - no one has yet triaged the report
  • CONFIRMED - a maintainer believes the report is valid, and the issue is under discussion
  • NEED_EXAMPLE - more information is required from the submitter (e.g.: abbr. of Latin exempli gratia)

  • IN_PROGRESS - a fix is being developed
  • TESTING - the submitter should test the fix

  • RESOLVED - closed, issue has been fixed or rejected

Issues in the NEED_EXAMPLE and TESTING states will be marked RESOLVED if there is no further activity. If a bug stays "stuck" in some unresolved state for a long time, it may eventually be resolved as WONTFIX.

Resolutions - how a bug is closed out:

  • FIXED - the bug has been fixed or the feature has been implemented
  • INVALID - the issue was rejected, or no progress was made for a long time
  • WONTFIX - the issue might have been valid, but will not be addressed
  • DUPLICATE - a pre-existing issue covers the same topic
  • WORKSFORME - the issue could not be reproduced

5. Etiquette

  • be responsive - developers are very busy
  • try to answer the specific questions asked by developers
  • paste tracebacks into message fields rather than uploading attachments
  • test fixes!
  • don't attach patches to the wiki, see ContributingChanges instead

6. See also


CategoryBugs CategoryProject

BugTracker (last edited 2020-01-16 06:00:32 by aayjaychan)