Re: What has happened.
> > 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).
Well, I think I will answer the obvious question actually, because I think
(know) that things don't quite go as smoothly as you seem to expect.
As a perfect example, Steve just did a CD image creation run for 2.1_r2, which
in theory couldn't possibly go wrong, since almost nothing changed in the
archive between 2.1_r0 and now.
Well, in fact there were several problems. It seems that the sparc archive
had become contaminated with forward links into sid, and for some reason the
first source CD image ended up being over 650MB, so wouldn't fit on a CD.
[ Steve, how many attempts did you end up making before the whole set of
CDs was properly made ? ]
This didn't happen because Steve screwed up (as far as I know ;-)
It happened because minor changes in the archive can have serious an
unexpected effects on the resulting CD images.
If that's true when practically nothing changes between 2.1_r0 and 2.1_r2, how
much more likely is it that our first run at producing a CD will be broken
when the whole archive goes berserk around freeze time ?
> 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.
The way I see it is that the first cut of the CD will either be basically
OK,in which case the plan to do only one is just fine, or it will be fatally
flawed in some way, in which case persevering with it would be a little
foolish IMO.
Laying down rules in advance, that assume that everything is going to go
swimmingly, doesn't strike me as particularly realistic.
>
> > 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...
How about if new bugs are introduced by the fixes to packages that were
allowed into frozen solely to fix bugs in the initial CD set ? This has
happened before, so it will probably happen again.
How about if new important packages are allowed into ``frozen'' after we do
the first test CDs ?
> > > 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,
That's the way to go.
> or I can just FTP the entire official images. The former option
> requires more disk space, more time and more bandwidth
A little bandwidth the first time, yes, but much less bandwidth from the CD
servers, where it's scarce, and a little more bandwidth from a normal mirror,
of which there are many, and probably one that is much closer to you than your
nearest CD mirror.
I'm sorry, but if you are not in a position to either have a local archive
mirror, or a recent CD to start from, then you cannot expect to get copies of
the CD images via the net around release time.
> 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).
I don't know where you got that from, but if it was sunsite.org.uk you helped
to ensure that for two days after that our best mirror was off the air because
of the bandwidth spike the CD release generated.
It's not your fault, since that's why we try to get the CDs out to as many
mirrors as possible. It's just that encouraging it doesn't do anyone any good.
BTW why were you grabbing CD images then, anyway. If you're ferrying them
around on a laptop, why not just mirror the archive and do network installs ?
It's a lot quicker than grabbing CDs.
> 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).
Hm, that's true. mea culpa. I'll sort it out, once I work out a way of doing
it that doesn't break on every CD release.
Cheers, Phil.
Reply to: