← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

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

  • Committer: Vincent Ladeuil
  • Date: 2009-07-07 08:24:57 UTC
  • mto: (4516.1.1 integration)
  • mto: This revision was merged to the branch mainline in revision 4519.
  • Revision ID: v.ladeuil+lp@free.fr-20090707082457-otq7zht7lgkpnpbr
Fix bug #383920 by inserting the missing Content-Length header.

* bzrlib/tests/test_transport_implementations.py:
(TransportTests.test_get_unknown_file,
TransportTests.test_get_bytes_unknown_file): Localize bug #383920.

* bzrlib/tests/test_read_bundle.py:
(TestReadBundleFromURL.setUp,
TestReadBundleFromURL.read_mergeable_from_url): Fix regression
caused by pqm not running pycurl + python2.6, which means that the
https test server is not tested there and couldn't catch it. Clean
up the tests too.

* bzrlib/tests/http_server.py:
(TestingHTTPRequestHandler.send_error): Send the Content-Length
header or pycurl can't handle the 404...

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/bug-handling.txt
 
1
***********************
 
2
Tracking Bugs in Bazaar
 
3
***********************
 
4
 
 
5
This document describes the bug-tracking processes for developing Bazaar
 
6
itself.  Bugs in Bazaar are recorded in Launchpad.
 
7
 
 
8
 
 
9
See also:
 
10
 
 
11
* `Bazaar Developer Documents <index.html>`_.
 
12
 
 
13
* `The Bazaar Development Cycle <cycle.html>`_.
 
14
 
 
15
* `The Bazaar User Guide <../en/user-guide/index.html>`_ -- for
 
16
  information on integrating Bazaar with other bug trackers.
 
17
 
 
18
 
 
19
Links
 
20
*****
 
21
 
 
22
* `bzr bugs home page <https://bugs.edge.launchpad.net/bzr>`_.
 
23
 
 
24
* `Critical bugs <https://bugs.edge.launchpad.net/bzr/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed>`_.
 
25
 
 
26
* `Open bugs by importance <https://bugs.edge.launchpad.net/bzr/+bugs>`_.
 
27
 
 
28
* `Open bugs most recently changed first
 
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
 
 
31
 
 
32
Generalities
 
33
************
 
34
 
 
35
Anyone involved with Bazaar is welcome to contribute to managing our bug
 
36
reports.  **Edit boldly**: try to help users out, assess importance or improve
 
37
the bug description or status.  Other people will see the bugs: it's
 
38
better to have 20 of them processed and later change the status of a
 
39
couple than to leave them lie.
 
40
 
 
41
When you file a bug as a Bazaar developer or active user, if you feel
 
42
confident in doing so, make an assessment of status and importance at the
 
43
time you file it, rather than leaving it for someone else.  It's more
 
44
efficient to change the importance if someone else feel's it's higher or
 
45
lower, than to have someone else edit all bugs.
 
46
 
 
47
It's more useful to actually ship bug fixes than to garden the bug
 
48
database.  It's more useful to take one bug through to a shipped fix than
 
49
to partially investigate ten bugs.  You don't get credit for a bug until
 
50
the fix is shipped in a release.  Users like getting a response to their
 
51
report, but they generally care more about getting bugs fixed.
 
52
 
 
53
The aim of investigating bugs before starting concentrated work on them is
 
54
therefore only to: 
 
55
 
 
56
* determine if they are critical or high priority (and
 
57
  should displace existing work)
 
58
 
 
59
* garden sufficiently to keep the database usable: meaningful summaries,
 
60
  and duplicates removed
 
61
 
 
62
It's OK to fix some bugs that just annoy you, even if they're not
 
63
rationally high.
 
64
 
 
65
You can use ``--fixes lp:12345678`` when committing to associate the
 
66
commit with a particular bug.
 
67
 
 
68
If there are multiple bugs with related fixes, putting "[master]" in the
 
69
title of one of them helps find it
 
70
 
 
71
It's often fastest to find bugs just using the regular Google search
 
72
engine, rather than Launchpad's search.
 
73
 
 
74
Martin Pitt says:
 
75
 
 
76
 | One of the things you should not do often is to start asking
 
77
 | questions/for more debug info and then forget about the bug. It's just
 
78
 | a waste of the reporter's and your time, and will create frustration
 
79
 | on the reporter side. 
 
80
 
 
81
 
 
82
Priorities
 
83
**********
 
84
 
 
85
The suggested priorities for bug work are:
 
86
 
 
87
1. Fix critical bugs.
 
88
   
 
89
2. Get existing fixes through review and landed.
 
90
 
 
91
3. Fix bugs that are already in progress.
 
92
 
 
93
4. Look at bugs already assigned to you, and either start them, or change
 
94
   your mind and unassign them.
 
95
 
 
96
5. Take new bugs from the top of the stack.
 
97
 
 
98
6. Triage new bugs.
 
99
 
 
100
It's not strict and of course there is personal discretion but our work
 
101
should be biased to the top of this hierarchy.
 
102
 
 
103
 
 
104
Clear Bugs
 
105
**********
 
106
 
 
107
Bugs should have clear edges, so that you can make a clear statement about
 
108
whether a bug is fixed or not.  (Sometimes reality is complicated, but aim
 
109
for each bug to be clear.)
 
110
 
 
111
Bugs on documentation, performance, or UI are fine as long as they're
 
112
clear bugs.
 
113
 
 
114
Examples of good bugs:
 
115
 
 
116
* "ValueError in frob_foo when committing changed symlink" - although
 
117
  there may be many possible things that could cause a ValueError there,
 
118
  you should at least know when you've fixed the problem described in this
 
119
  bug.
 
120
 
 
121
* "Unclear message about incompatible repositories" - even though the user
 
122
  may not agree the new message is sufficiently clear, at least you know
 
123
  when you've tried to fix it.
 
124
 
 
125
Examples of bad bugs:
 
126
 
 
127
* "Commit is too slow" - how fast is fast enough to close it?  "Commit
 
128
  reads the working tree twice" is clearer.
 
129
 
 
130
 
 
131
Bug Status
 
132
**********
 
133
 
 
134
New
 
135
    The bug has just been filed and hasn't been examined by a developer
 
136
    yet.
 
137
Incomplete
 
138
    The bug requires more information from the reporter to make progress.
 
139
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
 
142
    it's not a good idea for a developer to spend time reproducing the bug
 
143
    until they're going to work on it.)
 
144
Triaged
 
145
    We don't use this status.  If it is set, it means the same as
 
146
    Confirmed.
 
147
In Progress
 
148
    Someone has started working on this.
 
149
Won't Fix
 
150
    The behaviour complained about is intentional and we won't fix it.
 
151
    Needless to say, be thoughtful before using this status, and consider if
 
152
    the user experience can be improved in some other way.
 
153
Invalid
 
154
    The reporter was confused, and this is not actually a bug.
 
155
    Again, be sensitive in explaining this to the user.
 
156
Fix Committed
 
157
    A fix for this bug exists in a branch somewhere.  Ideally the bug will
 
158
    be linked to the branch.
 
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.
 
164
 
 
165
 
 
166
Bug Importance
 
167
**************
 
168
 
 
169
Critical
 
170
    This is a serious bug that could cause data loss, stop bzr being
 
171
    usable in an important case, or represents a regression in something
 
172
    previously working.  We should fix critical bugs before doing other
 
173
    work, or seriously consider whether the bug is really critical
 
174
    or whether the other change is more urgent.
 
175
High
 
176
    This is a bug that can seriously interfere with people's use of
 
177
    Bazaar.  We should seriously consider fixing these bugs before
 
178
    working on new features.
 
179
Medium
 
180
    A regular bug.  We'd like to fix them, but there may be a long delay.
 
181
Low
 
182
    Something suboptimal that may affect an unimportant case or have a
 
183
    fairly easy workaround.
 
184
Wishlist
 
185
    These will basically never get done.
 
186
 
 
187
Bugs rated Medium or lower are unlikely to get fixed unless they either
 
188
pique the interest of a developer or are escalated due eg to many users
 
189
being affected.
 
190
 
 
191
Not every existing bug is correctly rated according to this scale, and we
 
192
don't always follow this process, but we'd like to do it more.  But
 
193
remember, fixing bugs is more helpful than gardening them.
 
194
 
 
195
 
 
196
Assignment
 
197
**********
 
198
 
 
199
Assigning a bug to yourself, or someone else, indicates a real intention
 
200
to work on that bug soon.
 
201
 
 
202
 
 
203
Targetting Bugs
 
204
***************
 
205
 
 
206
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.
 
210
 
 
211
Therefore, we don't target bugs that we'd like to have fixed or that could
 
212
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.
 
217
 
 
218
 
 
219
Backports
 
220
*********
 
221
 
 
222
Sometimes we'll want to make a special point-release update (eg 1.15.1)
 
223
off an already-released branch including a fix for a particular bug.  To
 
224
represent this, create a new bug task (ie link in the status table on the
 
225
bug page) by clicking the `poorly-named
 
