Re: InfoMagic's new LDR
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 <swasey@together.net>
> X-Sender: swasey@sequoia
> To: tgakem@chem.tue.nl
> cc: tgakem@chem.tue.nl, debian-user@lists.debian.org
> Subject: Re: InfoMagic's new LDR
> Resent-From: debian-user@lists.debian.org
>
>
>
> On Mon, 12 May 1997 tgakem@chem.tue.nl 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
> debian-user-request@lists.debian.org .
> Trouble? e-mail to templin@bucknell.edu .
>
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: