Hi, I've been a buildmaster making deliveries for commercial products in the past and religiously followed a "build-&-install-clean-and -test-before-delivery" method. (See summary at end.)
<start ramble> In this case it would map to: create a totally brand new install image (i.e. the bits that the CD people will pick up. This set of bits (packages hierarchy) will be totally private and locked down--no one has access except for your analog of buildmaster and the people making a pick-up...if that's how the hand-off works. Your buildmaster then does a full install from these bits onto a "blank" machine--i.e. does the install the way a customer (end-user) will. She then runs at the very least some "heartbeat" tests on the freshly installed machine to verify not only that the install from these packages goes smoothly but that it runs sensibly afterwards. Of course there are a zillion permuations for installation so you pick two: a sensible minimum and a full-blown everything. You don't let the CD people take delivery until you've verified what you're handing over. It's fine for john-and-mary-user to pick up bolluxed packages from your experimental tree or to copy them into the wrong part of the their tree--they'll get it sorted out eventually, but when you're delivering to a release (and that's exactly what a CD is--it carries a very high impression value on the recipients) you deliver only a certified set of bits--or you look like an incompetent fool whose stuff is probably trash. The quality of the delivery reflects on the perceived quality of what is delivered (if you follow that ;) The has the following beneficial results: you know *exactly* what you're delivering; the clean install and verification has the result of the buildmaster filing bugs against the install procedures until they're simple and clean enough to meet ease-of-use expectations; you get high quality snapshots that you can freeze and post for download access; you get a reputation for quality bits in a quality delivery. Too expensive, you say? Not really. It takes one or two spare machines to do the installs on. The tests can be run over a period of two or three days: launch the install and go to bed. Launch the heartbeats and go to your real job. <end ramble> Hope these thoughts are of some value. Maybe you're doing all this already... Summary: don't let a CD presser pick up at their convenience: deliver at your own (which will have to conform to their schedule, of course.) You're responsible for what you deliver--they're responsible to faithfully reproduce what you point them at. You might be responsible to verify a master CD before it goes to press. Regards--and thanks for a fine distribution! --emk > Date: Mon, 12 May 1997 12:49:33 -0400 (EDT) > From: Francis Swasey <[EMAIL PROTECTED]> > X-Sender: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > cc: [EMAIL PROTECTED], debian-user@lists.debian.org > Subject: Re: InfoMagic's new LDR > Resent-From: debian-user@lists.debian.org > > > > On Mon, 12 May 1997 [EMAIL PROTECTED] wrote: > > > > I wonder, is it time to request they stop distributing Debian? > > > > > provide a consistency check for complete CD's, so that companies like > > InfoMagic can easily check what they press. I have the impression the > > Eric, I suspect you are correct. I do have a tendancy to over-react to > bad situations. What kind of consistency check would we need to > provide? Something to read the Package file and verify that all packages > were there and also read all the directories and verify all packages were > listed in the Package file? Would something like that be enough? > > Frank > > > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > [EMAIL PROTECTED] . > Trouble? e-mail to [EMAIL PROTECTED] . > -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
