1
***********************
2
Tracking Bugs in Bazaar
3
***********************
5
This document describes the bug-tracking processes for developing Bazaar
6
itself. Bugs in Bazaar are recorded in Launchpad.
11
* `Bazaar Developer Documents <index.html>`_.
13
* `The Bazaar Development Cycle <cycle.html>`_.
15
* `The Bazaar User Guide <../en/user-guide/index.html>`_ -- for
16
information on integrating Bazaar with other bug trackers.
22
* `bzr bugs home page <https://bugs.edge.launchpad.net/bzr>`_.
24
* `Critical bugs <https://bugs.edge.launchpad.net/bzr/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed>`_.
26
* `Open bugs by importance <https://bugs.edge.launchpad.net/bzr/+bugs>`_.
28
* `Open bugs most recently changed first
29
<https://bugs.edge.launchpad.net/bzr/+bugs?field.searchtext=&orderby=-date_last_updated&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=>`_.
35
Anyone involved with Bazaar is welcome to contribute to managing our bug
36
reports. **Edit boldly**: try to help users out, assess importance or improve
37
the bug description or status. Other people will see the bugs: it's
38
better to have 20 of them processed and later change the status of a
39
couple than to leave them lie.
41
When you file a bug as a Bazaar developer or active user, if you feel
42
confident in doing so, make an assessment of status and importance at the
43
time you file it, rather than leaving it for someone else. It's more
44
efficient to change the importance if someone else feel's it's higher or
45
lower, than to have someone else edit all bugs.
47
It's more useful to actually ship bug fixes than to garden the bug
48
database. It's more useful to take one bug through to a shipped fix than
49
to partially investigate ten bugs. You don't get credit for a bug until
50
the fix is shipped in a release. Users like getting a response to their
51
report, but they generally care more about getting bugs fixed.
53
The aim of investigating bugs before starting concentrated work on them is
56
* determine if they are critical or high priority (and
57
should displace existing work)
59
* garden sufficiently to keep the database usable: meaningful summaries,
60
and duplicates removed
62
It's OK to fix some bugs that just annoy you, even if they're not
65
You can use ``--fixes lp:12345678`` when committing to associate the
66
commit with a particular bug.
68
If there are multiple bugs with related fixes, putting "[master]" in the
69
title of one of them helps find it
71
It's often fastest to find bugs just using the regular Google search
72
engine, rather than Launchpad's search.
76
| One of the things you should not do often is to start asking
77
| questions/for more debug info and then forget about the bug. It's just
78
| a waste of the reporter's and your time, and will create frustration
79
| on the reporter side.
85
The suggested priorities for bug work are:
89
2. Get existing fixes through review and landed.
91
3. Fix bugs that are already in progress.
93
4. Look at bugs already assigned to you, and either start them, or change
94
your mind and unassign them.
96
5. Take new bugs from the top of the stack.
100
It's not strict and of course there is personal discretion but our work
101
should be biased to the top of this hierarchy.
107
Bugs should have clear edges, so that you can make a clear statement about
108
whether a bug is fixed or not. (Sometimes reality is complicated, but aim
109
for each bug to be clear.)
111
Bugs on documentation, performance, or UI are fine as long as they're
114
Examples of good bugs:
116
* "ValueError in frob_foo when committing changed symlink" - although
117
there may be many possible things that could cause a ValueError there,
118
you should at least know when you've fixed the problem described in this
121
* "Unclear message about incompatible repositories" - even though the user
122
may not agree the new message is sufficiently clear, at least you know
123
when you've tried to fix it.
125
Examples of bad bugs:
127
* "Commit is too slow" - how fast is fast enough to close it? "Commit
128
reads the working tree twice" is clearer.
135
The bug has just been filed and hasn't been examined by a developer
138
The bug requires more information from the reporter to make progress.
140
The bug report has been seen by a developer and we agree it's a bug.
141
You don't have to reproduce the bug to mark it confirmed. (Generally
142
it's not a good idea for a developer to spend time reproducing the bug
143
until they're going to work on it.)
145
This is an odd state - one we consider a bug in launchpad, as it really
146
means "Importance has been set". We use this to mean the same thing
147
as confirmed, and set no preference on whether Confirmed or Triaged are
148
used. Please do not change a "Confirmed" bug to "Triaged" or vice verca -
149
any reports we create or use will always search for both "Confirmed" and
150
"Triaged" or neither "Confirmed" nor "Triaged".
152
Someone has started working on this.
154
The behaviour complained about is intentional and we won't fix it.
155
Needless to say, be thoughtful before using this status, and consider if
156
the user experience can be improved in some other way.
158
The reporter was confused, and this is not actually a bug.
159
Again, be sensitive in explaining this to the user.
161
A fix for this bug exists in a branch somewhere. Ideally the bug will
162
be linked to the branch.
164
The fix for this bug is now in the bzr trunk. It's not necessarily
165
true that it's released yet, but it will be in the next release. The
166
bug target milestone should be set to the release it went into, but
167
don't spend too much time updating this if you don't immediately know.
174
This is a serious bug that could cause data loss, stop bzr being
175
usable in an important case, or represents a regression in something
176
previously working. We should fix critical bugs before doing other
177
work, or seriously consider whether the bug is really critical
178
or whether the other change is more urgent.
180
This is a bug that can seriously interfere with people's use of
181
Bazaar. We should seriously consider fixing these bugs before
182
working on new features.
184
A regular bug. We'd like to fix them, but there may be a long delay.
186
Something suboptimal that may affect an unimportant case or have a
187
fairly easy workaround.
189
These will basically never get done.
191
Bugs rated Medium or lower are unlikely to get fixed unless they either
192
pique the interest of a developer or are escalated due eg to many users
195
Not every existing bug is correctly rated according to this scale, and we
196
don't always follow this process, but we'd like to do it more. But
197
remember, fixing bugs is more helpful than gardening them.
203
Assigning a bug to yourself, or someone else, indicates a real intention
204
to work on that bug soon.
210
It's possible to target a bug to a milestone, eg
211
<https://bugs.edge.launchpad.net/bzr/+milestone/1.16>. We use this mostly
212
to help the release manager know what **must** be merged to make the
215
Therefore, we don't target bugs that we'd like to have fixed or that could
216
be fixed in a particular release, we only target bugs that must be fixed
217
and that will or might cause us to decide to slip the release if they're
218
not fixed. At any time, very few if any of the bugs targetted to a
219
release should be still open. By definition, these bugs should normally
220
be Critical priority.
226
Sometimes we'll want to make a special point-release update (eg 1.15.1)
227
off an already-released branch including a fix for a particular bug. To
228
represent this, create a new bug task (ie link in the status table on the
229
bug page) by clicking the `poorly-named
230
<https://bugs.launchpad.net/bugs/132733>`_ "Target to Release" link.
231
Target it to the appropriate series (ie 1.15) and then to the milestone
234
This bug task then has a separate status and importance to indicate the
235
separate work to get it into that release.
241
Most bugs that are fixed should be mentioned in a `NEWS
242
<../en/release-notes/NEWS.html>`_ file entry,
243
including the bug number.
244
(Exceptions might be bugs that are not at all user visible.)
250
Here are some bug tags we use. In Malone tags are currently of limited use, so don't feel obliged to tag bugs unless you're finding it useful.
254
authenticating to servers
257
candidate for backporting to an update of the previous release
263
should be possible to finish in an hour or two
266
bugs about the High-Performance Smart Server, i.e. bzr+ssh://, etc.
269
bugs for causes of VFS methods of the smart server
272
bugs about interactions with launchpad (typically this means bzrlib.plugins.launchpad).
275
problems using locales other than English
278
problems where we use too much memory for some reason
281
fixing this would need a new disk format
284
bugs about performance problems.
287
needs changes to the test framework
290
virtual filesystem for http, sftp, etc
293
should be very easy to fix (10-20 minutes) and easily landed: typically just spelling errors and the like
296
bugs relating to the bzr user interface, e.g. confusing error messages.
299
bugs that mainly affects Windows. Also there is cygwin and win98 tags for marking specific bugs.
301
You can see the full list of tags in use at
302
<https://bugs.edge.launchpad.net/bzr/+bugs>. As of September 2008 the
303
list is on the right.
added
removed
doc/developers/bug-handling.txt
