Testing

[Hal Murray]

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

I'll be glad to work on that.  Where does it fit in on the priorities?  I'm 
assuming not much will happen until after the release.

There was some sort of document on the release process.  Anybody remember 
where it lives?

I think there are 3 areas.

1 is the big picture of project management
2 is getting ready for a release, freeze, testing, and such
3 is the actual release, bumping versions, tagging, tarball, etc


In the short term, I think we have 2 options.  One is to make a bug fix 
release with only a few lines of code changed.  That doesn't require much 
testing.  The other is to release the current HEAD.  I think that deserves 
serious testing.  Handwave, week.


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

My view of a testing phase is either of two options.  One is to allow plenty 
of time and ship when the timer runs out unless the fan is covered with brown 
stuff.  That requires good judgment on the project managers part to pick the 
duration of testing.  The other is to ship after you have gone N days without 
finding anything interesting.  Again, somebody has to pick N.


My comment about a documentation pass was expecting at least one set of 
eyeballs to look at each of the documents in our collection.  More than one 
would be better.  It can be one person looking at everything or split over 
several people.



-- 
These are my opinions.  I hate spam.