~bzr-pqm/bzr/bzr.dev

* `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>`_.

* `Open bugs by importance <https://bugs.edge.launchpad.net/bzr/+bugs>`_.

* `bzr bugs home page <https://bugs.launchpad.net/bzr>`_.

* `Critical bugs <https://bugs.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>`_.

* `Open bugs by importance <https://bugs.launchpad.net/bzr/+bugs>`_.

* `Open bugs most recently changed first

<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=>`_.

<https://bugs.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=>`_.

* `Most commonly duplicated bugs <http://tinyurl.com/bzr-bugs-by-dupes>`_.

Generalities

When you file a bug as a Bazaar developer or active user, if you feel

confident in doing so, make an assessment of status and importance at the

time you file it, rather than leaving it for someone else. It's more

efficient to change the importance if someone else feel's it's higher or

efficient to change the importance if someone else feels it's higher or

lower, than to have someone else edit all bugs.

It's more useful to actually ship bug fixes than to garden the bug

report, but they generally care more about getting bugs fixed.

The aim of investigating bugs before starting concentrated work on them is

therefore only to:

* determine if they are critical or high priority (and

should displace existing work)

| One of the things you should not do often is to start asking

| questions/for more debug info and then forget about the bug. It's just

| a waste of the reporter's and your time, and will create frustration

| on the reporter side.

Priorities

The suggested priorities for bug work are:

1. Fix critical bugs.

2. Get existing fixes through review and landed.

3. Fix bugs that are already in progress.

136

138

yet.

137

139

Incomplete

138

140

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.

139

145

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

146

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

142

148

it's not a good idea for a developer to spend time reproducing the bug

143

149

until they're going to work on it.)

144

150

Triaged

145

151

We don't use this status. If it is set, it means the same as

146

152

Confirmed.

147

153

In Progress

148

Someone has started working on this.

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.

149

161

Won't Fix

150

162

The behaviour complained about is intentional and we won't fix it.

151

163

Needless to say, be thoughtful before using this status, and consider if

154

166

The reporter was confused, and this is not actually a bug.

155

167

Again, be sensitive in explaining this to the user.

156

168

Fix Committed

157

A fix for this bug exists in a branch somewhere. Ideally the bug will

158

be linked to the branch.

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`_.

159

171

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.

172

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/launchpad/+bug/163694

164

188

165

189

166

190

Bug Importance

204

228

***************

205

229

206

230

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.

231

<https://bugs.launchpad.net/bzr/+milestone/1.16>. We use this to help the

232

release manager know what **must** be merged to make the release.

210

233

211

234

Therefore, we don't target bugs that we'd like to have fixed or that could

212

235

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.

236

and that will cause us to slip the release if they're not fixed. At any time,

237

very few if any of the bugs targeted to a release should be still open. By

238

definition, these bugs should normally be Critical priority.

217

239

218

240

219

241

Backports

224

246

represent this, create a new bug task (ie link in the status table on the

225

247

bug page) by clicking the `poorly-named

226

248

<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.

249

Target it to the appropriate series (ie 1.15). If the bug should also

250

prevent any point releases of that series then you should also target the

251

new task to the appropriate milestone within that release. (See Targeting Bugs

252

above)

229

253

230

254

This bug task then has a separate status and importance to indicate the

231

255

separate work to get it into that release.

232

256

233

257

234

The News File

258

Release Notes

235

259

*************

236

260

237

Most bugs that are fixed should be mentioned in a `NEWS

238

<../en/release-notes/NEWS.html>`_ file entry,

261

Most bugs that are fixed should be mentioned in the `Release Notes

262

<../en/release-notes/>`_ for the forthcoming version,

239

263

including the bug number.

240

264

(Exceptions might be bugs that are not at all user visible.)

241

265

243

267