[cut-team] Snapshots

[Anthony Towns]

On Wed, Aug 25, 2010 at 13:43, Joey Hess <joeyh at debian.org> wrote:
> Anthony Towns wrote:
>>     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?

AFAIK suites are defined in dak.conf by hand, so adding/removing
suites is a manual operation, and having dak's name for the suite be
something that doesn't need to change regularly is a win. Symlinks
otoh can be automated reasonably trivially.

> 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

That would require multiple new suites on ftpmaster (otherwise the
debs in 20100901 would be deleted from the pool without being removed
from the Packages file), which I'm assuming would be extra work for
ftpteam.

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

Having the symlink lag would likewise require more additional suites.

>> 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.

Hmm. Maybe we could ignore that -- if we build a CD from the CUT
snapshot, and install from the CD, then the testing symlink on the CD
should just point at the CUT snapshot anyway, and everything might
work ok.

If not, we're looking at doing a d-i image build against the CUT
snapshot, and uploading that, then building ISOs, which is probably
workable too, but means the ability to update the snapshot is much
more important.

>> 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?

I think it'd be best to assume we have to manually build them for
supported architectures, at least initially. Once we've proven the
concept, autobuilders can be made to start working on it too.

> 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.

The script will need to be changed to not redirect the suite from
testing-snapshot to testing-snapshot-proposed-updates, but otherwise
that should be fine afaics.

Cheers,
aj

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