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 7B916D1CCB7 for ; Tue, 18 Nov 2003 03:57:33 +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 32998-06 for ; Mon, 17 Nov 2003 23:57:06 -0400 (AST) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by svr1.postgresql.org (Postfix) with SMTP id 480EFD1DA8F for ; Mon, 17 Nov 2003 23:42:52 -0400 (AST) Received: (qmail 2079 invoked by uid 65534); 18 Nov 2003 03:42:56 -0000 Received: from dsl-082-082-166-244.arcor-ip.net (EHLO [192.168.2.136]) (82.82.166.244) by mail.gmx.net (mp001) with SMTP; 18 Nov 2003 04:42:56 +0100 X-Authenticated: #495269 Date: Tue, 18 Nov 2003 04:43:12 +0100 (CET) From: Peter Eisentraut X-X-Sender: peter@peter.localdomain To: Neil Conway Cc: "Matthew T. O'Connor" , "Marc G. Fournier" , Christopher Kings-Lynne , PostgreSQL Development Subject: Re: Release cycle length In-Reply-To: <87smkmgyn7.fsf@mailbox.samurai.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200311/930 X-Sequence-Number: 47218 Neil Conway writes: > 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? Here are a couple of ideas: 0. As you say, make it known to the public. Have people test their in-development applications using a beta. 1. Start platform testing on day 1 of beta. Last minute fixes for AIX or UnixWare are really becoming old jokes. 2. Have a complete account of the changes available at the start of beta, so people know what to test. 3. Use a bug-tracking system so that "open items" are known early and by everyone. 4. Have a schedule. Not "We're looking at a release early in the later part of this year.", but dates for steps such as feature freeze then, proposals for open issues fielded then, string freeze then, release candiate then. 5. If need be, have a release management team that manages 0-4. -- Peter Eisentraut peter_e@gmx.net