Differences between revisions 19 and 57 (spanning 38 versions)
Revision 19 as of 2010-10-24 21:13:11
Size: 2896
Editor: mpm
Comment:
Revision 57 as of 2020-01-16 06:00:32
Size: 6642
Editor: aayjaychan
Comment: update link of hg-git
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Line 9: Line 8:
Line 12: Line 10:
 * [[http://bitbucket.org/tortoisehg/stable/issues|TortoiseHg]]  * [[https://bitbucket.org/mercurialeclipse/main/issues|Mercurial Eclipse]]
 * [[http://bitbucket.org/tortoisehg/thg/issues|TortoiseHg 2.x]] ~-([[http://bitbucket.org/tortoisehg/stable/issues|1.x series]])-~
Line 14: Line 13:
 * [[http://github.com/schacon/hg-git/issues|hg-git]]
 * [[http://javaforge.com/project/HGE/tracker|Mercurial Eclipse]]
 * [[https://dev.heptapod.net/mercurial/hg-git/issues|hg-git]]
Line 18: Line 16:
Mercurial's bug tracking system is located at https://bz.mercurial-scm.org/. It's used for tracking known bugs, requested features, and wishlist items.
Line 19: Line 18:
Mercurial's bug tracking system is located at http://mercurial.selenic.com/bts.
It's used for tracking known bugs, requested features, and wishlist items.
Most bug tracker usage will need you to [[https://bz.mercurial-scm.org/createaccount.cgi|register]] an account so that you can get updates on your bug reports.
Line 22: Line 20:
Most bug tracker usage will need you to [[http://mercurial.selenic.com/bts/user?@template=register|register]] an account so that you can get updates on your bug reports. == Don't send patches ==
We don't accept patches on the BTS:

 * they are hard to view
 * they are hard to comment on
 * they are hard to apply
 * they are only seen by a few people
 * all of our tooling and automation for patches is aimed at email

Since we'll never run out of patches submitted the right way that are much easier for us to deal with, your patch will go unloved. See ContributingChanges for how to send a patch we'll love.
Line 25: Line 32:
<!> Before filing a new bug, please use the [[https://bz.mercurial-scm.org/query.cgi|search form]] to try to locate similar bugs.
Line 26: Line 34:
<!> Before filing a new bug, please use the [[http://mercurial.selenic.com/bts/issue?@template=search|search form]] to try to locate similar bugs.

To create a new issue, click "Create New" under "Issues" in the sidebar. Put a ''specific'' summary of your issue in the title.
When creating a [[https://bz.mercurial-scm.org/enter_bug.cgi?product=Mercurial|new issue]], put a ''specific'' summary of your issue in the title.
Line 31: Line 37:
Please try to select the most appropriate severity:
Line 32: Line 39:
Please try to select the most appropriate priority:  * 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
Line 34: Line 42:
 * critical - data loss or security issue
 * urgent - bug that's blocking development or is a regression
 * bug - bug that's not blocking development
 * feature - it's not a bug, it's a feature
 * wish - would be nice
Once the bug is filed, there will be a priority associated with it:
Line 40: Line 44:
(A regression is defined as a bug that breaks something that worked in earlier releases.)  * critical - top priority (data loss, security issue, or major regression)
 * urgent - high priority (bug that's blocking development or is a regression)
 * normal - medium priority (no data loss involved)
 * wish - low priority (most feature requests end up in this state)
Line 42: Line 49:
=== Information it's often helpful to include in your description === {i} A regression is defined as a bug that breaks something that used to work in earlier releases.
Line 44: Line 51:
{i} Critical bugs may trigger out-of-cycle releases.

=== Helpful Information to include in your description ===
 * Whether what you're doing used to work before upgrading (this triggers special attention)
Line 49: Line 60:
 * 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
Line 51: Line 67:
Line 54: Line 69:
 * unread - no one has yet responded
 * chatting - issue is under discussion
 * need-eg - '''more information is required from the submitter'''
 * in-progress - a fix is being developed
 * testing - '''the submitter should test the fix'''
 * resolved - issue is solved
 * done-cbb - issue is not going to be fixed
 * 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'''
 * IN_PROGRESS - a fix is being developed
 * TESTING - '''the submitter should test the fix'''
 * RESOLVED - closed, issue has been fixed or rejected
Line 62: Line 76:
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 or ARCHIVED.
Line 64: Line 78:
<!> Don't comment on a resolved bug, it will reset the state to chatting! Resolutions - how a bug is closed out:

 * FIXED - the bug has been fixed or the feature has been implemented
 * INVALID - the issue was rejected
 * WONTFIX - the issue might have been valid but will not be addressed, or has stayed unresolved for too long
 * ARCHIVED - the issue might have been valid but being triaged out of the open bug set
 * DUPLICATE - a pre-existing issue covers the same topic
 * WORKSFORME - the issue could not be reproduced
Line 67: Line 88:
Line 72: Line 92:
 * don't attach patches to the wiki, see ContributingChanges instead   * don't attach patches to the BTS, see ContributingChanges instead
Line 74: Line 94:
== Why we auto-close old issues ==
You may have noticed your issue got moved to RESOLVED ARCHIVED automatically after several months of inactivity.
Line 75: Line 97:
See ManagingBugs for the developer side of the process. We have finite resources so not all issues will get attention. If we leave issues we don't prioritize open indefinitely, we'll have backlog that grows without limit, primarily populated by low-priority issues of unknown relevance to current Mercurial.

Experience has shown that no one is regularly motivated to dig through a huge, low-quality backlog because there's always new stuff to work on. This means as soon as an issue stops being active, it can disappear entirely from developers' radar, even if it's important. This is no good, so we have to do something to keep the backlog from growing indefinitely.

We could aggressively close bugs we don't want to work on. But this has two problems: we often intend to work on things, and we don't want to spend our time arguing about which bugs are important. The alternative is to automatically close bugs that no one seems to be interested in. The aim here is to get a shorter, higher-quality backlog that developers actually pay attention to and thus improve our overall responsiveness to bug reports.

That said, if you feel your issue is still relevant, please feel free to test against current Mercurial and re-open it.

== Shirt ==
People reporting regressions during release candidate phase will be sent a shirt (as stock permit). Here are the current available colors:

 * black: [[attachment:black-shirt.jpg|{{attachment:black-shirt.jpg||width=100}}]]
 * dark blue [[attachment:blue-shirt.jpg|{{attachment:blue-shirt.jpg||width=100}}]]
 * light grey [[attachment:light-grey-shirt.jpg|{{attachment:light-grey-shirt.jpg||width=100}}]]
 * dark grey [[attachment:dark-grey-shirt.jpg|{{attachment:dark-grey-shirt.jpg||width=100}}]]
 * models in mercurial shirts [[attachment:panel.jpg|{{attachment:panel.jpg||width=100}}]]

== See also ==
 * ManagingBugs for the developer side of the process
 * [[IRC]] for real-time diagnosis and support
 * Our [[MailingLists|mailing lists]] for general discussion

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 https://bz.mercurial-scm.org/. 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. Don't send patches

We don't accept patches on the BTS:

  • they are hard to view
  • they are hard to comment on
  • they are hard to apply
  • they are only seen by a few people
  • all of our tooling and automation for patches is aimed at email

Since we'll never run out of patches submitted the right way that are much easier for us to deal with, your patch will go unloved. See ContributingChanges for how to send a patch we'll love.

4. 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.

4.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, security issue, or major regression)
  • urgent - high priority (bug that's blocking development or is a regression)
  • normal - medium priority (no data loss involved)
  • wish - low priority (most feature requests end up in this state)

{i} A regression is defined as a bug that breaks something that used to work in earlier releases.

{i} Critical bugs may trigger out-of-cycle releases.

4.2. Helpful Information to include in your description

  • Whether what you're doing used to work before upgrading (this triggers special attention)
  • 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

5. 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

  • 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 or ARCHIVED.

Resolutions - how a bug is closed out:

  • FIXED - the bug has been fixed or the feature has been implemented
  • INVALID - the issue was rejected
  • WONTFIX - the issue might have been valid but will not be addressed, or has stayed unresolved for too long
  • ARCHIVED - the issue might have been valid but being triaged out of the open bug set
  • DUPLICATE - a pre-existing issue covers the same topic
  • WORKSFORME - the issue could not be reproduced

6. 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 BTS, see ContributingChanges instead

7. Why we auto-close old issues

You may have noticed your issue got moved to RESOLVED ARCHIVED automatically after several months of inactivity.

We have finite resources so not all issues will get attention. If we leave issues we don't prioritize open indefinitely, we'll have backlog that grows without limit, primarily populated by low-priority issues of unknown relevance to current Mercurial.

Experience has shown that no one is regularly motivated to dig through a huge, low-quality backlog because there's always new stuff to work on. This means as soon as an issue stops being active, it can disappear entirely from developers' radar, even if it's important. This is no good, so we have to do something to keep the backlog from growing indefinitely.

We could aggressively close bugs we don't want to work on. But this has two problems: we often intend to work on things, and we don't want to spend our time arguing about which bugs are important. The alternative is to automatically close bugs that no one seems to be interested in. The aim here is to get a shorter, higher-quality backlog that developers actually pay attention to and thus improve our overall responsiveness to bug reports.

That said, if you feel your issue is still relevant, please feel free to test against current Mercurial and re-open it.

8. Shirt

People reporting regressions during release candidate phase will be sent a shirt (as stock permit). Here are the current available colors:

  • black: attachment:black-shirt.jpg

  • dark blue attachment:blue-shirt.jpg

  • light grey attachment:light-grey-shirt.jpg

  • dark grey attachment:dark-grey-shirt.jpg

  • models in mercurial shirts attachment:panel.jpg

9. See also


CategoryBugs CategoryProject

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