GrumpyGroundhog

Revision 2 as of 2005-04-24 05:12:22

Clear message

The Grumpy Groundhog

Status

Introduction

The Grumpy Groundhog Project aims to produce a crack-of-the-day set of packages, in a release called "grumpy". Grumpy will never actually be released, it will be in a state of perpetual development, representing the very cutting edge of upstream and distro packaging. The packages in "grumpy" will be produced automatically by combining the very latest daily upstream (from CVS, SVN, Baz, BK or Arch) with the latest distro patches (from the current development release of Ubuntu, or specifically produced for grumpy to address build issues).

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. By offering the Grumpy Groundhog release, Ubuntu provides those developers with a ready source of daily built packages containing the very latest upstream code.

Regular and continuous building of new upstream code will allow cutting edge developers to keep track of changes in the upstream codebase that might affect the distribution in due course. For example, since these packages will be auto-built with the very latest compiler code, failures in the build cycle may indicate changes that are required to keep upstream compatible with the next release of the build toolchain. Should we make grumpy available on multiple architectures, we would provide an early warning system of porting issues with new daily upstream code.

Scope and Use Cases

Grumpy is designed to be a snapshot of every package in Ubuntu built against its crack-of-the-day upstream code.

  1. Frank is an Ubuntu developer, and particularly interested in the Apache
    • package. He would like the apache2 package to be part of Grumpy, so he can monitor daily snapshot builds of the package. He notices that Apache2 upstream is being published in Baz format in the Launchpad, so he sets up Apache2 for building in Grumpy. Every day, Launchpad attempts to build an apache2 package using the latest upstream SVN code (as imported and published in Baz format) together with the current set of patches in use for Grumpy. If the package successfully builds, it is published in grumpy.
  2. Harry is an end-user of Ubuntu, not a hard-core developer but
    • nevertheless interested in what's going on in the Apache project. He uses the latest stable Ubuntu release for his desktop, but out of curiousity he has installed the apache2 package from Grumpy. His apt sources have Grumpy pinned low except for apache2, so the only package on his system from Grumpy is apache2, everything else is from Hoary. On a regular basis he updates his system and gets the latest apache2 package with crack-of-the-day upstream code. The version of the package includes a build date identifier, so he knows when the package was built.
  3. William is interested in whether or not the upstream apache2 code will
    • build with the latest GCC, so he subscribes to the package build notifications for apache2 in Grumpy. Every day, when Launchpad assembles and builds the latest apache2 Grumpy package, he receives a log of the results of the process. He will see the results of the attempt to produce the source package, and any failures patching the upstream source with the current set of grumpy patches. If the source package is successfully constituted he also sees the log of the build attempt, and an indicator of its success or failure.
  4. Frank notices that apache2 did not build in Grumpy today. He looks over
    • the log and sees that one of the distro patches failed to apply, so he updates that patch using Baz and HCT to resolve a conflict introduced by yesterday's upstream commits. He satisfies himself that the updated package builds for him locally, and commits the updated patch into the Grumpy repository. Tomorrow, the package will likely build correctly.

Implementation Plan

Data Preservation and Migration

Packages Affected

User Interface Requirements

Outstanding Issues

  • What social issues might arise when we bring Grumpy on stream? Might it
    • be hard to get developers focused on the current frozen release when they can get their fix of daily crack from Grumpy? Might some people want to try and run end-to-end grumpy, or is nobody actually that extreme?
  • How do we deal with build tool updates? Should we attempt to rebuild
    • every package in Grumpy when we update GCC? Should we attempt to build every package every day with the latest GCC?
  • Should grumpy have packages for unstable branches that are not
    • actually part of the current development distrorelease? For example, should it have a gimp2.5 package if the current stable distrorelease just has gimp2.4? Or should it have both gimp2.4 (updated for any new patches to the upstream stable release) as well as gimp2.5 (representing the latest upstream unstable branch)?