[cut-team] Snapshots

[Anthony Towns]

Hi *,

So here's a draft of how "snapshotting" should/might work in practice.
It's targeted at how it would work if we did it tomorrow, but I'll try
to add notes as to how "rolling" might affect it. I figure this is the
next step I'm interested in after the discussions so far, having now
had my little rocketry diversion in Colorado. :) I presume this should
go on the wiki if other people are happy with it. Comments
appreciated.

===
CUT snapshots
===

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

      debian/ dists/
          squeeze/
          squeeze-snapshot/
          testing-snapshot-20100901 -> squeeze-snapshot
          testing -> squeeze

The snapshot will be an exact copy of squeeze as per the date of the
snapshot, populated by:

    dak control-suite --list testing | dak control-suite --set testing-snapshot

[[[This may change to become a snapshot of "rolling" depending on how
that all works out. People doing daily or similar snapshots may just
name them testing-snapshot-YYYYMMDD and be mostly compatible, except
that there's actually four possibly different versions of testing each
day...]]]

We want some sort of installer-ARCH images for the snapshot. The
easiest thing to do would be to pull the current sid image, something
like:

    ln -s ../../../sid/main/installer-i386/20100722
squeeze-snapshot/main/installer-i386/current

or scriptable as something like:

    for arch in $ARCHES; do
        di_ver=$(find sid/main/installer-${arch}/current -printf '%l')
        ln -s ../../../sid/main/installer-${arch}/${di_ver}
squeeze-snapshot/main/installer-${arch}/current
    done

That should then allow for doing CD/liveCD/etc image builds,
distributed via cdimage.debian.org, somewhere like:

    cdimage.debian.org/debian-cd/
        testing-snapshot/
            $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.

It probably needs to be possible to directly update the snapshot, but
this ability should only be used rarely -- eg if the installer images
from sid don't work against the testing snapshot, or there is a major
copyright/patent problem or something. In general the procedures for
updating testing should ensure any snapshot 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-snapshot" 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/t-s-new/COMMENTS/ACCEPT.sourcepkg_ver to tell dinstall to accept
the update
     * testing-snapshot is updated in the next dinstall run

(COMMENTS/REJECT.sourcepkg_ver would reject a package)

This seems like minimal effort for the ftp team (only one additional
suite is needed, not two -- one for the snapshots and another for
proposed-updates to the snapshot suite), while giving enough
flexibility to the CUT team to actually be productive.

It would be nice to do release notes too, but I presume that's either
a prior version of the squeeze release notes captured in the snapshot,
or else a website getting updated, and shouldn't require any extra
setup.

Thoughts?

Cheers,
aj

-- 
Anthony Towns <aj at erisian.com.au>