← 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: Canonical.com Patch Queue Manager
  • Date: 2009-09-19 00:32:14 UTC
  • mfrom: (4685.2.1 bzr.dev)
  • Revision ID: pqm@pqm.ubuntu.com-20090919003214-2dli9jc4y5xhjj3n
(mbp for garyvdm) Revert rename of
        test_merge_uncommitted_otherbasis_ancestor_of_thisbasis.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/bug-handling.txt
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.