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.launchpad.net/bzr>`_.
24
* `Critical bugs <https://bugs.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.launchpad.net/bzr/+bugs>`_.
28
* `Open bugs most recently changed first
29
<https://bugs.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=>`_.
31
* `Most commonly duplicated bugs <http://tinyurl.com/bzr-bugs-by-dupes>`_.
37
Anyone involved with Bazaar is welcome to contribute to managing our bug
38
reports. **Edit boldly**: try to help users out, assess importance or improve
39
the bug description or status. Other people will see the bugs: it's
40
better to have 20 of them processed and later change the status of a
41
couple than to leave them lie.
43
When you file a bug as a Bazaar developer or active user, if you feel
44
confident in doing so, make an assessment of status and importance at the
45
time you file it, rather than leaving it for someone else. It's more
46
efficient to change the importance if someone else feel's it's higher or
47
lower, than to have someone else edit all bugs.
49
It's more useful to actually ship bug fixes than to garden the bug
50
database. It's more useful to take one bug through to a shipped fix than
51
to partially investigate ten bugs. You don't get credit for a bug until
52
the fix is shipped in a release. Users like getting a response to their
53
report, but they generally care more about getting bugs fixed.
55
The aim of investigating bugs before starting concentrated work on them is
58
* determine if they are critical or high priority (and
59
should displace existing work)
61
* garden sufficiently to keep the database usable: meaningful summaries,
62
and duplicates removed
64
It's OK to fix some bugs that just annoy you, even if they're not
67
You can use ``--fixes lp:12345678`` when committing to associate the
68
commit with a particular bug.
70
If there are multiple bugs with related fixes, putting "[master]" in the
71
title of one of them helps find it
73
It's often fastest to find bugs just using the regular Google search
74
engine, rather than Launchpad's search.
78
| One of the things you should not do often is to start asking
79
| questions/for more debug info and then forget about the bug. It's just
80
| a waste of the reporter's and your time, and will create frustration
81
| on the reporter side.
87
The suggested priorities for bug work are:
91
2. Get existing fixes through review and landed.
93
3. Fix bugs that are already in progress.
95
4. Look at bugs already assigned to you, and either start them, or change
96
your mind and unassign them.
98
5. Take new bugs from the top of the stack.
102
It's not strict and of course there is personal discretion but our work
103
should be biased to the top of this hierarchy.
109
Bugs should have clear edges, so that you can make a clear statement about
110
whether a bug is fixed or not. (Sometimes reality is complicated, but aim
111
for each bug to be clear.)
113
Bugs on documentation, performance, or UI are fine as long as they're
116
Examples of good bugs:
118
* "ValueError in frob_foo when committing changed symlink" - although
119
there may be many possible things that could cause a ValueError there,
120
you should at least know when you've fixed the problem described in this
123
* "Unclear message about incompatible repositories" - even though the user
124
may not agree the new message is sufficiently clear, at least you know
125
when you've tried to fix it.
127
Examples of bad bugs:
129
* "Commit is too slow" - how fast is fast enough to close it? "Commit
130
reads the working tree twice" is clearer.
137
The bug has just been filed and hasn't been examined by a developer
140
The bug requires more information from the reporter to make progress.
142
Only set this state if it's impossible or uneconomical to make
143
progress on the bug without that information. The bug will expire if
144
it remains in this state for two months.
146
The bug report has been seen by a developer and we agree it's a bug.
147
You don't have to reproduce the bug to mark it Confirmed. (Generally
148
it's not a good idea for a developer to spend time reproducing the bug
149
until they're going to work on it.)
151
We don't use this status. If it is set, it means the same as
154
Someone has started working on this. We can deliver the value of the
155
work already done by finishing and shipping the fix.
157
The bug keeps this state from the time someone does non-trivial
158
analysis, until the fix is merged to a release or trunk branch (when
159
it is Fix Released), or until they give up on it (back to New or
160
Confirmed) or decide it is Invalid or Incomplete.
162
The behaviour complained about is intentional and we won't fix it.
163
Needless to say, be thoughtful before using this status, and consider if
164
the user experience can be improved in some other way.
166
The reporter was confused, and this is not actually a bug.
167
Again, be sensitive in explaining this to the user.
169
Don't use this. If set on old bug, it probably means In Progress,
170
with the fix waiting for review. See Launchpad `bug 163694`_.
172
The fix for this bug is now in the bzr branch that this task is for.
173
The branch for the default task on a bug is bzr.dev.
175
We use this value even though the fix may not have been been included
176
in a release yet because all the developer activity around it is
177
complete and we want to both avoid bug spam when releases happen, and
178
keep the list of bugs that developers see when they look at the bug
179
tracker trimmed to those that require action.
181
When setting a bug task to fix released, the bug target milestone
182
should be set to the release the fix will be included in (or was
183
included in, if you are updating an old bug). Don't spend too much
184
time updating this if you don't immediately know: its not critical
187
.. _`bug 163694`: https://bugs.launchpad.net/malone/+bug/163694
194
This is a serious bug that could cause data loss, stop bzr being
195
usable in an important case, or represents a regression in something
196
previously working. We should fix critical bugs before doing other
197
work, or seriously consider whether the bug is really critical
198
or whether the other change is more urgent.
200
This is a bug that can seriously interfere with people's use of
201
Bazaar. We should seriously consider fixing these bugs before
202
working on new features.
204
A regular bug. We'd like to fix them, but there may be a long delay.
206
Something suboptimal that may affect an unimportant case or have a
207
fairly easy workaround.
209
These will basically never get done.
211
Bugs rated Medium or lower are unlikely to get fixed unless they either
212
pique the interest of a developer or are escalated due eg to many users
215
Not every existing bug is correctly rated according to this scale, and we
216
don't always follow this process, but we'd like to do it more. But
217
remember, fixing bugs is more helpful than gardening them.
223
Assigning a bug to yourself, or someone else, indicates a real intention
224
to work on that bug soon.
230
It's possible to target a bug to a milestone, eg
231
<https://bugs.launchpad.net/bzr/+milestone/1.16>. We use this to help the
232
release manager know what **must** be merged to make the release.
234
Therefore, we don't target bugs that we'd like to have fixed or that could
235
be fixed in a particular release, we only target bugs that must be fixed
236
and that will cause us to slip the release if they're not fixed. At any time,
237
very few if any of the bugs targeted to a release should be still open. By
238
definition, these bugs should normally be Critical priority.
244
Sometimes we'll want to make a special point-release update (eg 1.15.1)
245
off an already-released branch including a fix for a particular bug. To
246
represent this, create a new bug task (ie link in the status table on the
247
bug page) by clicking the `poorly-named
248
<https://bugs.launchpad.net/bugs/132733>`_ "Target to Release" link.
249
Target it to the appropriate series (ie 1.15). If the bug should also
250
prevent any point releases of that series then you should also target the
251
new task to the appropriate milestone within that release. (See Targeting Bugs
254
This bug task then has a separate status and importance to indicate the
255
separate work to get it into that release.
261
Most bugs that are fixed should be mentioned in a `NEWS
262
<../en/release-notes/NEWS.html>`_ file entry,
263
including the bug number.
264
(Exceptions might be bugs that are not at all user visible.)
270
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.
274
authenticating to servers
277
candidate for backporting to an update of the previous release
283
should be possible to finish in an hour or two
286
bugs about the High-Performance Smart Server, i.e. bzr+ssh://, etc.
289
bugs for causes of VFS methods of the smart server
292
bugs about interactions with launchpad (typically this means bzrlib.plugins.launchpad).
295
problems using locales other than English
298
problems where we use too much memory for some reason
301
fixing this would need a new disk format
304
bugs about performance problems.
307
bugs which represent an aspect of bzr becoming accidentally less good than it was.
310
needs changes to the test framework
313
virtual filesystem for HTTP, SFTP, etc.
316
should be very easy to fix (10-20 minutes) and easily landed: typically
317
just spelling errors and the like
320
bugs relating to the bzr user interface, e.g. confusing error messages.
323
bugs that mainly affects Windows. Also there is cygwin and win98 tags for
324
marking specific bugs.
326
You can see the full list of tags in use at
327
<https://bugs.launchpad.net/bzr/+bugs>. As of September 2008 the
328
list is on the right.