~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

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

  • Committer: Andrew Bennetts
  • Date: 2010-01-04 02:25:11 UTC
  • mfrom: (4634.108.8 2.0)
  • mto: This revision was merged to the branch mainline in revision 4928.
  • Revision ID: andrew.bennetts@canonical.com-20100104022511-2tq2r9w2te84wzgs
Merge lp:bzr/2.0 into lp:bzr, including fixes for #343218, #495000, #495023, #494406 and #498378.

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
 
 
33
31
 
34
32
Generalities
35
33
************
138
136
    yet.
139
137
Incomplete
140
138
    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.
145
139
Confirmed
146
140
    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
 
141
    You don't have to reproduce the bug to mark it confirmed.  (Generally
148
142
    it's not a good idea for a developer to spend time reproducing the bug
149
143
    until they're going to work on it.)
150
144
Triaged
151
145
    We don't use this status.  If it is set, it means the same as
152
146
    Confirmed.
153
147
In Progress
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.
 
148
    Someone has started working on this.
161
149
Won't Fix
162
150
    The behaviour complained about is intentional and we won't fix it.
163
151
    Needless to say, be thoughtful before using this status, and consider if
166
154
    The reporter was confused, and this is not actually a bug.
167
155
    Again, be sensitive in explaining this to the user.
168
156
Fix Committed
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`_.
 
157
    A fix for this bug exists in a branch somewhere.  Ideally the bug will
 
158
    be linked to the branch.
171
159
Fix Released
172
160
    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
 
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.
188
171
 
189
172
 
190
173
Bug Importance