HctPackageCollaboration

Package Collaboration with HCT

Status

Introduction

This specification describes the workflow for people collaborating on a source package in Ubuntu using the HCT; only features in the 1.0 release planned during the Breezy development cycle are considered.

Rationale

Many, if not all, packages benefit from being maintained by a team; rather than a solitary individual. By bringing different expertise to the problems, the team can tackle them faster and with more efficiency.

HCT, as the Ubuntu source management tool, should not only allow teams to use it to work on a package but encourage and help them to do so.

Scope and Use Cases

One of the primary use cases is the Kernel team, who work on the kernel collaboratively adding and modifying patches. Some of the work they perform as a team:

  • Adding new patches, often taken from upstream, other distributions or locally authored.
  • Updating existing patches with new released changes
  • Removing patches that are no longer relevant, or found to cause more problems than they fix
  • Test builds and runs on all architectures
  • Release prepared after testing and uploaded to the distribution.

The features of being able to pull/steal new patches and updates to existing patches are outside the scope of the 1.0 release, however these use cases can be addressed in the 1.0 release by the ability to add and share patches; the developers can simply maintain them the traditional way (by applying diffs).

Work Flow

Below we document the work flow that a team member or leader would go through with HCT for a team-managed package.

Team Creation

The first step towards team management is to create a team, and tell Launchpad about it. This can be done from the web application in the usual way. There could be a "Team Ubuntu" for packages managed by the entire distro team.

The next step is to get the source for a package the team wishes to manage and make a shared team copy available; this will be accomplished with two commands. 

$ hct source our-package
$ hct publish --bound our-package teams/ubuntu

The first is the usual command to get the source package, the second is a variation on the publish command; we give a destination for the publish (teams/ubuntu) and give a --bound option that tells HCT that commits should be made available to the team and updates pull from the team.

The team archive and branches will be hosted on the SuperMirror and accessed through the sftp server.

Getting the Source

Other team members will need to get this shared repository, and work within that to be a part of the team. HCT will support fetching packages that belong to teams: 

$ hct source people/ubuntu-team/our-package

This simple, usual command is therefore sufficient to get the team-managed version. The version in the distribution can be retrieved using the traditional URL form: 

$ hct source /distros/ubuntu/our-package

We may in future allow for one of the packages-under-development to be designated as the "head" of the package for the distrorelease. This would allow us to provide a simpler URL to get the current-development-version of the package at a URL like: 

$ hct source ubuntu/netapplet/+dev

Working on the Source

The source to the package can be worked on in the normal way, as if the package was managed by a sole team member.

Sharing with the Team

Because the local branches are bound to the team-managed package, changes can be sent to the team simply by committing them: 

$ hct commit

And changes made by team members can be taken by simply updating: 

$ hct update

Releasing

One (or possibly more) team members would act as a release manager, this need not be a position but simply whoever happens to be around to make a given release. Their job is simply to update their branch, manually check the various patches and reject any they don't wish to include, and publish the source into the distribution. 

$ hct update
$ hct publish ubuntu

Launchpad will see this publish attempt and perform the necessary work to build the package. There's nothing in this specification that prevents Launchpad from performing test builds of the shared team repository.

Implementation Plan

HCT:

  • Add concept of binding to Manifest

  • Add bound/unbound flag to SourceTree

  • Add Manifest URL to SourceTree

  • branch, publish, update and source-wide commit commands will need to be implemented

Banzai/Launchpad:

  • Check for a bound manifest of the same id when retrieving manifest, prefer over original

  • Add link between Manifest table and Team, probably through extending the magic SourcePackage

Outstanding Issues

  • Permissions; who has permission to commit to a team archive, and who has permission to publish into the release. If you don't have permission to commit, this could automatically break the bind and we could default to all packages being bound (even distribution ones). This is a Launchpad-wide issue.

  • Personal APT Repositories; the location and methods of the published source and binary packages is outside the scope of Launchpad 1.0, and not yet decided. This is also a requirement for SoyuzDynamicBuilds.

  • What triggers automatic package building and testing, and how do we display the results of them? This will be addressed by GrumpyGroundhog.

CategoryUdu CategorySpec

UbuntuDownUnder/BOFs/HctPackageCollaboration (last edited 2008-08-06 16:27:22 by localhost)