arsenal-devel team mailing list archive

[Bryce Harrington <bryce@xxxxxxxxxxxxx>]

Rick also mentioned about some of the various reporting tools I've done,
and there was one I wanted to highlight in particular:

 http://people.canonical.com/~bryce/Reports/symptoms_intel.html

The purpose of this particular report is to allow browsing bugs by
"symptom" to help spot dupes, or to make it easier to work on a group of
similar bugs.

I wanted to mention this one particularly, because you said we ought to
look at identifying a common framework, and in fact when I did this
report, I also had exactly that aim in mind.


Architecturally, I split the reports into two pieces.  First is the
"backend" which collects the data from launchpadlib or whereever.  It
stores the data as a simple JSON file:

  http://people.canonical.com/~bryce/Reports/symptoms_intel.json

Generating JSON files is really easy with python (or perl), with just a
few lines of code:

  http://bazaar.launchpad.net/~arsenal-devel/arsenal/master/annotate/head%3A/scripts/bugs-symptoms.py

JSON files are nice because it's just Javascript, and it's a simple
format that's both machine parsable and fairly easy to read by eyeball
too.

Similarly, the "display" logic to turn this data into a web page can be
kept really general purpose (so long as the JSON format is kept
consistent across tools).  I do this with the 'bug-listing' script and
couple generic templates here:

  http://bazaar.launchpad.net/~arsenal-devel/arsenal/master/files/head%3A/web/templates/

You could also imagine using other kinds of display tools, like
bugzapper if you prefer interacting in a GUI rather than HTML.


Anyway, I think this idea of splitting out front end from back end is
really powerful, because it allows much more richer options for sharing
data between ourselves and our various tools than could be done in an
all-in-one type of tool.

Here's a practical example - Brian provides this really handy dandy
report of bugs fixed in a particular release cycle:

  http://qa.ubuntu.com/reports/bug-fixing/karmic-fixes-report.html

This is great at giving a high level overview of *everything*, but what
Leann wanted a view of just fixed Linux kernel bugs?  Or if Rick wanted
a report showing only bugs fixed by Desktop team members?  Or Marjo
wanted to use it as input for generating a report about High, Medium,
and Low priority bugs fixed this month.  It would be slick to have the
data from the above report as a .json file, which Leann, Rick, and Marjo
could each reuse in generating their own reports according to their own
needs.

I'm picking on Brian, but we've got tons and tons of other really great
reports like this one scattered around the company, which could be
remixed to provide more customized information that individuals need.

You could imagine the QA team providing other different "json bug feeds"
like this...  Bugs with patches attached...  The top 1000 oldest bugs...
Bugs with no package assigned but that mention "regression" somewhere in
the subject/tags/description...  etc. etc.  By providing this data as
feeds rather than as a static report it would enable people to further
filter or process them.

Bryce