51
51
report, but they generally care more about getting bugs fixed.
53
53
The aim of investigating bugs before starting concentrated work on them is
56
56
* determine if they are critical or high priority (and
57
57
should displace existing work)
138
138
The bug requires more information from the reporter to make progress.
140
Only set this state if it's impossible or uneconomical to make
141
progress on the bug without that information. The bug will expire if
142
it remains in this state for two months.
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
144
The bug report has been seen by a developer and we agree it's a bug.
145
You don't have to reproduce the bug to mark it Confirmed. (Generally
142
146
it's not a good idea for a developer to spend time reproducing the bug
143
147
until they're going to work on it.)
145
149
We don't use this status. If it is set, it means the same as
148
Someone has started working on this.
152
Someone has started working on this. We can deliver the value of the
153
work already done by finishing and shipping the fix.
155
The bug keeps this state from the time someone does non-trivial
156
analysis, until the fix is merged to a release or trunk branch (when
157
it is Fix Released), or until they give up on it (back to New or
158
Confirmed) or decide it is Invalid or Incomplete.
150
160
The behaviour complained about is intentional and we won't fix it.
151
161
Needless to say, be thoughtful before using this status, and consider if
154
164
The reporter was confused, and this is not actually a bug.
155
165
Again, be sensitive in explaining this to the user.
157
A fix for this bug exists in a branch somewhere. Ideally the bug will
158
be linked to the branch.
167
Don't use this. If set on old bug, it probably means In Progress,
168
with the fix waiting for review. See Launchpad `bug 163694`_.
160
The fix for this bug is now in the bzr trunk. It's not necessarily
161
true that it's released yet, but it will be in the next release. The
162
bug target milestone should be set to the release it went into, but
163
don't spend too much time updating this if you don't immediately know.
170
The fix for this bug is now in the bzr branch that this task is for.
171
The branch for the default task on a bug is bzr.dev.
173
We use this value even though the fix may not have been been included
174
in a release yet because all the developer activity around it is
175
complete and we want to both avoid bug spam when releases happen, and
176
keep the list of bugs that developers see when they look at the bug
177
tracker trimmed to those that require action.
179
When setting a bug task to fix released, the bug target milestone
180
should be set to the release the fix will be included in (or was
181
included in, if you are updating an old bug). Don't spend too much
182
time updating this if you don't immediately know: its not critical
185
.. _`bug 163694`: https://bugs.launchpad.net/malone/+bug/163694
206
228
It's possible to target a bug to a milestone, eg
207
<https://bugs.edge.launchpad.net/bzr/+milestone/1.16>. We use this mostly
208
to help the release manager know what **must** be merged to make the
229
<https://bugs.edge.launchpad.net/bzr/+milestone/1.16>. We use this to help the
230
release manager know what **must** be merged to make the release.
211
232
Therefore, we don't target bugs that we'd like to have fixed or that could
212
233
be fixed in a particular release, we only target bugs that must be fixed
213
and that will or might cause us to decide to slip the release if they're
214
not fixed. At any time, very few if any of the bugs targetted to a
215
release should be still open. By definition, these bugs should normally
216
be Critical priority.
234
and that will cause us to slip the release if they're not fixed. At any time,
235
very few if any of the bugs targeted to a release should be still open. By
236
definition, these bugs should normally be Critical priority.
224
244
represent this, create a new bug task (ie link in the status table on the
225
245
bug page) by clicking the `poorly-named
226
246
<https://bugs.launchpad.net/bugs/132733>`_ "Target to Release" link.
227
Target it to the appropriate series (ie 1.15) and then to the milestone
247
Target it to the appropriate series (ie 1.15). If the bug should also
248
prevent any point releases of that series then you should also target the
249
new task to the appropriate milestone within that release. (See Targeting Bugs
230
252
This bug task then has a separate status and importance to indicate the
231
253
separate work to get it into that release.
250
272
authenticating to servers
253
275
candidate for backporting to an update of the previous release
259
281
should be possible to finish in an hour or two
262
284
bugs about the High-Performance Smart Server, i.e. bzr+ssh://, etc.
265
287
bugs for causes of VFS methods of the smart server
268
290
bugs about interactions with launchpad (typically this means bzrlib.plugins.launchpad).
271
293
problems using locales other than English
274
296
problems where we use too much memory for some reason
277
299
fixing this would need a new disk format
280
302
bugs about performance problems.
283
305
needs changes to the test framework
286
308
virtual filesystem for http, sftp, etc
289
311
should be very easy to fix (10-20 minutes) and easily landed: typically just spelling errors and the like
292
314
bugs relating to the bzr user interface, e.g. confusing error messages.
295
bugs that mainly affects Windows. Also there is cygwin and win98 tags for marking specific bugs.
317
bugs that mainly affects Windows. Also there is cygwin and win98 tags for marking specific bugs.
297
319
You can see the full list of tags in use at
298
320
<https://bugs.edge.launchpad.net/bzr/+bugs>. As of September 2008 the
299
list is on the right.
321
list is on the right.
added
removed
doc/developers/bug-handling.txt
