← 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-15 06:07:11 UTC
  • mfrom: (4675.2.3 docs)
  • Revision ID: pqm@pqm.ubuntu.com-20090915060711-9vf2j4piarn8fgp9
(robertc) Replace bazaar-vcs.org/bzr/ references with launchpad
        hosting urls in developer docs. (Robert Collins)

Show diffs side-by-side

added added

removed removed

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