public inbox for [email protected]  

help / color / mirror / Atom feed

From: Christopher Kings-Lynne <[email protected]>
To: Neil Conway <[email protected]>
Cc: Matthew T. O'Connor <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Marc G. Fournier <[email protected]>
Cc: PostgreSQL Development <[email protected]>
Subject: Re: Release cycle length
Date: Tue, 18 Nov 2003 11:32:25 +0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>

> 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

view thread (83+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Release cycle length
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox