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

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/malone/+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.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.

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.

249

273

authentication

250

274

authenticating to servers

251

275

252

backport

276

backport

253

277

candidate for backporting to an update of the previous release

254

278

255

dirstate

279

dirstate

256

280

WorkingTree4

257

281

258

easy

282

easy

259

283

should be possible to finish in an hour or two

260

284

261

hpss

285

hpss

262

286

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

263

287

264

hpssvfs

288

hpssvfs

265

289

bugs for causes of VFS methods of the smart server

266

290

267

launchpad

291

launchpad

268

292

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

269

293

270

locale

294

locale

271

295

problems using locales other than English

272

296

273

memory

297

memory

274

298

problems where we use too much memory for some reason

275

299

276

newformat

300

newformat

277

301

fixing this would need a new disk format

278

302

279

performance

303

performance

280

304

bugs about performance problems.

281

305

282

test

306

regression

307

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

308

309

test

283

310

needs changes to the test framework

284

311

285

transport

312

transport

286

313

virtual filesystem for http, sftp, etc

287

314

288

trivial

315

trivial

289

316

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

290

317

291

318

292

319

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

293

320

294

win32

295

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

321

win32

322

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

296

323

297

324

You can see the full list of tags in use at

298

325

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

299

list is on the right.

326

list is on the right.

300

327

301

328

.. vim: ft=rst

Older »