Re: Modest proposal for successful releases

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

Brian C. White wrote:
> > 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.
> 
> Oh, I understand this.  This is why I originally advocated a three
> month schedule that include 1 month of bringing in the latest stuff
> and 2 months of testing it together as a whole.  As I understand
> the 6 month schedule, it is 5 months of development (i.e. getting
> new stuff and having the _maintainers_ write code patches) plus 1
> month of system testing.

True, good point.

I'll add that testing a release can be a bit like packet overhead - too
many releases, and you're network is bombed with tinygrams.

I envision a testing period as being mostly:

1) Getting amiable people filing bug reports on problems they
encounter     in day-to-day use
2) Debian maintainers passing bug reports upstream, fixing bugs and
   passing fixes upstream, and/or (as a slightly deprecated resort)
   dropping back to an earlier release of a package

I suspect that if we're testing twice a year, it won't be quite so hard
to discipline ourselves into doing it well, nor quite so hard to find
people interested in running beta software.

Granted, there are lots of folks interested in hopping into unstable, I
like to myself.  But that doesn't help much with putting together a
stable release.

> >        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.
> 
> Very true, but I don't believe that applies directly here.  (Note that
> I'm about to make a distiction between software developers and release
> developers.)

I think it applies, but I'll concede it needn't be the single most
important concern in a development/test/release schedule.  Just A
concern.


> Those people developing software/system-components _do_ (or should) have
> a stable integrated system to work with.  This is called the "stable"
> release.
> 
> Those people developing _releases_ (putting the system components
> together) have already finished their previous product (the stable
> release) and are now working on a new product.

In both of these scenarios, people are starting from something stable.
The question at hand is "how often do they do that?"

> One of the problems I have with a 6-month release schedule is that
> many people would feel the need to go to the "unstable" distribution
> and thus violate the rule you stated above.  This can be seen very
> clearly by the comments people make about "unstable" being more
> stable than "stable".

That's an important comment.

Where does this sit in relation to "-fixes"?  How many of the people
saying this are comfortable with (lots of) change?


--
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