~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/bug-handling.txt

  • Committer: John Arbash Meinel
  • Date: 2010-02-17 17:11:16 UTC
  • mfrom: (4797.2.17 2.1)
  • mto: (4797.2.18 2.1)
  • mto: This revision was merged to the branch mainline in revision 5055.
  • Revision ID: john@arbash-meinel.com-20100217171116-h7t9223ystbnx5h8
merge bzr.2.1 in preparation for NEWS entry.

Show diffs side-by-side

added added

removed removed

Lines of Context:
51
51
report, but they generally care more about getting bugs fixed.
52
52
 
53
53
The aim of investigating bugs before starting concentrated work on them is
54
 
therefore only to: 
 
54
therefore only to:
55
55
 
56
56
* determine if they are critical or high priority (and
57
57
  should displace existing work)
76
76
 | One of the things you should not do often is to start asking
77
77
 | questions/for more debug info and then forget about the bug. It's just
78
78
 | a waste of the reporter's and your time, and will create frustration
79
 
 | on the reporter side. 
 
79
 | on the reporter side.
80
80
 
81
81
 
82
82
Priorities
85
85
The suggested priorities for bug work are:
86
86
 
87
87
1. Fix critical bugs.
88
 
   
 
88
 
89
89
2. Get existing fixes through review and landed.
90
90
 
91
91
3. Fix bugs that are already in progress.
136
136
    yet.
137
137
Incomplete
138
138
    The bug requires more information from the reporter to make progress.
 
139
 
 
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.
139
143
Confirmed
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.)
144
148
Triaged
145
149
    We don't use this status.  If it is set, it means the same as
146
150
    Confirmed.
147
151
In Progress
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.  
 
154
    
 
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.
149
159
Won't Fix
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.
156
166
Fix Committed
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`_.
159
169
Fix Released
160
170
    The fix for this bug is now in the bzr branch that this task is for.
161
 
    The branch for the default task on a bug is bzr.dev.  We use this value
162
 
    even though the fix may not have been been included in a release yet
163
 
    because all the developer activity around it is complete and we want to
164
 
    both avoid bug spam when releases happen, and keep the list of bugs that
165
 
    developers see when they look at the bug tracker trimmed to those that
166
 
    require action. When setting a bug task to fix released, the bug target
167
 
    milestone should be set to the release the fix will be included in (or
168
 
    was included in, if you are updating an old bug). Don't spend too much time
169
 
    updating this if you don't immediately know: its not critical that it be
170
 
    set.
 
171
    The branch for the default task on a bug is bzr.dev.  
 
172
    
 
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. 
 
178
    
 
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
 
183
    that it be set.
 
184
 
 
185
.. _`bug 163694`: https://bugs.launchpad.net/malone/+bug/163694
171
186
 
172
187
 
173
188
Bug Importance
256
271
authentication
257
272
    authenticating to servers
258
273
 
259
 
backport 
 
274
backport
260
275
    candidate for backporting to an update of the previous release
261
276
 
262
 
dirstate 
 
277
dirstate
263
278
    WorkingTree4
264
279
 
265
 
easy 
 
280
easy
266
281
    should be possible to finish in an hour or two
267
282
 
268
 
hpss 
 
283
hpss
269
284
    bugs about the High-Performance Smart Server, i.e. bzr+ssh://, etc.
270
285
 
271
 
hpssvfs 
 
286
hpssvfs
272
287
    bugs for causes of VFS methods of the smart server
273
288
 
274
 
launchpad 
 
289
launchpad
275
290
    bugs about interactions with launchpad (typically this means bzrlib.plugins.launchpad).
276
291
 
277
 
locale 
 
292
locale
278
293
    problems using locales other than English
279
294
 
280
 
memory 
 
295
memory
281
296
    problems where we use too much memory for some reason
282
297
 
283
 
newformat 
 
298
newformat
284
299
    fixing this would need a new disk format
285
300
 
286
 
performance 
 
301
performance
287
302
    bugs about performance problems.
288
303
 
289
 
test 
 
304
test
290
305
    needs changes to the test framework
291
306
 
292
 
transport 
 
307
transport
293
308
    virtual filesystem for http, sftp, etc
294
309
 
295
 
trivial 
 
310
trivial
296
311
    should be very easy to fix (10-20 minutes) and easily landed: typically just spelling errors and the like
297
312
 
298
 
ui 
 
313
ui
299
314
    bugs relating to the bzr user interface, e.g. confusing error messages.
300
315
 
301
 
win32 
302
 
    bugs that mainly affects Windows. Also there is cygwin and win98 tags for marking specific bugs. 
 
316
win32
 
317
    bugs that mainly affects Windows. Also there is cygwin and win98 tags for marking specific bugs.
303
318
 
304
319
You can see the full list of tags in use at
305
320
<https://bugs.edge.launchpad.net/bzr/+bugs>.  As of September 2008 the
306
 
list is on the right. 
 
321
list is on the right.
307
322
 
308
323
.. vim: ft=rst