~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: 2010-03-02 08:49:07 UTC
  • mfrom: (5067.1.1 integration)
  • Revision ID: pqm@pqm.ubuntu.com-20100302084907-z4r0yoa4ldspjz82
(vila) Resolve --take-this or --take-other correctly rename kept file

Show diffs side-by-side

added added

removed removed

Lines of Context:
28
28
* `Open bugs most recently changed first
29
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=>`_.
30
30
 
 
31
* `Most commonly duplicated bugs <http://tinyurl.com/bzr-bugs-by-dupes>`_.
 
32
 
31
33
 
32
34
Generalities
33
35
************
51
53
report, but they generally care more about getting bugs fixed.
52
54
 
53
55
The aim of investigating bugs before starting concentrated work on them is
54
 
therefore only to: 
 
56
therefore only to:
55
57
 
56
58
* determine if they are critical or high priority (and
57
59
  should displace existing work)
76
78
 | One of the things you should not do often is to start asking
77
79
 | questions/for more debug info and then forget about the bug. It's just
78
80
 | a waste of the reporter's and your time, and will create frustration
79
 
 | on the reporter side. 
 
81
 | on the reporter side.
80
82
 
81
83
 
82
84
Priorities
85
87
The suggested priorities for bug work are:
86
88
 
87
89
1. Fix critical bugs.
88
 
   
 
90
 
89
91
2. Get existing fixes through review and landed.
90
92
 
91
93
3. Fix bugs that are already in progress.
136
138
    yet.
137
139
Incomplete
138
140
    The bug requires more information from the reporter to make progress.
 
141
 
 
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.
139
145
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
 
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
142
148
    it's not a good idea for a developer to spend time reproducing the bug
143
149
    until they're going to work on it.)
144
150
Triaged
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".
 
151
    We don't use this status.  If it is set, it means the same as
 
152
    Confirmed.
151
153
In Progress
152
 
    Someone has started working on this.
 
154
    Someone has started working on this.  We can deliver the value of the
 
155
    work already done by finishing and shipping the fix.  
 
156
    
 
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.
153
161
Won't Fix
154
162
    The behaviour complained about is intentional and we won't fix it.
155
163
    Needless to say, be thoughtful before using this status, and consider if
158
166
    The reporter was confused, and this is not actually a bug.
159
167
    Again, be sensitive in explaining this to the user.
160
168
Fix Committed
161
 
    A fix for this bug exists in a branch somewhere.  Ideally the bug will
162
 
    be linked to the branch.
 
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`_.
163
171
Fix Released
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.
 
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.  
 
174
    
 
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. 
 
180
    
 
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
 
185
    that it be set.
 
186
 
 
187
.. _`bug 163694`: https://bugs.launchpad.net/malone/+bug/163694
168
188
 
169
189
 
170
190
Bug Importance
208
228
***************
209
229
 
210
230
It's possible to target a bug to a milestone, eg
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
213
 
release.
 
231
<https://bugs.edge.launchpad.net/bzr/+milestone/1.16>.  We use this to help the
 
232
release manager know what **must** be merged to make the release.
214
233
 
215
234
Therefore, we don't target bugs that we'd like to have fixed or that could
216
235
be fixed in a particular release, we only target bugs that must be fixed
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.
 
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.
221
239
 
222
240
 
223
241
Backports
228
246
represent this, create a new bug task (ie link in the status table on the
229
247
bug page) by clicking the `poorly-named
230
248
<https://bugs.launchpad.net/bugs/132733>`_ "Target to Release" link.
231
 
Target it to the appropriate series (ie 1.15) and then to the milestone
232
 
within that release.  
 
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
 
252
above)
233
253
 
234
254
This bug task then has a separate status and importance to indicate the
235
255
separate work to get it into that release.
253
273
authentication
254
274
    authenticating to servers
255
275
 
256
 
backport 
 
276
backport
257
277
    candidate for backporting to an update of the previous release
258
278
 
259
 
dirstate 
 
279
dirstate
260
280
    WorkingTree4
261
281
 
262
 
easy 
 
282
easy
263
283
    should be possible to finish in an hour or two
264
284
 
265
 
hpss 
 
285
hpss
266
286
    bugs about the High-Performance Smart Server, i.e. bzr+ssh://, etc.
267
287
 
268
 
hpssvfs 
 
288
hpssvfs
269
289
    bugs for causes of VFS methods of the smart server
270
290
 
271
 
launchpad 
 
291
launchpad
272
292
    bugs about interactions with launchpad (typically this means bzrlib.plugins.launchpad).
273
293
 
274
 
locale 
 
294
locale
275
295
    problems using locales other than English
276
296
 
277
 
memory 
 
297
memory
278
298
    problems where we use too much memory for some reason
279
299
 
280
 
newformat 
 
300
newformat
281
301
    fixing this would need a new disk format
282
302
 
283
 
performance 
 
303
performance
284
304
    bugs about performance problems.
285
305
 
286
 
test 
 
306
test
287
307
    needs changes to the test framework
288
308
 
289
 
transport 
 
309
transport
290
310
    virtual filesystem for http, sftp, etc
291
311
 
292
 
trivial 
 
312
trivial
293
313
    should be very easy to fix (10-20 minutes) and easily landed: typically just spelling errors and the like
294
314
 
295
 
ui 
 
315
ui
296
316
    bugs relating to the bzr user interface, e.g. confusing error messages.
297
317
 
298
 
win32 
299
 
    bugs that mainly affects Windows. Also there is cygwin and win98 tags for marking specific bugs. 
 
318
win32
 
319
    bugs that mainly affects Windows. Also there is cygwin and win98 tags for marking specific bugs.
300
320
 
301
321
You can see the full list of tags in use at
302
322
<https://bugs.edge.launchpad.net/bzr/+bugs>.  As of September 2008 the
303
 
list is on the right. 
 
323
list is on the right.
304
324
 
305
325
.. vim: ft=rst