The Grumpy Groundhog

Status

Introduction

The Grumpy Groundhog Project aims to produce an "Ubuntu-derived" distribution containing a crack-of-the-day set of packages. This distribution will never actually be released, instead it will be in a state of perpetual development, representing the very cutting edge of upstream and distro packaging.

Rationale

Upstream development in the open source world moves at a tremendous pace. Many developers like to keep up to date with specific upstream products, but the work involved in building from CVS every day is substantial. With The Grumpy Groundhog Project, Ubuntu provides those developers with a ready source of packages containing the latest upstream code.

These same packages will allow cutting-edge developers to keep track of changes in the upstream codebase that might affect the distribution later down the line. For example, these packages can be auto-built with the latest compiler and toolchain packages to test compatibility with the versions that may be used for the next release of Ubuntu.

The system can also be used to provide early warnings of porting issues on the different architectures the builds will be run for.

Gentoo has packages such as emacs-cvs which update, build and install a checkout from HEAD. Perhaps something can be applied from the way they do this or the consequences.

Scope and Use Cases

Initial import of upstream repositories and ongoing import of new commits is covered by the BazaarImports specification.

Auto-building of packages is covered by the Launchpad AutoBuildManagement specification.

HCT user interaction is covered by the HctTrainingAndFeedback specification.

HCT merge processes are covered by the HctMergeProcess specification.

Implementation Plan

Archive

Grumpy will be implemented as a separate distribution to the ordinary Ubuntu one, for the following reasons:

It's recommended that the distribution be hosted on an alternate machine entirely to the Ubuntu distribution, for example daily.ubuntu.com. The archive will be set up so that APT pins it lower than installed packages by default, as with the Debian experimental distribution.

Build Daemons

Grumpy will use the existing build daemon network, and simply use alternate chroots to build the packages in. This allows us to immediately scale to all architectures we have build infrastructure for, and allows us to use the existing Launchpad build system.

The "latest toolchain" chroot can be updated by a daily dist-upgrade within it, perhaps simply from cron.

Successful builds will be uploaded to the appropriate part of the archive.

Source Assemblers

The simplest way to assemble the source packages that we wish to build is to use the existing build daemon network and an alternate chroot containing HCT.

  1. Obtain desired base source package with hct source

  2. Pull changes from CVS or other distribution with hct pull

  3. Update changelog and control file.
  4. Assemble new source with hct assemble

  5. Upload to archive
  6. Build system automatically triggered

The changelog and control file will need to be updated in a similar manner to the existing merge-o-matic:

The version number or changelog marker could also be used to indicate to a bug reporting tool that it's a grumpy package, and not part of the main distribution for reporting purposes.

If the assembly is unsuccessful, for example because the pull or patch application fails, no source will be uploaded so no build will be triggered.

The result of the assembly will not be committed anywhere, and the manifest not added to Launchpad. This avoids causing future conflicts, and is cheap to make yourself.

Custom Assembly

In order to support the SoyuzDynamicBuilds specification, the assemblers will take custom orders. This will be a queue containing the following information:

On completion of assembly and build, the requester is notified and rather than being uploaded into the grumpy distribution, the result is uploaded into their personal apt archive.

User Interface Requirements

We should try to fix packages to make downgrades work.

Perhaps people should be advised to install into a chroot or similar setup?

Notification

By using the existing build daemon system, logs of both the assembly and builds will be available. These can be watched for failures and e-mail notifications triggered if desired. Notifications will only be permitted to people and teams registered within Launchpad.

Web pages could be produced to indicate the overall status of individual packages or the entire distribution. Potential examples for this reporting could include a web-based waterfall of test builds and status, such as http://build.samba.org/ or the existing buildbot system.

Another option for notifications would be the filing of bugs within Malone.

Failures are inherently transient and the bug could be fixed between test builds. For this reason, any notification should take this into account. A web-based waterfall should return to green once a build has completed and an opened Malone bug should be automatically resolved and perhaps a reply to the e-mail sent to say its all fine now. We should make sure e-mails are not repeatedly sent for the same failure.

Exclusions

We may need the ability to exclude certain packages from the distribution, for example GNU have indicated they prefer people to not make CVS builds of emacs available.

On the other hand, some packages such as mplayer, encourage people to build from CVS HEAD. These might be good demonstrations of grumpy power.

Security Concerns

Since the code at the top of HEAD is even less trusted than regular releases we have to be careful to build it in a protected chroot, possibly eventually in a virtual machine. Even without malice, it's not unheard of for Makefile or packaging bugs to try rm -rf / or to kill other processes.

Outstanding Issues


CategoryUdu CategorySpec

UbuntuDownUnder/BOFs/GrumpyGroundhog (last edited 2008-08-06 16:25:21 by localhost)