Bazaar

Bazaar

 

Wiki Tools

  • Login
  • Create Profile
  • FindPage
  • RecentChanges
  • Page History
  • Attachments
Bazaar news
Blogs

Contents

  1. Bug Guidelines
    1. Anyone can edit a bug
    2. Bug fields
      1. Status
      2. Importance
      3. Tags
    3. Other remarks

Bug Guidelines

bzr bugs are tracked in Launchpad at http://launchpad.net/products/bzr/+bugs

Here are some guidelines for using it, and definitions of terms specific to bzr:

Anyone can edit a bug

The bugs should be editable by anyone with a launchpad account, which can be obtained easily.

Bug fields

Here's a description of how to use the Status and Severity fields of a bug.

Status

  • Confirmed — someone has looked at the bug and confirmed that the behaviour can occur and that this is a proper bug which can be fixed; anyone is welcome to confirm bugs, but there should be some investigation beyond just reading it

  • In progress — there is some work on this bug, e.g. diagnosing how to fix it, a patch that's not committed yet, etc.

  • Fix committed — a fix for this bug has been committed into someone's branch somewhere.

  • Fix released — the fix is merged into the bzr.dev branch. (It may not be strictly "released" as a tarball yet but this definition seems best.) Please put the milestone for the upcoming release into the bug change message and the bug target milestone.

If we put the upcoming release into the bug target milestone then a page such as https://launchpad.net/products/bzr/+milestone/0.10 can show which bug fixes will be new in that release (the ones marked "fix released") and which are/were meant to be fixed but have not been.

Importance

The key thing is that this suggests the order/priority in which tasks should be fixed. (So, it's useless to leave all tasks "normal".) Some requests for enhancement may be much more important than some "bugs" or defects that are of limited scope/impact.

Note also that something may be very important even if there is no consensus yet about how it should behave or the right way to fix it.

  • wishlist — Generally for feature requests that are not defects. Indicate a broadening of the scope or functionality of bzr. People using bzr for currently supported operations won't suffer from the lack of it, though they might enjoy it if it's there. Bugs that cause a traceback shouldn't be here.

  • low — The shortcoming affects niche or rarely used functionality. Many "correct but confusing" bugs will be here.

  • medium — Default.

  • high — This affects a commonly used feature/operation/behaviour (commit, log, branch, push), etc, and so will affect most users in day to day work. Also includes bugs we strongly desire to fix for a particular release — may be a feature goal. ("Their time has come...")

  • critical — So important that a release will be done for this. (Either the current release will slip or move forward or a special point release in the previous series, etc...) Some examples might be data loss bugs or extreme "can't get any work done" issues.

Tags

Here are some commonly used bugs tags:

  • authentication — authenticating to servers

  • backport — candidate for backporting to an update of the previous release

  • dirstate — WorkingTree4

  • easy — should be possible to finish in an hour or two

  • hpss — bugs about the High-Performance Smart Server, i.e. bzr+ssh://, etc.

  • launchpad — bugs about interactions with launchpad (typically this means bzrlib.plugins.launchpad).

  • locale — problems using locales other than English

  • memory — problems where we use too much memory for some reason

  • newformat — fixing this would need a new disk format

  • performance — bugs about performance problems.

  • test — needs changes to the test framework

  • transport — virtual filesystem for http, sftp, etc

  • trivial — should be very easy to fix (10-20 minutes) and easily landed: typically just spelling errors and the like

  • ui — bugs relating to the bzr user interface, e.g. confusing error messages.

  • win32 — bugs that mainly affects Windows. Also there is cygwin and win98 tags for marking specific bugs.

You can see the full list of tags in use at https://bugs.launchpad.net/bzr/+bugs — as of September 2008 the list is on the right.

Other remarks

These are guidelines and there can be some flex: for example a bug for which there is a fairly easy & obvious workaround may be somewhat less serious than otherwise.

Behaviour that is "correct but confusing" can be taken into account too — bugs asking that bzr explain better what it's doing can be minor not wishlist if they are likely to confuse typical users on common operations.

Specifications should be created for issues requiring a large code, design or behaviour change; or where the design will take si