~bzr-pqm/bzr/bzr.dev

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

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

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

* `Open bugs most recently changed first

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

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

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 feels it's higher or

efficient to change the importance if someone else feel's 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.

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

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

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

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

228

211

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

229

212

230

213

It's possible to target a bug to a milestone, eg

231

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

214

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

232

215

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

233

216

234

217

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

255

238

separate work to get it into that release.

256

239

257

240

258

Release Notes

241

The News File

259

242

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

260

243

261

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

262

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

244

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

245

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

263

246

including the bug number.

264

247

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

265

248

267

250