Maintenance and Enhancement of the Arsenal Reports used for tracking bugs

UDS Discussion Points:

Problems detected and discussed prior to UDS session:

0. [bjf] The reports have become business-critical for a couple of teams (at least). No one has been assigned responsibility or ownership to make sure that they get the care and feeding that they require.

  --> ursinha will take ownership of stable arsenal reports
  --> bryce will take ownership of development branch

1. [bjf] The reports use a jQuery table component that I found and have hacked on a little bit. Since we are not building a web application here, we could probably stick with jQuery. However, I am not opposed to reworking this to use YUI3 instead. I have done a little prototyping and there is a DataTable component that would meet most of the same needs. I really like the look of the tables as they are now and any other implementation would need to have the same look and features (sorting on multiple columns for example).

  --> Replacing jQuery with YUI is still a TBD. Since jQuery is already implemented,
       staying with that for now, pending completion of bjf's YUI experimentation work.

2. [arges] A feature I find useful for our reports is searching/filtering. Have a search box which filters out results to only see relevant bugs. This makes it useful it many people are looking at a queue to locate assigned bugs, and titles, etc. I have a rough implementation in my arsenal branch:
http://people.canonical.com/~arges/pictures/arsenal_search_example.png

[bjf] If you look at: http://people.canonical.com/~kernel/reports/_precise-open-bugs_.html and pull down the "Options" tab at the top you can select the assignee. Is this the same as your search or not?

[arges] It's just a different way to do it, I think its a bit more flexible as I can search on any strings. In addition, I've set it up so searches, or filters can be bookmarked so one can bookmark a page and 'save' that search.

  --> In scope for development branch

3. [cjwatson] The reports seem to be very unreliable, and apparently don't alert anyone when they fail. This makes it troublesome to use them for tech lead work.
    [bdmurray] I believe things have improved on this front.

  --> bryce uses email notifications for alerting of failures in the X scripts (with filtering out of general launchpad downtime and known flakiness). These will be repurposed to provide alert notifications across all teams.

4. [cnd] For Open Input Framework, and possibly other projects where Canonical/Ubuntu are the upstreams and downstreams, we need better bug collecting functionality. Our use cases are:
 * We want all Ubuntu bugs for packages the oif-bugs team is structurally subscribed to
 * We want all Ubuntu bugs that the oif-bugs team is directly subscribed to
 * We want all bugs that are part of the canonical-multitouch meta project

  --> In scope for development branch

Outcome of UDS session discussion:

- Define which versions of the tools we're using to avoid upstream changes to break scripts
- Define who will be part of the "maintenance" team
- Define if we're adopting code reviews
- Define a procedure on deployment: where to deploy and so on

- Is there a wiki page for Arsenal current development process?
   - Ubuntu wiki page to discuss that - http://wiki.ubuntu.com/Arsenal
   - Static pages for arsenal docs

- Questions for Use Cases:
1. What data fields (columns) do you show/need shown in your reports?
2. What filtering or sorting do you use or want to use in your reports?
3. How will the data in your reports be put to use? I.e. how are you processing the bugs?
4. What other features do you have, need, or want in your reports?

Work items:
[ursinha] Define process for contributions to stable arsenal releases: TODO
[ursinha] Define process for contributions to stable lpltk releases: INPROGRESS
[bryce] Arsenal script cleanup - define which templating system we're using: DONE
[brad-figg] Arsenal script cleanup - define which javascript library we're using: DONE
[bryce] Arsenal script cleanup - define which scripts we're keeping: DONE
[bryce] Arsenal script cleanup - define graphing system: POSTPONED
[bryce] Create a development and a stable branch of arsenal: DONE
[bryce] Separate out python-launchpadlib-toolkit (lpltk) out of arsenal: DONE
[bryce] Establish testing scaffolding for lpltk and arsenal unit tests: DONE
[bryce] Define deployment process onto local systems: DONE
[bryce] Define deployment process onto QA server (cranberry): INPROGRESS
[bryce] Define process of Arsenal development using code reviews (first only Bryce, people being mentored would become reviewers.): DONE
[bryce] Arsenal mailing list open so people can join and discuss (another team to have commit access?): DONE
[ursinha] consolidate public arsenal reports running under the ubuntu-reports-dev account on cranberry: TODO
[bryce] setup mailing list for cronjob failures from ubuntu-dev-reports and filter out launchpad timeouts: DONE