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

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

Generalities

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

Anyone involved with Bazaar is welcome to contribute to managing our bug

reports. **Edit boldly**: try to help users out, assess importance or improve

the bug description or status. Other people will see the bugs: it's

better to have 20 of them processed and later change the status of a

couple than to leave them lie.

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

lower, than to have someone else edit all bugs.

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

database. It's more useful to take one bug through to a shipped fix than

to partially investigate ten bugs. You don't get credit for a bug until

the fix is shipped in a release. Users like getting a response to their

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)

* garden sufficiently to keep the database usable: meaningful summaries,

and duplicates removed

It's OK to fix some bugs that just annoy you, even if they're not

rationally high.

You can use ``--fixes lp:12345678`` when committing to associate the

commit with a particular bug.

If there are multiple bugs with related fixes, putting "[master]" in the

title of one of them helps find it

It's often fastest to find bugs just using the regular Google search

engine, rather than Launchpad's search.

Martin Pitt says:

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

4. Look at bugs already assigned to you, and either start them, or change

your mind and unassign them.

5. Take new bugs from the top of the stack.

6. Triage new bugs.

100

It's not strict and of course there is personal discretion but our work

101

should be biased to the top of this hierarchy.

102

103

104

Clear Bugs

105

**********

106

107

Bugs should have clear edges, so that you can make a clear statement about

108

whether a bug is fixed or not. (Sometimes reality is complicated, but aim

109

for each bug to be clear.)

110

111

Bugs on documentation, performance, or UI are fine as long as they're

112

clear bugs.

113

114

Examples of good bugs:

115

116

* "ValueError in frob_foo when committing changed symlink" - although

117

there may be many possible things that could cause a ValueError there,

118

you should at least know when you've fixed the problem described in this

119

bug.

120

121

* "Unclear message about incompatible repositories" - even though the user

122

may not agree the new message is sufficiently clear, at least you know

123

when you've tried to fix it.

124

125

Examples of bad bugs:

126

127

* "Commit is too slow" - how fast is fast enough to close it? "Commit

128

reads the working tree twice" is clearer.

129

130

131

Bug Status

132

**********

133

134

New

135

The bug has just been filed and hasn't been examined by a developer

136

yet.

137

Incomplete

138

The bug requires more information from the reporter to make progress.

139

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

142

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

143

until they're going to work on it.)

144

Triaged

145

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

146

Confirmed.

147

In Progress

148

Someone has started working on this.

149

Won't Fix

150

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

151

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

152

the user experience can be improved in some other way.

153

Invalid

154

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

155

Again, be sensitive in explaining this to the user.

156

Fix Committed

157

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

158

be linked to the branch.

159

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.

164

165

166

Bug Importance

167

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

168

169

Critical

170

This is a serious bug that could cause data loss, stop bzr being

171

usable in an important case, or represents a regression in something

172

previously working. We should fix critical bugs before doing other

173

work, or seriously consider whether the bug is really critical

174

or whether the other change is more urgent.

175

High

176

This is a bug that can seriously interfere with people's use of

177

Bazaar. We should seriously consider fixing these bugs before

178

working on new features.

179

Medium

180

A regular bug. We'd like to fix them, but there may be a long delay.

181

Low

182

Something suboptimal that may affect an unimportant case or have a

183

fairly easy workaround.

184

Wishlist

185

These will basically never get done.

186

187

Bugs rated Medium or lower are unlikely to get fixed unless they either

188

pique the interest of a developer or are escalated due eg to many users

189

being affected.

190

191

Not every existing bug is correctly rated according to this scale, and we

192

don't always follow this process, but we'd like to do it more. But

193

remember, fixing bugs is more helpful than gardening them.

194

195

196

Assignment

197

**********

198

199

Assigning a bug to yourself, or someone else, indicates a real intention

200

to work on that bug soon.

201

202

203

Targetting Bugs

204

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

205

206

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.

210

211

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

212

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.

217

218

219

Backports

220

*********

221

222

Sometimes we'll want to make a special point-release update (eg 1.15.1)

223

off an already-released branch including a fix for a particular bug. To

224

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

225

bug page) by clicking the `poorly-named

226

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

229

230

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

231

separate work to get it into that release.

232

233

234

The News File

235

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

236

237

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

238

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

239

including the bug number.

240

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

241

242

243