Re: Modest proposal for successful releases

[Dan Stromberg <strombrg@nis.acs.uci.edu>]

Brian C. White wrote:
> > I'd like to see something like:
> >
> > month 1: develop
> > month 2: develop
> > month 3: develop
> > month 4: develop and dig up preliminary list of beta testers
> > month 5: develop, and make beta release at end of month
> > month 6: make absolutely minimal bug-fix changes, and release to public
> 
> I could easily see this if debian involed a lot of "development".  However,
> Debian is mostly about taking other people's development & testing, and
> fitting it all together.

Debian involves a lot of "development", in the sense that debian has a
lot of "developers".  Granted, in the debian world, "development" is
primarily "systems integration".

IE, debian's more like building motherboards, than like VLSI design&fab. 

motherboards still need good testing before market, tho.  Look what
happens to a workstation vendor, if they contract out for CPU's, but 
put flakey CPU's in their motherboards - or more likely, just didn't
sufficiently test the interaction of their outsourced CPU's with their
outsourced on-board disk controllers and outsourced UART's.

They loose sales, in a big way - especially if they aren't a PC clone
board maker, one with lots of singular visibility, like sun, sgi, hp...
Or like a linux distribution.

Note that systems integration in industry, is a small percentage cutting
and pasting, and a large percentage: testing.  In fact, there'll often
be an entire staff devoted to testing, and nothing but testing - but I
don't think that's a good plan for a free project.

I'm not arguing for doing more testing than pasting (not at all - it
wouldn't be as fun to most) like we should if we were an industry shop,
but I am arguing that "other people develop and test for us" is
incompatible with "we've released buggy stuff too often, and we need to
test more to stop it."

I think it would be pretty painless to test by:

1) cultivating a list of people who want to try out beta stuff, and
would be interested in doing a full re-install for the sake of truly
testing out the install-portion of a beta release (this would be a small
but valuable list, if -one- additional person wanted to do it)

2) announcing beta availability of a new debian release on COLA, a day
or two before the beginning of the beta period.

3) announcing the location of "beta" and "stable" stuff, on ftp
README's, througout the beta period.  This way people who like bleeding
edge stuff sometimes but not always (like me) could just install the
beta stuff if they happen to want an upgrade during that time.


I'm not going to advocate restricted access.  I am advocating a formal
beta, and careful suggestions as to when people should go with beta
stuff, and when people should go with stable stuff.

I think that debian's future as a semi-major (at least) distribution,
depends on this.


	Each team building another component has been using the most
	recent tested version of the integrated system as a test bed
	for debugging its piece.  Their work will be set back by
	having that test bed change under them.  Of course it must.
	But the changes need to be quantized.  Then each user has
	periods of productive stability, interrupted by bursts of
	test-bed change.  This seems to be much less disruptive than a
	constant rippling and trembling.

	- Frederick Brooks Jr., "The Mythical Man Month"

(we should do that)

	As the system comes up, the component builders will from
	time to time appear, bearing hot new versions of their
	pieces -- faster, smaller, more complete, or putatively less
	buggy.  The replacement of a working component by a new
	version requires the same systematic testing procedure that
	adding a new component does, although it should require less
	time, for more complete and efficient test cases will
	usually be available.

	- Frederick Brooks Jr., "The Mythical Man Month"

(we shouldn't go to this extreme, but we should keep it in mind when
deciding how much to test)


--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com