Versions page

[Robert Ancell]

Hi all,

You may be aware of the "versions" web page we use in the desktop team
to keep packages up to date:
http://people.canonical.com/~platform/desktop/versions.html
The purpose of the page is to give a priority queue (rainbow coloured)
of things to work on (by anyone who wants to).

This is a tool that has been growing over time and I've recently been
making some changes to it.  The main change recently being the number of
packages has more than doubled and there are grey ("untracked") packages.

Basically what it shows is all the packages that make up the Desktop
product (i.e. the CD).  This is cobbled together from the germinate
outputs [1] [2] [3].  As the desktop team is responsible for the desktop
image it's important we know every piece of software that makes this
image is up to date, and the versions page there to warn us when we are
not and help us fix it.

What it does now:
- Shows when we are behind upstream and/or Debian (common cases are we
make Ubuntu changes and then stop updating packages, or maintainers can
just disappear for rare packages leaving us out of date).
- Shows when packages are failing to build
- Show if a package is in process of being updated or blocked by linking
to Launchpad bugs (using the desktop-upgrade tag)
- Shows packages that we distribute that don't maintain (the grey
packages at the bottom, i.e. stuff maintained by foundations).
- Shows packages that we are distributing but are not tracking (grey
packages with upstream version "UNKNOWN") - these should be updated in
versions.py to track or ignore (or they should be removed from the seed
/ switched from recommends to suggests if they're innapropriate.  I'm
looking at you xbitmaps).

Where I'd like versions to go in the future:
- It should be a lot more real time (i.e. after uploading a package the
versions page should be up to date)
- We should be tracking all the build dependencies too - i.e. every
single line of code that can affect the desktop image
- We should have more than one versions page, e.g. an Ubuntu page, a
GNOME page, a foundations page, a KDE page (if those teams would also
find this useful).
- To do the above we really need to split the version checking out into
a service and generate the pages from the results of that (I'd always
wanted to use Launchpad to do this but it always seems to be too
difficult to get the data out of it).
- If the repository doesn't do it before us, we should flag which
packages have had build dependencies changed since they were built -
this is really a class of "potentially unknown build failure" that we
don't pick up until very late in the cycle (when archive rebuilds occur).

--Robert

[1]
http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.quantal/standard
[2]
http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.quantal/desktop-common
[3]
http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.quantal/desktop