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 original goal of this spec was to provide a web page for each of the top packages in Ubuntu showing bug counts and other vital signs and statistics. A solid start for this was developed during the Hardy cycle and can be seen at http://status.qa.ubuntu.com . This spec is now being recycled for Jaunty to document new features and improvements to the existing package status pages.

Release Note

Not applicable - the improvements for Jaunty will not be part of Ubuntu itself. However, once they are implemented they should be announced on relevant mailing lists.

Rationale

There exists sites which reflect the general state of Ubuntu as a whole in terms of release readiness. However, it was determined that package maintainers would find it useful if they had a landing page describing the general state of their specific package. During the Hardy cycle package specific status pages were made to help showcase this information and help package maintainers and users measure the state of a package. These status pages received positive feedback with additional requests for new features and improvements. Enhancing these pages with these new features and improvements will provide an added benefit to both maintainers and users.

Use Cases

• Ubuntu package maintainer Sue appreciates the current graphing trends displayed on the existing status pages. However, an added benefit would be to see a broader historical view of the data, not just a static one month time frame.

• End user Bob has noticed not every package has a status page being generated. It would be useful to him if, for example, packages shown in the upstream report could also have a corresponding status page.

Design

http://status.qa.ubuntu.com

Jaunty Improvements/Features

https://wiki.ubuntu.com/QATeam/Specs/PackageStatusPages/Feedback

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

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

Outstanding Issues

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

Hardy

We don't want to lose any historical information on how this spec has evolved. Below is some of the spec highlights that were written for the Hardy cycle.

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

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.

CategorySpec