PackageStatusPages
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.
Launchpad Entry: package-status-pages
Summary
The goal is to provide a web page for each of the top 20-30 packages in Ubuntu showing bug counts and other vital signs and statistics.
Release Note
Not applicable - these status pages will not be part of Ubuntu itself. However, once they are in a condition to provide useful information they should be announced on relevant mailing lists and linked to from qa.ubuntu.com
Rationale
There currently exists sites which reflect the general state of Ubuntu as a whole in terms of release readiness. However, it may be more useful to package maintainers if they have a landing page describing the general state of their specific package. Package specific status pages can help showcase this information and help package maintainers and users measure the quality of a package.
Use Cases
- Ubuntu package maintainer Sue is interested in the overall status of the package she is maintaining. The package specific status page should provide her with some general statistics regarding its state.
- Upstream package maintainer Bob wants to follow the status of his package in Ubuntu. He's likely interested in upstream bug reports filed in launchpad among other metrics. This package status page should contain this information.
- Community member Sam wants to help contribute to package foo. The package specific status page may provide Sam ideas where he could best help contribute. For example, triaging new incoming bugs, reviewing bugs with patches, evaluating high impact bugs . . .
Assumptions
- Adding a new package status page should be trivial - should follow a template
- Status page should provide links to the specific metric thus enabling users to drill down to the specific information
- Incorporate visual cues, for example graphs or charts, to be able to quickly asses status as well as possibly asses status over time
Design
List of ideas to incorporate into each of these pages:
Bug Data
- volume of incoming bugs
- percentage of bugs in a certain state (or upstream)
- number of unreviewed patches (or fixed upstream)
- Oldest triaged/new/... bug
- average time of first reply
- percentage of bugs reported upstream
High Impact
- most duplicated bug report / bugs with most subscribers
- percentage of bugs in a certain importance
- percentage of apport-crash reports
External Data
- last upload / number of uploads
- does it build
- does it install
- severe lintian errors
- new upstream version available
- popcon.ubuntu.com(?)
Documentation coverage
- Is the shipped documentation up-to-date and comprehensive? Likewise on help.ubuntu.com
- Is the debugging documentation complete/up-to-date?
Layout
A layout similar to qa.ubuntu.com and brainstorm will be used.
Nested structure
The pages should be nested on 3 levels: Distro, category and Application:
- Distro: status.qa.ubuntu.com/ubuntu will contain global data for Ubuntu
- Category: Key categories such as: Gnome desktop, Gnome applications, Display, Mozilla, aligned with the areas of responsibility of various teams
Application: Single applications (that may in turn be comprised of a few packages), like OpenOffice, Firefox
The main distro page should contain a list of categories and the category pages should have links to the Applications that make up that category. The applications page finally contains links to the Launchpad pages for the source packages being tracked. The results displayed on the applications page is aggregated directly from the data of the packages associated with it and likewise the category page is an aggregate of the applications it contains. However, the Ubuntu page is not the sum of categories but rather global data sourced directly (unless we make an 'everything else' category page).
Implementation
Incorporate code to leverage qa.ubuntu.com code base. Most plots links and metrics are pulled automatically from various existing sources. Some items (like whether the debugging docs are complete) are stored in a bzr branch.
List of packages to consider having pages for
Ubuntu summary at status.qa.ubuntu.com - A global summary of bug stats in Ubuntu. Will replace [http://people.ubuntu.com/~brian/graphs/ this page]. (Distro level)
The following is a sample structure of Categories, Applications (and packages). The configuration should be flexible so it can be adjusted after feedback. The structure will be stored in an XML file in bzr. The following structure is roughly ordered by teams:
Graphics
Xorg (server core and drivers)
Configuration (monitor setup, bullet-proof-x)
Kernel
Linux package (linux, l-r-m)
Mozilla
Firefox (core app and extensions)
Thunderbird (core and plugins)
Gnome desktop
Accessibility (orca, espeak, gok)
Nautilus
Gnome core (gnome session, gtk+, libgnome, etc.)
gnome-power-manager
Compiz
Gnome applications
Rhythmbox
Totem
Evolution (client and exchange server)
Pidgin
KDE desktop
Accessibility
KDE core (kde-core)
KDE desktop - (kicker, pladma)
KDE applications
Amarok
Konqueror
Koffice
KDE PIM
Openoffice (including help, language packages and Java support)
Printing
Printing config (system-config-printer)
Printing backends (cupsys, drivers)
Server
Samba
Apache
Platform
Live CD install (ubiquity)
Alternate install (d-i)
update-manager
synaptic
hal
usplash
Network manager
Code Changes
To be implemented in python, extending existing weather report and bug list pages. The results will be pulled into navigateable pages in the drupal-based QA site and later the Zope-based version. The HTML pages will remain simple, stable and thus machine-readable.
Launchpad will soon allow for querying of data via a new API which is to be released in June/July. Python-launcpad-bugs will be taught to use this API rather than screen scraping information.
Outstanding Issues
- Selecting categories, applications and packages