Re: What has happened.
On Wed, 7 Jul 1999, Philip Hands wrote:
> "J.A. Bezemer" <costar@panic.et.tudelft.nl> writes:
>
> > Therefore, it might be wise to make one (and only one) beta (="pre-final")
> > set of images/CDs.
>
> This almost certainly won't work, I'm afraid, since the one image we
> produce is bound to be fatally flawed in some way,
Let me ask the obvious question: why ? No, don't answer. Only keep in mind
that things have to be production-ready at _any_ time if you want things to go
smoothly. And that's what I like about the current slink-cd/debian-cd/xxx-cd
developments: if everything is sorted out, it should only need an up-to-date
mirror of the debian ftp archive and a "press the button" to generate good (as
in "bugless") CDs. Without need for any second version (if it weren't for
changes in the doc/ dir).
And then, you're only going to mail one "beta" set of CDs to testers. So it's
of course also possible to give only one set the "official beta" designation
and call subsequent sets only "testing 03" sets etc. -- just to avoid the
confusion of "who's talkin' 'bout what?" And then mark those sets clearly as
such (also _in_the_directory_of_ FTP mirrors and the like), because all those
different "slink1.raw" images and uncountable "md5sums" files were causing
much confusion to `outsiders' like me.
> Anyway, with rsync it's no great hardship to download a new image, and
> if the images change during the download you just need to check the
> md5sum at the end, and keep rsyncing until the md5sums match.
Okay, but I don't want to endlessly keep burning "the latest beta" CD sets.
What I want is just one beta set to test things etc., and after that one
Official CD Set. Otherwise I'll waste my time burning instead of testing...
> > Make it available on only one (fast) FTP site and announce
> > it properly, and possibly burn some CDs and mail them to testers.
>
> FTP/HTTP is pretty much useless for CD image downloads and certainly
> shouldn't be encouraged, since you have to actually download the whole
> image.
Good point. Only you might be thinking too highly of people like me. I don't
know if my situation is unique, but let me describe it briefly.
I don't have a permanent Internet connection for this kind of thing. I merely
have a laptop with a big disk to take large files home from the university.
Also I don't maintain a (private) Debian ftp mirror. So to get CD images of a
new version (say 2.2r0), I can either create a new (temporary) private FTP
mirror, make "unofficial" images myself and update to the official ones using
rsync, or I can just FTP the entire official images. The former option
requires more disk space, more time and more bandwidth -- so the latter option
seems the logical choice. And that seems to work well in my case; I got the
2.1r0 i386 Bin and Src images at Saturday night prior to the official release
on the next Monday, at speeds of 200-300 kB/s (FTP using wget).
If you make pre-final images available in a _clear_ and _documented_ way,
distributors can download these (fully) at ease and possibly slowly, and then
use a quick rsync to update to the official ones. But then that procedure
should be documented fully and correctly at _all_ times (which certainly was
not the case for 2.1r0 -- and STILL!!! the MD5SUM links on
http://cdimage.debian.org/ are broken!!! AFAIK they haven't been correct
since 2.0r3).
Regards,
Anne Bezemer
Reply to: