Ubuntu Wiki

See ArchiveReorganisation for overall rationale.

Upload permission changes

Rationale

For full-scale Ubuntu derivatives with their own maintenance teams, adding additional upload permissions to individual packages is likely to be inadequate, or at best only workable with a substantial amount of busy-work and automation. Furthermore, it does not solve the problems of expressing support from entities other than Canonical (such as development teams) or of indicating to users which of a set of packages is most likely to work best with the other packages already on their computer.

Good examples of the scaling problems here are Ubuntu Studio and Mythbuntu. Ubuntu Studio has 141 unique source packages in Ubuntu 8.04 LTS (i.e. packages that are part of Ubuntu Studio, but part of no other "set"). Mythbuntu has 124. Kubuntu and the KDE4 remix have 115 between them. Xubuntu has 65. In each case, it makes complete sense for each development group to be able to work on their set of packages, and neither the MOTU community nor the core developer community are likely to be as qualified to do so simply because they largely do not use them directly. Maintaining independent access control lists for each of these would quickly spiral out of control.

As the first phase of broader reorganisation work, we will shift to a new permission model which handles these kinds of problems in a more scalable way. This also begins the process of reducing process, training, and other organisational duplication between the core developer and MOTU communities.

Nomenclature

Seeds are aggregated into seed collections. For example, "Kubuntu Jaunty desktop" is a seed; "Kubuntu Jaunty" is a seed collection.

Seed collections are exposed only to developers, and are subject to reorganisation.

Packages are grouped into package sets: "core", "Ubuntu desktop", "Ubuntu server", and "Kubuntu" are expected to be examples of package sets. In the future, package sets will be exposed to users via package management (see ../Components), and thus care should be taken when rearranging them. While package set assignments are likely to be generated based on seeds in many or even most cases, the distinction allows us to shield users from rearrangements made purely for the convenience of developers.

A package may be in more than one package set.

Each package set has associated access control (upload permissions and queue administration). In addition, a default set of access controls is available for packages not in any package set.

For the purposes of permissions, package sets are collections of source package names. In future they will also need to be able to express collections of binary packages.

General developers are those with access to upload any package in the archive not in a restricted package set (q.v.).

A package set may be restricted or not-restricted. Restricted package sets grant upload access only to a subset of developers, and not to the developers who can upload to any other non-restricted package set containing the package in question. This will allow giving people full upload permissions earlier, while still being reasonably conservative with certain packages (such as, perhaps, glibc and linux) where changes have extremely widespread knock-on effects and require unusual levels of experience. It is likely that restricted package sets will be defined by a small list rather than by a seed.

Design

The Technical Board, and where appropriate their delegates, will be able to manage package sets by adding or removing packages from them, and will be able to assign upload privileges at the level of package sets. (This might be implemented either inside or outside Launchpad, although an external implementation would be rather slow; work on this Launchpad feature is currently in progress and we expect that it will be ready by the time we are ready to use it.)

The initial package set assignments are expected to be as follows:

• Packages in the "platform" seed collection are assigned to the "core" package set, for which upload access will be granted to general developers.

• Packages in a single seed collection are assigned to the usual package set associated with that seed collection, for which upload access will be granted to general developers and to the team owning that package set (normally, the same team that can commit to the seeds).
• Packages in more than one other seed collection are assigned to all the associated package sets. However, archive administrators are expected to investigate packages that want to move into this state, and may consider moving them into the "core" package set if they are in fact important central packages on which many other things depend.
• Unseeded packages will be in no package set, and access to them will be governed by the default access control for Ubuntu, which will grant upload access to general developers. (It looks a little odd to have this require the same level of access as the "core" package set. The different package sets will be required later in order to preserve things like ogre model and the ability to produce working partial mirrors, and in practice this models the "broad and shallow" type of developer quite well.)

Additional uploaders may be added in any of these cases in the usual way.

The initial set of recognised package sets will be: Ubuntu (desktop), Ubuntu (server), Kubuntu, Ubuntu Education Edition (formerly Edubuntu), Ubuntu Mobile, Xubuntu, Mythbuntu, and Ubuntu Studio. The addition of further package sets will require the authorisation of the Technical Board, as that amounts to a mass delegation of the ability to confer upload authority.

While the initial set of package sets correspond to installable CD builds ("flavours" of Ubuntu), this is not required, and more fine-grained packages may be added as time goes on.

Package sets may easily be made to correspond to seed collections, and this should be the default assumption when using package sets for access control since seed access control operates at the level of seed collections. In principle a package set could also correspond to a smaller list of seeds within a collection, but access control issues should be given careful consideration.

A package set may also correspond to a small list of packages not related by dependencies: this might be useful as a short-cut to give a group of developers upload access to all the games in the archive. However, remember that package sets are ultimately intended to be exposed to users by means of package management. Consider whether a seed would be appropriate for management purposes, and consider other possibilities.

Note that stable release updates are a separate dimension, always requiring approval by archive administrators; the restrictions that apply to them are unaffected by this specification.

Resolving upload permissions

The rules for resolving the upload permissions that apply to a given source package will be as follows:

• If package X is a member of package sets A, B, C, and D where C and D are restricted, then the set of valid uploaders is the union of those with permission to upload to C or D.
• If package X is a member of package sets A, B, C, and D, none of which are restricted, then the set of valid uploaders is the union of the generalists with permission to upload to Ubuntu as a whole together with those with permission to upload to any of A, B, C, or D.

Uploads by people without the appropriate permissions will either be rejected or queued for review by those with upload permissions (depending on Launchpad implementation status).

Technical Board considerations

The Technical Board owns this process, including by default:

• ability to create new package sets
• ability to mark package sets as exclusive
• ability to add and remove packages from package sets
• ability to grant access to the packages in any package set

The Board may delegate any or all of these powers as it sees fit, and will mediate any disputes that arise.

Granting upload access to a team implies that the administrators of that team will be able to grant upload access to additional developers. As such, the Technical Board should take care when doing this.

Most new package sets should probably initially grant upload access either to a set of individual developers, or to a team owned by the Technical Board.

Community factors

This specification clearly has a significant impact on the role of our existing developer teams. Most noticeably, it is expected that the ubuntu-core-dev and motu teams will effectively be collapsed into a single team, provisionally entitled simply "Ubuntu Developers". Members of this team will have upload rights to all packages in Ubuntu, with the possible exception of a small number of "restricted package sets" determined to require greater experience. We expect that the union of all such restricted package sets will be substantially smaller than the current "core".

As part of the transition to this new layout, we expect to talk to existing developers to determine whether they need and want access to the whole archive, or whether their work is strongly focused on a particular area and can be represented by access to a particular package set or sets.

There is an obvious danger that the development teams might become fragmented as the result of more teams with upload access to particular package sets. We will need to be careful to ensure that communication remains strong. We will also need to balance the presentation of "promotion" to increased access levels with the reality that many highly competent developers are only interested in a narrow area. Anyone with direct upload access to any part of the archive, which should generally be accompanied by an interest in and commitment to Ubuntu as a whole, should be regarded as an Ubuntu developer for the purposes of "social status"; for example, all such people should be able to vote on appointments to the Technical Board.

[FIXME: There is a conflict between "Ubuntu Developer" as the team with upload rights to the entire archive, and this social meaning of "Ubuntu developer". Resolve this.]

FIXME: Transition problem raised by Scott Kitterman: what do we do with people determined during the transition not to be ready for full upload permissions, but who don't have a particular narrow interest?

Launchpad requirements

Launchpad needs at least the following extensions:

• Upload and queue administration permission sets should exist, and be editable through the Launchpad API, for each package set, and there should be default permission sets for packages not in any package set.
• Launchpad should interpret these permission sets in the manner described above ("Design", and the note about restricted package sets under "Nomenclature").