The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Modest proposal for successful releases



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

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.

Just to recap my original suggestion...

Month 0:  ("frozen" period of previous release)
 - decisions about what features are to go into the following release
 - anything not finished for the previous release can be started

Month 1:  
 - free-for-all:  any and all upgrades/new-packages/development/etc.                                             

Month 2:
 - internal "developer" testing:  small upgrades, new non-essential
   packages, minor policy changes
 - big packages (X, Passwd, Tex, dpkg & friends, etc) are to have no
   major changes/releases
 - base disks being worked on

Month 3:  "frozen"
 - external "user" testing:  bug fixes only!  no new code!
 - base disks done and undergoing necessary updates/fixes

Release:
 - a nice, stable system with 2 months of testing behind it.


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

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.

If the releases that Debian makes are stable enough and frequent enough,
there there would be no need for users or software developers to use
the "unstable" tree.  Only distribution developers would need 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".

                                          Brian
                                 ( bcwhite@verisim.com )
                                             
-------------------------------------------------------------------------------
  Want to get it together?  We can help!  http://www.verisim.com/coordinator/


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