~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

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

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2009-11-17 03:20:35 UTC
  • mfrom: (4792.4.3 456036)
  • Revision ID: pqm@pqm.ubuntu.com-20091117032035-s3sgtlixj1lrminn
(Gordon Tyler) Fix IndexError during 'bzr ignore /' (#456036)

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.
143
139
Confirmed
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
 
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
146
142
    it's not a good idea for a developer to spend time reproducing the bug
147
143
    until they're going to work on it.)
148
144
Triaged
149
145
    We don't use this status.  If it is set, it means the same as
150
146
    Confirmed.
151
147
In Progress
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.
 
148
    Someone has started working on this.
159
149
Won't Fix
160
150
    The behaviour complained about is intentional and we won't fix it.
161
151
    Needless to say, be thoughtful before using this status, and consider if
164
154
    The reporter was confused, and this is not actually a bug.
165
155
    Again, be sensitive in explaining this to the user.
166
156
Fix Committed
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`_.
 
157
    A fix for this bug exists in a branch somewhere.  Ideally the bug will
 
158
    be linked to the branch.
169
159
Fix Released
170
160
    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.  
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
 
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.
186
171
 
187
172
 
188
173
Bug Importance
271
256
authentication
272
257
    authenticating to servers
273
258
 
274
 
backport
 
259
backport 
275
260
    candidate for backporting to an update of the previous release
276
261
 
277
 
dirstate
 
262
dirstate 
278
263
    WorkingTree4
279
264
 
280
 
easy
 
265
easy 
281
266
    should be possible to finish in an hour or two
282
267
 
283
 
hpss
 
268
hpss 
284
269
    bugs about the High-Performance Smart Server, i.e. bzr+ssh://, etc.
285
270
 
286
 
hpssvfs
 
271
hpssvfs 
287
272
    bugs for causes of VFS methods of the smart server
288
273
 
289
 
launchpad
 
274
launchpad 
290
275
    bugs about interactions with launchpad (typically this means bzrlib.plugins.launchpad).
291
276
 
292
 
locale
 
277
locale 
293
278
    problems using locales other than English
294
279
 
295
 
memory
 
280
memory 
296
281
    problems where we use too much memory for some reason
297
282
 
298
 
newformat
 
283
newformat 
299
284
    fixing this would need a new disk format
300
285
 
301
 
performance
 
286
performance 
302
287
    bugs about performance problems.
303
288
 
304
 
test
 
289
test 
305
290
    needs changes to the test framework
306
291
 
307
 
transport
 
292
transport 
308
293
    virtual filesystem for http, sftp, etc
309
294
 
310
 
trivial
 
295
trivial 
311
296
    should be very easy to fix (10-20 minutes) and easily landed: typically just spelling errors and the like
312
297
 
313
 
ui
 
298
ui 
314
299
    bugs relating to the bzr user interface, e.g. confusing error messages.
315
300
 
316
 
win32
317
 
    bugs that mainly affects Windows. Also there is cygwin and win98 tags for marking specific bugs.
 
301
win32 
 
302
    bugs that mainly affects Windows. Also there is cygwin and win98 tags for marking specific bugs. 
318
303
 
319
304
You can see the full list of tags in use at
320
305
<https://bugs.edge.launchpad.net/bzr/+bugs>.  As of September 2008 the
321
 
list is on the right.
 
306
list is on the right. 
322
307
 
323
308
.. vim: ft=rst