226
<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.  
 
229
 
 
230
This bug task then has a separate status and importance to indicate the
 
231
separate work to get it into that release.
 
232
 
 
233
 
 
234
The News File
 
235
*************
 
236
 
 
237
Most bugs that are fixed should be mentioned in a `NEWS
 
238
<../en/release-notes/NEWS.html>`_ file entry,
 
239
including the bug number.
 
240
(Exceptions might be bugs that are not at all user visible.)
 
241
 
 
242
 
 
243
Tags
 
244
****
 
245
 
 
246
Here are some bug tags we use.  In Malone tags are currently of limited use, so don't feel obliged to tag bugs unless you're finding it useful.
 
247
 
 
248
 
 
249
authentication
 
250
    authenticating to servers
 
251
 
 
252
backport 
 
253
    candidate for backporting to an update of the previous release
 
254
 
 
255
dirstate 
 
256
    WorkingTree4
 
257
 
 
258
easy 
 
259
    should be possible to finish in an hour or two
 
260
 
 
261
hpss 
 
262
    bugs about the High-Performance Smart Server, i.e. bzr+ssh://, etc.
 
263
 
 
264
launchpad 
 
265
    bugs about interactions with launchpad (typically this means bzrlib.plugins.launchpad).
 
266
 
 
267
locale 
 
268
    problems using locales other than English
 
269
 
 
270
memory 
 
271
    problems where we use too much memory for some reason
 
272
 
 
273
newformat 
 
274
    fixing this would need a new disk format
 
275
 
 
276
performance 
 
277
    bugs about performance problems.
 
278
 
 
279
test 
 
280
    needs changes to the test framework
 
281
 
 
282
transport 
 
283
    virtual filesystem for http, sftp, etc
 
284
 
 
285
trivial 
 
286
    should be very easy to fix (10-20 minutes) and easily landed: typically just spelling errors and the like
 
287
 
 
288
ui 
 
289
    bugs relating to the bzr user interface, e.g. confusing error messages.
 
290
 
 
291
win32 
 
292
    bugs that mainly affects Windows. Also there is cygwin and win98 tags for marking specific bugs. 
 
293
 
 
294
You can see the full list of tags in use at
 
295
<https://bugs.edge.launchpad.net/bzr/+bugs>.  As of September 2008 the
 
296
list is on the right. 
 
297
 
 
298
.. vim: ft=rst