[cut-team] Snapshots

[Joey Hess]

Anthony Towns wrote:
> 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

Would it really be "--set squeeze-snapshot" ? (Don't see where the
string comes from otherwise.) And is the symlink then made manually?

Following Drake's points about the usefulness of being able to keep
and examing multiple snapshots in order to pick the best one, could
it be flipped like this instead? --

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

(With the symlink probably being made on eg, 20100914.)

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

Except the current sid d-i image installs whatever suite testing
points at.

To change d-i to install a suite like testing-snapshot, one way is
to do a custom build of debian-installer, modifying debian/changelog to
specify the suite it should build against (and that d-i should download
udebs from); and also modifying build/config/common to set DEBIAN_RELEASE
to the suite to install.

(Another way would be to modify existing images, eg changing the
/etc/udebs-source and /etc/default-release files inside them to specify
the suite to use. But this would probably be more bother than it saves.)

> 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

Would uploads to this queue need to be autobuilt, or would we manually
build them for supported arches?

This queue could be used to get d-i images uploaded into the suite. I
assume the "auto byhand" stuff that handles regular d-i uploads would
also work here.

> Thoughts?

Thanks for making it so concrete.. 

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/cut-team/attachments/20100825/f6da6493/attachment.pgp>