Ubuntu Wiki

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 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

http://status.qa.ubuntu.com

Jaunty

Improvements/Features

HIGH

• historical view of data - ie like bryce's page (Needs change to php code)
  • individual graphical view of status' (possibly clickable from the graph headers)

• look at upstream report to find packages to add - https://edge.launchpad.net/ubuntu/+upstreamreport

• Reword "Most duplicates" to "Bug with most duplicates"

MEDIUM

• most recent version of the package (see "More info on the package itself" on the Feedback wiki page)

  • https://edge.launchpad.net/ubuntu/+source/linux-ports

    • per release and per pocket
• Bugs with bzr branches - possible to find these with bugnumbers
• graphs should use the svg instead of a png file (May need change to the php code)
• Last at zero counter* [see footnote]
• bug info for bug tags like apport-crash, apport-bug, regresssion, bitesize
• Linking to patches in Ubuntu e.g. n-m patches more for upstreams

  • example - http://patches.ubuntu.com/a/amarok/amarok_2:1.4.10-0ubuntu3.patch or http://patches.ubuntu.com/by-release/atomic/ubuntu/a/amarok/ (which scales more, as more changes are made)

  • apparmor
  • amarok

LOW

• Number of bugs carried over from release to release (missed milestone)
• Change the theme for the links in the number : this is not obvious, I did not notice it for a while. (Needs change to the CSS style sheet)
  • will cause a conflict with the rest of the qa.ubuntu.com site so would require a separate CSS style sheet
  • additionally adding color changes will need modification

WISHLIST

• breakdowns by release
• delta's for increasing/decreasing number of duplicates and subscribers to indicate the popularity of a given bug
  • possibly leverage the mailing list to gather this info
• bug gravity -
  • a mathematic calculation of the bugs impact using no of subscribers, comments, metoos and duplicates

• Delta's of bug stats for each milestone; overlaps with http://people.ubuntu.com/~ogasawara/weatherreport.html

• deltas should be clickable links to list of bugs e.g. the new bugs in the past seven days
  • wait to use the "bug bag" functionality that will come with LP 3.0
• vertical lines for releases and package uploads
  • still don't know how to do this in gnuplot
• bug info section for release targetted bugs

Hardy

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.

• Click to zoom Source

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

http://qa.ubuntu.com/reports/pkg-stats/

Which is derived from a list of packages with more than 100 bugs:

http://bazaar.launchpad.net/~canonical-qa/canonical-qa-tracking/main/annotate/209?file_id=gt100bugpackages.txt-20080215170433-q6f6v4qipfatvqen-1

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

• Add any additional feedback or feature requests to https://wiki.ubuntu.com/QATeam/Specs/PackageStatusPages/Feedback

CategorySpec