PlusOneMaintenanceTeam

Differences between revisions 51 and 52
Revision 51 as of 2021-07-16 11:27:42
Size: 4694
Editor: ginggs
Comment:
Revision 52 as of 2024-01-26 09:07:43
Size: 4695
Editor: fheimes
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
There is no requirement to sign up anywhere to do archive maitenance work. Vanguards are simply a point of contact, a knowledgeable developer who advertises an "open door" policy to answer questions, sponsor patches, etc. There is no requirement to sign up anywhere to do archive maintenance work. Vanguards are simply a point of contact, a knowledgeable developer who advertises an "open door" policy to answer questions, sponsor patches, etc.

+1 Maintenance Team

The +1 Maintenance Team ensures that the development release stays in an installable state and that the archive is usable throughout the cycle.

Furthermore, members of the +1 Maintenance Team can additionally sign up as "+1 vanguard" to serve as a point of contact for developers wishing to coordinate +1 maintenance work, who need patches reviewed or packages sponsored.

There is no requirement to sign up anywhere to do archive maintenance work. Vanguards are simply a point of contact, a knowledgeable developer who advertises an "open door" policy to answer questions, sponsor patches, etc.

Goals

Primary

  • Maintain archive-level quality throughout the development cycle to minimise roadblocks for people developing features for the next release, and to ease the preparation of milestones
    • Migration of packages from -proposed
      • first priority are packages involved in transitions (multiple source packages must migrate together to keep the archive installable).

      • second priority is to work on packages in age order, to address neglected packages in universe that have gotten stuck
    • 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

Any developers or prospective developer can sign up to do +1 maintenance work; the only requirement is to work on the general health of the development series.

+1 vanguard is a voluntary rotational team; interested developers can sign up for a "shift" as they feel appropriate, by updating topic in #ubuntu-devel (use @pilot in or @pilot out to update the topic) or otherwise making their availability known. A regular vanguard schedule can be arranged (if this is your wish, please sign up below).

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

We use #ubuntu-release on Libera.Chat and highlight the call sign plusone.

Specifications

Vanguards

Please sign up here if you are interested in being a vanguard:

  • cyphermox
  • tsimonq2

PlusOneMaintenanceTeam (last edited 2024-01-26 09:07:43 by fheimes)