Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.


The goal is to provide a dashboard covering all the variables that go into determining whether Ubuntu is release ready - bug count, RC bug count, archive analysis reports, iso testing summaries, etc, linking to detailed data about each metric.

Release Note

Not applicable — this dashboard will be part of the development process, not part of Ubuntu itself. Once in a useful state, however, the page should be announced on .... and linked to from ....


There currently exists numerous sites which display information regarding the state of Ubuntu. However, it is inconvenient having to remember multiple sites as well as navigate to multiple locations to obtain wanted information. It would be useful if this information were gathered into one central location. A dashboard will help showcase this information at a single location and provide the release managers and Distro Team a way to measure the quality of an upcoming release.

Use Cases

  • Release manager Bob wants to know the current Distro release status and what showstopping bugs exist at this point in the release. He'd also like to drill down and see which of these bugs relate to the packages his team oversees. He currently has to visit multiple different locations to gather this information.
  • Mary in the distro team wants to know about the iso testing status and the current number of iso-testing related bugs. This will help her determine which areas still need help testing as well as what areas are proving to be problematic. She also currently has to visit multiple locations to find this information.
  • Jack noticed one showstopper in the previous build, but a new one is now available which fixes it. He wants to see the test results from both the previous build and the current build to get a sense of our confidence level for the new build.
  • In the current build we are testing there is already one showstopper known. Jill knows we're going to have to respin (and may be able to see that there's an upload queued to fix it), but she wants to continue testing the current build to catch any other issues before we reset the test cycle.
  • The Ubuntu desktop ISO is considered final, validated and ready to release, but the server ISO needs to be rebuilt to fix a bug. A new build has just gone up and hasn't been tested yet. Frank wants to see the test results from the previous build, but make sure it's clear that they're old.


  • The system should scale gracefully, i.e. it should be trivial to add a new data source and incorporate it into the dashboard display
  • Visual cues (e.g. color) should be used to show at a glance whether anything is outstanding
  • Dashboard should provide a link to the specific metric thus enabling the capability to drill down to the information
  • A distinction could be made between critical indicators (blocking) and other metrics (e.g. bug counts)


Phase I (Release readiness / critical path)

The items in this table will be the initial target.




launchpad distro release status

high/critical milestoned (rc) bugs

failed builds (all components), (index of failed/pending main builds)/

include links to failed-build logs

packages which have no current build (all components), index for main on URL above

pending uploads in the queue that need to be approved or

iso testing

iso bug count

filter on 'iso-testing' tag in launchpad

iso's up to date

compare package versions on CDs with archive<build_version or "current">/hardy-alternate-i386.list (alternates)<build>/hardy-desktop-i386.manifest (desktops)

Primary/official architectures (i386, amd64 and sparc) and flavours (ubuntu, kubuntu, edubuntu) are much more relevant than the others

oversize cd images presence of *.OVERSIZED files

all CDs and DVDs for i386/amd64/sparc and {,U,K,Ed,X}ubuntu

automatic upgrade testing result

uninstallability of *-desktop packages and other archive inconsistencies


make sure it is seeding

mirror publishing

meta-release index


Example Prototype (mdz)



Launchpad release status


Pending uploads


Failed package builds


Pending package builds


Pending livefs builds


Archive inconsistencies


Outdated installation media

desktop, alternate

Showstopper bugs

#1234, #2345

Automated installation tests

Successful (current build)

Manual installation tests

Successful (build 20071031.2)

Pre-published mirrors


Meta-release index




Information Display

  • The use of color will help convey the quality or severity of a metric
    • red will indicate a failure/regression
    • green will indicate success/stability
    • grey will display non-volatile information
  • additional text information will be appended in ()'s
    • this can help convey versions, timestamps, etc.
    • if this becomes too cluttered we can break it out into another column
  • there should also be an indication as to when the stat was last updated as not all items will be updated at the same frequency
    • rather than clutter the table, I'd prefer to have a link to a page detailing the cronjob
  • some metrics will have to incorporate multiple rows (for ex. up to date iso's)

Other Logistics

UI Changes

  • There is a risk the interface could get very "cluttered", esp. if we wish to show historical info (graphs, etc.)

Test/Demo Plan

Outstanding Issues

The dashboard will evolve over several cycles. Items listed here should be developed as separate specifications.

  • all data should be tracked historically, but not in the first version
    • maybe keep all output files (data files?) in bzr
    • low-priority for implementation
  • XML-RPC interface? or scrape HTML
    • Scraping HTML will be very brittle
    • One suggestion was to have each source output javascript object notation (JSON)
      • Each data source can then be "syndicated" at given locations (e.g. http://.../.../datasource1.js, and update at whatever frequency makes most sense for that particular data source (hourly, daily, etc.).

      • Can still use scraping for areas that do not output this format, but have those tools each output JSON for inclusion into the interface
      • The weather report page can then re-load these objects asynchronously, so page will update itself without needing manual reload
  • ideally viewers should be able to filter the stats they want to view and save(?) preferences - most likely won't happen in the initial version
  • It may also help to have collapsed sections that can be expanded to get the next level of detail. For instance, one line may show total number of new, open, etc. bugs, but when expanded it shows a further breakdown (per milestone, per area, over time, or etc.) - again, most likely wont' happen in the initial version
  • As quality/stability increases the color will intensify
    • Success





    • for example, if there are multiple successful builds in a row, the green will intensify in color
  • Likewise as severity escalates the color will intensify
    • Failure





    • for example, if the number of showstopper bugs increases, the red will intensify
  • set the focus of the report based on a given build

Phase II (further metrics)

The items listed here will be taken into consideration after the initial implementation (Phase I) is satisfactory with the target audience.

BoF agenda and discussion

Discussions were held at UDS Boston 2007 and the comments have been incorporated into the above spec.


QATeam/Specs/DeveloperWeatherReport (last edited 2008-08-06 16:18:53 by localhost)