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



> I think two releases a year is pretty good, really.  Testing isn't easy,
> and it tends not to be as rewarding as development, in all candor.
> Testing means not changing things.  My impression is, testing and not
> making changes are -HARD-.  Development takes concentration, but it
> doesn't take the same kind of discipline that not making changes does.
> 
> 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.


> Brian C. White wrote:
> >
> > I can't believe I'm getting involved in this again...
> >
> > What I would suggest, for a 3 month release schedule is the following:
> >
> > 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.
> >
> > To me, the primary goal behind "stable" is stability.  Period.  Cutting
> > edge, latest packages, new features, etc. are all secondary.  If those
> > are your primary concern, then you should be using the "unstable" tree.
                                             
                                          Brian
                                 ( bcwhite@verisim.com )
                                             
-------------------------------------------------------------------------------
    In theory, theory and practice are the same.  In practice, they're not.


--
This message was delayed because the list mail delivery agent was down.