Re: Dealing better with CD releases

[Gerfried Fuchs <rhonda@deb.at>]

	Hi!

* Steve McIntyre <steve@einval.com> [2009-04-15 15:36:57 CEST]:
> We then prune most of the old ISO images so we don't waste too much
> space - older images can be recreated in the future using jigdo if
> necessary.

 To the best of my knowledge that would depend on snapshot.debian.net
being functional because once we release we also prune out the old
packages that would be required to build the old images.

> We currently potentially have a window of a few hours of breakage, as
> the web pages that point directly to the old images stay around for
> quite a while. Even if they are updated directly in $VCS as we do a
> release, the website is only rebuilt periodically from cron.

 It's not that big of a deal to trigger a manual rebuild of the webpages
if one of the webmasters is contacted and around for the time, it
doesn't need to wait for the periodically rebuild from cron. Involving a
webmaster also solves the problems that we had at lenny release with
respect to not-tested commits resulting in build problems and not only
delaying the issue until the next periodically cron run but the one
after the problem got noticed and fixed.

> 2. Possible solutions
> 
>    a. Stop linking directly to the images, and go through a set of
>       symlinks instead. Potentially messy, and people may get mixed
>       sets. Probably difficult to set up on mirrors too?

 Yeah, symlinking from hell might solve the issue of broken links but
raise a lot of other issues indeed - I guess broken links are rather a
much lower issue than those.

>    b. Stop linking directly to the images, and go via redirects. Could
>       maybe be a central cgi, maybe even with intelligence to redirect
>       to good/close/fast/up-to-date mirrors. Could work, but needs
>       implementing. :-)

 Sounds like a path that would work very well; but yes, requires work.

>    c. Do things in stages:
> 
>       * Copy the old release to the archive area a few days before
>         release. Add a warning to users that a new build is due, and
>         they should be careful that their downloaded images are all
>         from one version.
> 
>       * Once that archive copy is live, update the links to point to
>         the archive copy and push the new website.
> 
>       * On the day of release, release as normal and update the web
>         pages in $VCS to point to the new release in "release". Remove
>         the "new build due" warning and add "new build just happened".
>         After the website is built, new users will see the new images.
> 
>       * A few days/weeks later, prune the images in the old tree under
>         "archive". No current pages should be looking here, so we're
>         just dealing with stragglers.

 Staging is usually a quite save approach but requires better
coordination which seems to have been problematic the last releases from
what I perceived. I though would be happy to be proven wrong. ;)

 So long!
Rhonda