/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

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

  • Committer: Jonathan Lange
  • Date: 2009-12-09 09:20:42 UTC
  • mfrom: (4881 +trunk)
  • mto: This revision was merged to the branch mainline in revision 4907.
  • Revision ID: jml@canonical.com-20091209092042-s2zgqcf8f39yzxpj
Merge trunk.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/bug-handling.txt
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.
137
137
Incomplete
138
138
    The bug requires more information from the reporter to make progress.
139
139
Confirmed
140
 
    The bug report has been seen by a developer and we agree it's a bug.  
 
140
    The bug report has been seen by a developer and we agree it's a bug.
141
141
    You don't have to reproduce the bug to mark it confirmed.  (Generally
142
142
    it's not a good idea for a developer to spend time reproducing the bug
143
143
    until they're going to work on it.)
157
157
    A fix for this bug exists in a branch somewhere.  Ideally the bug will
158
158
    be linked to the branch.
159
159
Fix Released
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.
 
160
    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.
164
171
 
165
172
 
166
173
Bug Importance
204
211
***************
205
212
 
206
213
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
209
 
release.
 
214
<https://bugs.edge.launchpad.net/bzr/+milestone/1.16>.  We use this to help the
 
215
release manager know what **must** be merged to make the release.
210
216
 
211
217
Therefore, we don't target bugs that we'd like to have fixed or that could
212
218
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.
 
219
and that will cause us to slip the release if they're not fixed.  At any time,
 
220
very few if any of the bugs targeted to a release should be still open.  By
 
221
definition, these bugs should normally be Critical priority.
217
222
 
218
223
 
219
224
Backports
224
229
represent this, create a new bug task (ie link in the status table on the
225
230
bug page) by clicking the `poorly-named
226
231
<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
228
 
within that release.  
 
232
Target it to the appropriate series (ie 1.15). If the bug should also
 
233
prevent any point releases of that series then you should also target the
 
234
new task to the appropriate milestone within that release. (See Targeting Bugs
 
235
above)
229
236
 
230
237
This bug task then has a separate status and importance to indicate the
231
238
separate work to get it into that release.
249
256
authentication
250
257
    authenticating to servers
251
258
 
252
 
backport 
 
259
backport
253
260
    candidate for backporting to an update of the previous release
254
261
 
255
 
dirstate 
 
262
dirstate
256
263
    WorkingTree4
257
264
 
258
 
easy 
 
265
easy
259
266
    should be possible to finish in an hour or two
260
267
 
261
 
hpss 
 
268
hpss
262
269
    bugs about the High-Performance Smart Server, i.e. bzr+ssh://, etc.
263
270
 
264
 
launchpad 
 
271
hpssvfs
 
272
    bugs for causes of VFS methods of the smart server
 
273
 
 
274
launchpad
265
275
    bugs about interactions with launchpad (typically this means bzrlib.plugins.launchpad).
266
276
 
267
 
locale 
 
277
locale
268
278
    problems using locales other than English
269
279
 
270
 
memory 
 
280
memory
271
281
    problems where we use too much memory for some reason
272
282
 
273
 
newformat 
 
283
newformat
274
284
    fixing this would need a new disk format
275
285
 
276
 
performance 
 
286
performance
277
287
    bugs about performance problems.
278
288
 
279
 
test 
 
289
test
280
290
    needs changes to the test framework
281
291
 
282
 
transport 
 
292
transport
283
293
    virtual filesystem for http, sftp, etc
284
294
 
285
 
trivial 
 
295
trivial
286
296
    should be very easy to fix (10-20 minutes) and easily landed: typically just spelling errors and the like
287
297
 
288
 
ui 
 
298
ui
289
299
    bugs relating to the bzr user interface, e.g. confusing error messages.
290
300
 
291
 
win32 
292
 
    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.
293
303
 
294
304
You can see the full list of tags in use at
295
305
<https://bugs.edge.launchpad.net/bzr/+bugs>.  As of September 2008 the
296
 
list is on the right. 
 
306
list is on the right.
297
307
 
298
308
.. vim: ft=rst