+1 Maintenance Team

The +1 Maintenance Team is an experiment for the Ubuntu 12.04 development cycle to ensure that the development release stays in an installable state and that the archive is usable throughout the cycle.

Goals

Primary

• Maintain archive-level quality of 12.04 throughout the development cycle to minimise roadblocks for people developing features for 12.04, and to ease the preparation of milestones
  • Installability of main and important parts of universe, including ensuring that daily builds are always installable
  • Package buildability throughout the archive
  • Clean upgrades

  • Other similar consistency metrics

Secondary

• Improve infrastructure for tracking archive-level quality
  • Make existing reports easier to use (e.g. dynamic linking to bugs, comments, etc.)
  • Add new reports when it becomes feasible to do something with them
  • Track progress over time

Tertiary

• Provide the opportunity for the range of duties to prepare engineers for ubuntu-core-dev

• Provide a respite for team members who need a change
• Provide opportunity for technical cross-training within teams

Rationale

This work is currently done by regular developers as time permits, but it often falls by the wayside during feature development and needs to be done in a rush as milestones approach. In the 11.10 cycle this was often a source of stress. In a smaller team one might use a "stop the line" process, where build/test breakage causes landings to be halted until the problem is fixed, but Ubuntu is too large and broad for this to be efficient; having a small team dedicated to keeping things working should allow less cognitive dissonance for everyone.

QA engineers should not need to spend their time on problems that can be detected automatically. Fixing such problems aggressively and rapidly will allow QA to spend their time more productively. It should also increase the likelihood of getting successful image builds on a regular basis, which was a particular problem for the ARM team in the 11.10 cycle.

Driving our existing reports of automatically-detectable quality problems to zero and keeping them there should allow us to ratchet up quality over time (for example, many upgrade problems are already detected by the conflict checker, but because there are so many other problems we rarely garden that list).

Removing packages is an acceptable alternative to fixing them, although as usual we should think about whether this is the right thing to do case by case (e.g. removed from Debian, unmaintained upstream, fixes are too invasive/complicated/unknown, superseded by some other package, etc.).

Administration

Within Canonical, this is a voluntary rotational team; interested developers will normally spend one or two months on this team at a time. Line management is not affected. In some cases (when substitutes cannot be arranged) line managers may wish to arrange for developers to continue to spend a day a week on their normal duties.

It would be great for non-Canonical people to get involved too. There's a fair bit of overlap here with the kinds of things MOTU does, although we have a slightly different focus.

A minimum useful staffing level will be three people.

None of this team's work is expected to be private. They should coordinate on ubuntu-devel (etc.) or if necessary a new public mailing list / etc.

We use #ubuntu+1-maint on freenode.

Specifications

Schedule

• November
  • Colin Watson (confirmed)
  • Michael Terry (confirmed)
  • Mathieu Trudel-Lapierre (confirmed)
• December
  • Martin Pitt (confirmed)
  • James Page (confirmed)
  • Allison Randal (confirmed)
• January (overlaps with platform rally)
  • Colin Watson (confirmed)
  • Max Brustkern (confirmed)
• February
  • Barry Warsaw (confirmed)