/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: John Arbash Meinel
  • Date: 2009-12-10 17:16:19 UTC
  • mfrom: (4884 +trunk)
  • mto: This revision was merged to the branch mainline in revision 4889.
  • Revision ID: john@arbash-meinel.com-20091210171619-ehdcxjbl8afhq9g1
Bring in bzr.dev 4884

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.)
144
144
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".
 
145
    We don't use this status.  If it is set, it means the same as
 
146
    Confirmed.
151
147
In Progress
152
148
    Someone has started working on this.
153
149
Won't Fix
161
157
    A fix for this bug exists in a branch somewhere.  Ideally the bug will
162
158
    be linked to the branch.
163
159
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.
 
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.
168
171
 
169
172
 
170
173
Bug Importance
208
211
***************
209
212
 
210
213
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.
 
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.
214
216
 
215
217
Therefore, we don't target bugs that we'd like to have fixed or that could
216
218
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.
 
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.
221
222
 
222
223
 
223
224
Backports
228
229
represent this, create a new bug task (ie link in the status table on the
229
230
bug page) by clicking the `poorly-named
230
231
<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.  
 
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)
233
236
 
234
237
This bug task then has a separate status and importance to indicate the
235
238
separate work to get it into that release.
253
256
authentication
254
257
    authenticating to servers
255
258
 
256
 
backport 
 
259
backport
257
260
    candidate for backporting to an update of the previous release
258
261
 
259
 
dirstate 
 
262
dirstate
260
263
    WorkingTree4
261
264
 
262
 
easy 
 
265
easy
263
266
    should be possible to finish in an hour or two
264
267
 
265
 
hpss 
 
268
hpss
266
269
    bugs about the High-Performance Smart Server, i.e. bzr+ssh://, etc.
267
270
 
268
 
hpssvfs 
 
271
hpssvfs
269
272
    bugs for causes of VFS methods of the smart server
270
273
 
271
 
launchpad 
 
274
launchpad
272
275
    bugs about interactions with launchpad (typically this means bzrlib.plugins.launchpad).
273
276
 
274
 
locale 
 
277
locale
275
278
    problems using locales other than English
276
279
 
277
 
memory 
 
280
memory
278
281
    problems where we use too much memory for some reason
279
282
 
280
 
newformat 
 
283
newformat
281
284
    fixing this would need a new disk format
282
285
 
283
 
performance 
 
286
performance
284
287
    bugs about performance problems.
285
288
 
286
 
test 
 
289
test
287
290
    needs changes to the test framework
288
291
 
289
 
transport 
 
292
transport
290
293
    virtual filesystem for http, sftp, etc
291
294
 
292
 
trivial 
 
295
trivial
293
296
    should be very easy to fix (10-20 minutes) and easily landed: typically just spelling errors and the like
294
297
 
295
 
ui 
 
298
ui
296
299
    bugs relating to the bzr user interface, e.g. confusing error messages.
297
300
 
298
 
win32 
299
 
    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.
300
303
 
301
304
You can see the full list of tags in use at
302
305
<https://bugs.edge.launchpad.net/bzr/+bugs>.  As of September 2008 the
303
 
list is on the right. 
 
306
list is on the right.
304
307
 
305
308
.. vim: ft=rst