Re: Release cycle length

> That said, I'm not really sure how we can make better use of the beta
> period. One obvious improvement would be making the beta announcements
> more visible: the obscurity of the beta process on www.postgresql.org
> for 7.4 was pretty ridiculous. Does anyone else have a suggestion on
> what we can do to produce a more reliable .0 release in less time?

I can think of a few things.

1. Try to encourage list members to actually test stuff. For example, I
decided to find stuff that might be broken. So I checked the tutorial
scripts (no-one ever looks at them) and found heaps of bugs. I thought
about some new features and tried to break them. I also tend to find
bugs by coding phpPgAdmin and delving into the nitty gritty of stuff.

Maybe we could actually ask for people for the 'beta team'. Then, once
we have volunteers, they are each assigned a set of features to test by
the 'testing co-ordinator' (a new core position, say?) What you are
asked to test depends on your skill, say.

eg. Someone who just knows how to use postgres could test my upcoming
COMMENT ON patch. (It's best if I myself do not test it) Someone with
more skill with a debugger can be asked to test unique hash indexes by
playing with concurrency, etc.

The test co-ordinator could also manage the testing of new features as
they are committed to save time later.

The co-ordinator should also maintain a list of what features have been
committed, which have been code reviewed (what Tom usually does) and
which have been tested.

Of course, I'm not talking about exhaustive testing here, just better
and more organised that what we currently have.

Chris