Testing

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> >From Subject: Re: Python 3 division
> > My plan is to let the current minor flurry of bug-fixing activity subside
> > and then call a short freeze. 
> 
> That's what I've been trying to complain about.
> 
> If all you do is call a "short" freeze before a release, nobody ever has time 
> to look around and try things that might uncover bugs.

Well, normally it would be a longer freeze, but we're doing this to roll out
a bug fix on code that has been pretty stable.

> A serious testing phase is also a good opportunity to test and improve the 
> documentation.  Documentation gets tested if people use it when they try 
> something new.  I'm willing to fis or clarify documentation without setting 
> the testing timer back to zero.  We can get several people to review the 
> changes.
> 
> It's probably worth several of us making a pass over all the documentation.  
> That includes most of devel/ as well as what gets installed.

Aha. This sounds like the beginning of something I just asked you to do
privately - design an actual acceptance process for a release.

What does a "serious testing phase" look like? When we do a documentation
pass, how do we know when we're done?

I'm not trying objecting to be difficult.  These are things we need to have
some handle on for the proces to be implementable.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.