On Thu, Apr 16, 2009 at 01:28:56PM +0200, Gerfried Fuchs wrote: > Hi!
Hey! >* Steve McIntyre <st...@einval.com> [2009-04-15 15:36:57 CEST]: > >> 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. OK. How long does it take for the web mirrors to update after a cron run? I'm thinking of *trying* to make all versions of the pages work for a while if we can... Yes, I know I'm being awkward. :-) >> 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. Yup, exactly. >> 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. Yup. >> 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. ;) This is what I'm going to try for the next few point releases, I think. How much effort would it be for the web team to make changes like this? -- Steve McIntyre, Cambridge, UK. st...@einval.com "C++ ate my sanity" -- Jon Rabone -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
