LucidMOTU

Summary

The current archive reorganization plan does not address development and maintenance work in the unseeded package set. There is also a desire, at least among some MOTUs, to continue a distinct social/technical identity for people working in this area. See the tech board meeting minutes for November 3, 2009 for details.

Release Note

No changes to existing release communication are required: the implementation of this specification will largely be invisible to end-users, and where not, largely represents a continuation of pre-lucid practices.

Rationale

With the advent of ArchiveReorganisation, the component-based upload permissions policy is due to change (eventually!), and the definition of MOTU needs to correspondingly change to reflect the lack of a universe component, given the desire among some subset of MOTU to provide a continuance of the social/technical identity of those working in this area.

Assumptions

  • There exist a sufficient number of existing MOTU who self-identify as MOTU to maintain a coherent social community.

Design

The MOTU role will be redefined from developers responsible for packages in the universe and multiverse components to developers responsible for the long tail of packages not explicitly maintained by other groups of developers. (A snappier version of this would be welcome!)

The existing MOTU team includes a number of functions within the Ubuntu Development community. These functions are to be analysed, with the target of either centralising or distributing any functions that are not unique to the MOTU role.

Definition of responsibility

MOTU shall be responsible for the set of source packages that generate no binary packages listed as dependencies, build-dependencies, or recommendations of any of the packages listed in any of the seeds managed by groups to which the TechnicalBoard has granted an explicit separated upload permission.

MOTU shall share responsibility for any packages within this set that are also maintained by a person or group granted per-package upload rights to the specific packages concerned (as differentiated from those groups that have been explicitly granted the right to manage their own seeds, and consequently their package sets).

MOTU Function Analysis

The following functions were identified in the UDS session on this topic. In each case, they have been classified as one of distribute, indicating that the function should be distributed across *all* Ubuntu Development teams, preserve, indicating that the function should remain a function of MOTU, or centralise, indicating that the function should be merged with the similar function in other Ubuntu Development teams into a single central team for all Ubuntu Development.

  • Developer Training : distribute
  • Entry point for new packages : distribute
  • "Debian-QA"-like function : preserve
  • Code Review : distribute
  • Release Management : centralise
  • Update Candidate review : centralise
  • Long-tail maintenance : preserve
  • Developer approvals: distribute
  • Dispute Resolution : preserve

Implementation

Distributed Functions

Documentation on the responsibilities of delegated Ubuntu Development teams shall be created, indicating the expectations of such bodies. This documentation shall include that these teams have the following responsibilities:

  • Training new developers in the area for which the team is responsible
  • Reviewing new packages for inclusion in Ubuntu where the packages would otherwise fall within the team's responsibility
  • Reviewing proposed code changes to packages maintained by the team
  • Approving new developers to join the team (if so delegated by the Technical Board)

Centralised Functions

The motu-release and motu-sru teams shall be merged into the ubuntu-release and ubuntu-sru teams, and all documentation on associated processes and procedures updated to reference the centralised team.

Preserved Functions

MOTU shall continue to fulfil the following functions:

  • "Debian QA"-like function, a lot more packages though ("terraforming")
    • But 2 kinds of packages:
      • packages with someone interested in maintaining it in Ubuntu
      • packages without anyone particularly interested
    • FTBFS, NBS ("not built from source"), classes of similar bugs
    • position this responsibility within the mandate of the release team
    • change nothing; MOTU continues to take care of this in the long tail, and is likely to be in a good position to notice issues elsewhere
  • On-ramp for generalists
  • developer approvals (restricted to within MOTU)
  • dispute resolution (restricted to within MOTU)
  • long-tail maintenance (more shallow characteristics)

Upload Permissions

The Permissions Model shall be adjusted such that Soyuz is aware of the set of packages to which MOTU shall be granted upload permission, and such permission granted. (It is not required that this list be explicit; indeed, it would be simpler to manage it if Soyuz calculated it implicitly, on the fly.) In the interim, MOTU shall continue to be granted upload to the packages in the universe and multiverse components, so long as they continue to exist.

Future of MOTU Council

MOTU Council shall be preserved to assist with governance of MOTU. MOTU Council shall remain responsible to the Technical Board, Community Council, and Developer Membership Board, and be selected from among MOTU by MOTU.

MOTU Council shall be explicitly granted the following responsibilities:

  • Oversight of MOTU policy development
  • Dispute Resolution within MOTU and related to packages maintained by MOTU

Any other responsibilities historically granted to the MOTU Council shall revert to the Community Council, the Technical Board, the Developer Membership Board (in the case of MOTU membership review and approval), or the MOTU team as a whole.

Identity Communication

The MOTU identity shall be communicated as non-exclusive, such that individuals who are MOTU may also be other types of Ubuntu Developers (or other things entirely). There shall be no requirement that any Ubuntu Developer choose to be MOTU, nor participate in MOTU activities, although all Ubuntu Developers shall be encouraged to participate.

Unresolved issues

This specification does not provide any definition for "core-dev", nor any guidance on other related changes supporting ArchiveReorganisation

BoF agenda and discussion

Functions of the MOTU team

  • Train new developers
    • express gratitude to MOTU for doing a good job at this
    • affirm this as a responsibility of Ubuntu developers in general
    • position this responsibility within the general mandate of DMB
    • delegated to various other teams
    • including the team which takes on MOTU package maintenance function
  • Entry point for new packages
    • needs to be unified/standardized across the archive
    • this is ultimately a tech board responsibility
    • somebody needs to own responsibility
    • punt to TB
  • "Debian QA"-like function, a lot more packages though (terraforming)
    • But 2 kinds of packages:
      • packages with someone interested in maintaining it in Ubuntu
      • packages without anyone particularly interested
    • FTBFS, NBS ("not built from source"), classes of similar bugs
    • position this responsibility within the mandate of the release team
    • change nothing; MOTU continues to take care of this in the long tail, and is likely to be in a good position to notice issues elsewhere
  • REVU, and other similar review processes
  • On-ramp for generalists
    • Handled above
  • Mentoring
    • Handled above
  • Social identity
    • Need name, but does it need to change?

Not served well right now:

  • People who want to contribute new applications to Ubuntu

Need to define functions for group but not necessarily the group

Divide functions into genuine duplicates and legitimate distinctions

Genuine duplicates:

  • -release
  • -sru
  • -sponsors
  • developer approvals

Legitimate distinctions:

  • dispute resolution
  • long-tail maintenance (more shallow characteristics) The entity that does dispute resolution (e.g. the MC now) needs to have both institutional and social legitimacy. Institutional legitimacy needs to be delegated from TB/DMB. Social legitimacy is conferred by selection from the community (i.e. elections).

Action: ScottK and cjwatson to document proposal and present to TB


CategorySpec

Specs/LucidMOTU (last edited 2010-02-02 15:24:48 by cjwatson)