Debian CUT/ snapshots/ implementation plan

CUT snapshots

A CUT release is a suite that is a snapshot of testing, with some minimal QA done on it. From that snapshot, CD images are built, and we can know that the installer will reliably work for users without day-to-day breakage.

Terminology

Since "snapshot" has some negative connotations, and we're doing more than just taking a snapshot and throwing it over the wall, we may use that term internally, but in communication with users, we refer to them as a "cut".

We might say "squeeze-cut-2010-09" or just "cut-2010-09" to unambiguously refer to a particular version.

The term "final cut" is reserved for the stable release. The terms "director's cut" and "extended cut" have no meaning currently. :) Continuing the film analogy possibly too far, testing's rolling updates are "dailies"

Layout

We'll introduce a new "cut" suite on ftpmaster, something like:

 debian/ dists/
     squeeze/
     testing-cut/
     testing-cut-new/
     cut-2010-04 -> testing-cut
     testing -> squeeze

The CUT will be (almost) an exact copy of squeeze as per the date of the snapshot, populated by exactly duplicating the current contents of testing.

(This may change to become a snapshot of "rolling" depending on how that all works out.)

Installer

We want some sort of installer-ARCH images for the CUT release. Since the version in sid installs testing, not the CUT, we will need to build new images and upload them specifically for the CUT, presumably after the CUT is made.

CD and DVD images

After installer images have been made and uploaded, this should then allow for doing CD/liveCD/etc image builds, distributed via cdimage.debian.org, somewhere like:

cdimage.debian.org/debian-cd/ cut -> cut-2010-04 cut-2010-04/ $ARCH/ live/ iso-cd/ ... install/ iso-cd/ ...

There should be jigdo images for all architectures, ISO CD and DVD install images for i386 and amd64, and ISO live CD images for i386, amd64 and any other architectures where live CDs work.

Bug fixes

It probably needs to be possible to directly update the CUT, but this ability should only be used rarely -- eg if the installer images from sid don't work against the CUT, or there is a major copyright/patent problem or something. In general the procedures for updating testing should ensure any CUT is almost entirely functional, and users should not be led to expect the same level of quality from CUT snapshots as they would expect from a stable release.

This probably depends on the ftpteam as to what works best, but duplicating the system for uploading to proposed updates might be a good approach. That would mean:

  • For updates, place "testing-cut" in the changelog instead of unstable
  • Updates go to ftp-master, and get put in a queue like queue/p-u-new, accessible to the CUT team but not users
  • CUT team creates a file named queue/cut-p-u/COMMENTS/ACCEPT.sourcepkg_ver to tell dinstall to accept the update (COMMENTS/REJECT.sourcepkg_ver would reject a package)
  • testing-cut is updated in the next dinstall run

Note that there's no autobuilder support for these updates (though there could be, one day).

CUT acceptance testing

Given any particular version of testing is obsoleted within about six hours, there isn't much time to do any significant testing before making a new cut, or to upload d-i images or similar. In order to make this work, while keeping the released cut "constantly usable" at the same time, an additional suite (testing-cut-new) will be needed. The process for creating a new snapshot will then be:

  • copy testing to testing-cut-new
  • build, upload d-i images for testing-cut-new
  • build CD images for testing-cut-new
  • replace testing-cut with testing-cut-new
  • empty testing-cut-new

If testing-cut-new turns out to have an unworkable collection of packages, testing should be fixed and a new copy taken, rather than attempting to upload fixed packages to testing-cut-new directly.

Security support

There aren't currently any plans for additional security support. Three options are available:

  • just use the CUTs directly -- security updates go from unstable -> testing (10 days) -> next testing-cut (3-6 months) -> your system
  • install the CUT and any updates from the testing security repo -- mostly same as previous
  • install the CUT then immediately start following testing -- unstable -> testing -> your system

Targeting security support for CUT may be feasible at some point.

ftp team notes

This seems like the minimal effort possible for the ftp team , while giving enough flexibility to the CUT team to actually be productive. What's required for the above is:

Initially:

  • create a new suite "testing-cut" in dak

  • create queue/cut-p-u (or whatever)

  • add "punew" support for it in cron.dinstall

  • give CUT team perms to edit COMMENT files in that queue

  • create a new suite "testing-cut-new" in dak

  • update d-i autobyhand to support d-i uploads for testing-cut-new, should be installed into testing-cut dir, with a "current" symlink created/updated in t-s-n

When a new CUT is started:

  • invoke "dak control-suite --list testing | dak control-suite --set testing-cut-new"
  • update testing-cut-new Packages/Sources if that's not part of cron.dinstall

When a new CUT is released:

  • invoke "dak control-suite --list testing-cut-new | dak control-suite --set testing-cut"
  • generate Packages/Sources/Contents files etc for "testing-cut" if that's not part of cron.dinstall
  • update d-i image symlinks, delete old d-i images
  • invoke "dak control-suite --set testing-cut-new
  • update cut-YYYY-MM symlink in dists/

The CUT team should be expected to keep the time between starting and committing testing-cut-new fairly brief (a couple of weeks at most), and the time between different CUT releases relatively small (no more than 9 months). If that doesn't happen, it's probably reasonable to consider CUT to no longer be maintained, and clean out the suites.

live team notes

generating live images for CUT releases are straight forward, if:

  • all images of our prebuilt image set can be generated if all packages are installable that are included in the respective tasks: {gnome,kde,xfce,lxde}-desktop, desktop, laptop, standard

    otherwise, if one of them is not, the respective image could be skipped for one CUT release and brought back for the next. but that's up to someone else to decide.

  • (just for completness, it should never be an issue anyway:) live-boot and live-config are working

optionally:

  • debian-installer needs to be working in order to have combined live and installer images (regardless if d-i is going to be used in live or normal modus).

  • (just for completness, it should never be an issue anyway:) debian-installer-launcher is working