X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 2B4DED1DA92; Tue, 18 Nov 2003 03:42:53 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 31095-09; Mon, 17 Nov 2003 23:42:26 -0400 (AST) Received: from houston.familyhealth.com.au (fhnet.arach.net.au [203.22.197.21]) by svr1.postgresql.org (Postfix) with ESMTP id 5F047D1DAD3; Mon, 17 Nov 2003 23:28:53 -0400 (AST) Received: from familyhealth.com.au (work-40.internal [192.168.0.40]) by houston.familyhealth.com.au (8.12.9p1/8.12.9) with ESMTP id hAI3SqoD074961; Tue, 18 Nov 2003 11:28:53 +0800 (WST) (envelope-from chriskl@familyhealth.com.au) Message-ID: <3FB992C9.6020207@familyhealth.com.au> Date: Tue, 18 Nov 2003 11:32:25 +0800 From: Christopher Kings-Lynne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Neil Conway Cc: "Matthew T. O'Connor" , Peter Eisentraut , "Marc G. Fournier" , PostgreSQL Development Subject: Re: Release cycle length References: <3FB988B8.1050904@zeut.net> <87smkmgyn7.fsf@mailbox.samurai.com> In-Reply-To: <87smkmgyn7.fsf@mailbox.samurai.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200311/929 X-Sequence-Number: 47217 > 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