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

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.

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:

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:

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:

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

Not served well right now:

Need to define functions for group but not necessarily the group

Divide functions into genuine duplicates and legitimate distinctions

Genuine duplicates:

Legitimate distinctions:

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

CategorySpec

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