~bzr-pqm/bzr/bzr.dev

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

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

Generalities

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

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

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

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.

188

164

189

165

190

166

Bug Importance

228

204

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

229

205

230

206

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

231

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

232

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

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.

233

210

234

211

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

235

212

be fixed in a particular release, we only target bugs that must be fixed

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.

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.

239

217

240

218

241

219

Backports

246

224

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

247

225

bug page) by clicking the `poorly-named

248

226

<https://bugs.launchpad.net/bugs/132733>`_ "Target to Release" link.

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)

227

Target it to the appropriate series (ie 1.15) and then to the milestone

228

within that release.

253

229

254

230

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

255

231

separate work to get it into that release.

273

249

authentication

274

250

authenticating to servers

275

251

276

backport

252

backport

277

253

candidate for backporting to an update of the previous release

278

254

279

dirstate

255

dirstate

280

256

WorkingTree4

281

257

282

easy

258

easy

283

259

should be possible to finish in an hour or two

284

260

285

hpss

261

hpss

286

262

bugs about the High-Performance Smart Server, i.e. bzr+ssh://, etc.

287

263

288

hpssvfs

264

hpssvfs

289

265

bugs for causes of VFS methods of the smart server

290

266

291

launchpad

267

launchpad

292

268

bugs about interactions with launchpad (typically this means bzrlib.plugins.launchpad).

293

269

294

locale

270

locale

295

271

problems using locales other than English

296

272

297

memory

273

memory

298

274

problems where we use too much memory for some reason

299

275

300

newformat

276

newformat

301

277

fixing this would need a new disk format

302

278

303

performance

279

performance

304

280

bugs about performance problems.

305

281

306

regression

307

bugs which represent an aspect of bzr becoming accidentally less good than it was.

308

309

test

282

test

310

283

needs changes to the test framework

311

284

312

transport

285

transport

313

286

virtual filesystem for http, sftp, etc

314

287

315

trivial

288

trivial

316

289

should be very easy to fix (10-20 minutes) and easily landed: typically just spelling errors and the like

317

290

318

291

319

292

bugs relating to the bzr user interface, e.g. confusing error messages.

320

293

321

win32

322

bugs that mainly affects Windows. Also there is cygwin and win98 tags for marking specific bugs.

294

win32

295

bugs that mainly affects Windows. Also there is cygwin and win98 tags for marking specific bugs.

323

296

324

297

You can see the full list of tags in use at

325

298

<https://bugs.edge.launchpad.net/bzr/+bugs>. As of September 2008 the

326

list is on the right.

299

list is on the right.

327

300

328

301

.. vim: ft=rst

Older »