~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

289

bugs for causes of VFS methods of the smart server

290

291

launchpad

264

launchpad

292

265

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

293

266

294

locale

267

locale

295

268

problems using locales other than English

296

269

297

memory

270

memory

298

271

problems where we use too much memory for some reason

299

272

300

newformat

273

newformat

301

274

fixing this would need a new disk format

302

275

303

performance

276

performance

304

277

bugs about performance problems.

305

278

306

regression

307

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

308

309

test

279

test

310

280

needs changes to the test framework

311

281

312

transport

282

transport

313

283

virtual filesystem for http, sftp, etc

314

284

315

trivial

285

trivial

316

286

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

317

287

318

288

319

289

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

320

290

321

win32

322

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

291

win32

292

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

323

293

324

294

You can see the full list of tags in use at

325

295

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

326

list is on the right.

296

list is on the right.

327

297

328

298

.. vim: ft=rst

Older »