arsenal-devel team mailing list archive

[Marjo Mercado <marjo.mercado@xxxxxxxxxxxxx>]

Hi Bryce,

Thank you for feeding us all this great info.

I specially like your ideas below regarding the common framework,
splitting out the front end and the backend, and the use cases.

I will work with Brian to see what the QA team can do based on current
best practices, tools and methodologies.

Thanks,

Marjo

On Mon, 2009-08-24 at 13:57 -0700, Bryce Harrington wrote:
> 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
-- 
Marjo F. Mercado
W: (212) 608-0358
IRC: marjo