Bug Triage and Blueprints

Clint Byrum clint at ubuntu.com
Thu Nov 17 00:27:12 UTC 2011

I've just spent the last hour or so clearing out a lot of old bug reports
that were Status=>New Importance=>Undecided.

I'd like to suggest that we make *sure* that we review the list of bugs
that have basically been untouched on a regular basis. There were 50 of
these bugs when I started this session of triage, and its down to 30. I
started a Webnumbr graph, should start graphing tomorrow here:


At the very least, respond to the bug report and set the importance. If
you can't figure out the importance, then respond with a question and
set the status to Incomplete.

As juju gains popularity, this list is going to explode, and dilligent
triage is going to be the only way we actually stay in touch with our
most enthusiastic users.

One thing I noticed while going through these bugs was that there were
a lot of really broad sweeping feature requests, some of which we've
been discussing of late. Kapil and I had decided at UDS that we'd make
use of Blueprints to help bring some of these together.

The idea with blueprints is to break a big task up into littler ones
that fit better as a bug/task. IIRC, lpad can assign to blueprints,
so, if you are working on something that fits any of these blueprints,
please attach your bug report to it!

This will help people to see the roadmap for larger features in Juju
in a more concise way than the Kanban view, which is really more of a
"who is doing what" than a "what is in the pipeline".


I added machine-placement and subordinate-services. Just remember if
you see a bug that is clearly part of one of these features, attach it
to the blueprint. Likewise, as bigger features and overhauls become
clear, add a blueprint and attach any existing bug reports. Note
that the goal is that users can look at the current milestone view and
see not only the individual tasks, but the bigger features that are


Thanks, and happy hacking!

More information about the Juju mailing list