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>`_.
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
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>`_.
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=>`_.
43
41
When you file a bug as a Bazaar developer or active user, if you feel
44
42
confident in doing so, make an assessment of status and importance at the
45
43
time you file it, rather than leaving it for someone else. It's more
46
efficient to change the importance if someone else feels it's higher or
44
efficient to change the importance if someone else feel's it's higher or
47
45
lower, than to have someone else edit all bugs.
49
47
It's more useful to actually ship bug fixes than to garden the bug
53
51
report, but they generally care more about getting bugs fixed.
55
53
The aim of investigating bugs before starting concentrated work on them is
58
56
* determine if they are critical or high priority (and
59
57
should displace existing work)
140
138
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
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
148
142
it's not a good idea for a developer to spend time reproducing the bug
149
143
until they're going to work on it.)
151
We don't use this status. If it is set, it means the same as
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".
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.
152
Someone has started working on this.
162
154
The behaviour complained about is intentional and we won't fix it.
163
155
Needless to say, be thoughtful before using this status, and consider if
166
158
The reporter was confused, and this is not actually a bug.
167
159
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`_.
161
A fix for this bug exists in a branch somewhere. Ideally the bug will
162
be linked to the branch.
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/launchpad/+bug/163694
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.
230
210
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.
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
234
215
Therefore, we don't target bugs that we'd like to have fixed or that could
235
216
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.
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.
246
228
represent this, create a new bug task (ie link in the status table on the
247
229
bug page) by clicking the `poorly-named
248
230
<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
231
Target it to the appropriate series (ie 1.15) and then to the milestone
254
234
This bug task then has a separate status and importance to indicate the
255
235
separate work to get it into that release.
261
Most bugs that are fixed should be mentioned in the `Release Notes
262
<../en/release-notes/>`_ for the forthcoming version,
241
Most bugs that are fixed should be mentioned in a `NEWS
242
<../en/release-notes/NEWS.html>`_ file entry,
263
243
including the bug number.
264
244
(Exceptions might be bugs that are not at all user visible.)
270
Here are some bug tags we use. In Launchpad Bugs tags are currently of limited use, so don't feel obliged to tag bugs unless you're finding it useful.
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.
274
254
authenticating to servers
277
257
candidate for backporting to an update of the previous release
283
263
should be possible to finish in an hour or two
286
266
bugs about the High-Performance Smart Server, i.e. bzr+ssh://, etc.
289
269
bugs for causes of VFS methods of the smart server
292
272
bugs about interactions with launchpad (typically this means bzrlib.plugins.launchpad).
295
275
problems using locales other than English
298
278
problems where we use too much memory for some reason
301
281
fixing this would need a new disk format
304
284
bugs about performance problems.
307
bugs which represent an aspect of bzr becoming accidentally less good than it was.
310
287
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
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
320
296
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.
299
bugs that mainly affects Windows. Also there is cygwin and win98 tags for marking specific bugs.
326
301
You can see the full list of tags in use at
327
<https://bugs.launchpad.net/bzr/+bugs>. As of September 2008 the
302
<https://bugs.edge.launchpad.net/bzr/+bugs>. As of September 2008 the
328
303
list is on the right.
added
removed
doc/developers/bug-handling.txt
