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 90DF6D1B4F7; Tue, 18 Nov 2003 04:39:14 +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 43115-07; Tue, 18 Nov 2003 00:38:43 -0400 (AST) Received: from ganymede.hub.org (u46n208.hfx.eastlink.ca [24.222.46.208]) by svr1.postgresql.org (Postfix) with ESMTP id 75BA5D1B527; Tue, 18 Nov 2003 00:38:42 -0400 (AST) Received: by ganymede.hub.org (Postfix, from userid 1000) id 74761355B0; Tue, 18 Nov 2003 00:36:11 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 7376A34FF9; Tue, 18 Nov 2003 00:36:11 -0400 (AST) Date: Tue, 18 Nov 2003 00:36:11 -0400 (AST) From: "Marc G. Fournier" X-X-Sender: scrappy@ganymede.hub.org To: Peter Eisentraut Cc: Neil Conway , "Matthew T. O'Connor" , "Marc G. Fournier" , Christopher Kings-Lynne , PostgreSQL Development Subject: Re: Release cycle length In-Reply-To: Message-ID: <20031118002930.U731@ganymede.hub.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200311/934 X-Sequence-Number: 47222 On Tue, 18 Nov 2003, Peter Eisentraut wrote: > 0. As you say, make it known to the public. Have people test their > in-development applications using a beta. and how do you propose we do that? I think this is the hard part ... other then the first beta, I post a note out to -announce and -general that the beta's have been tag'd and bundled for download ... I know Sean does up a 'devel' port for FreeBSD, but I don't believe any of the RPM/deb maintainers do anything until the final release ... > 1. Start platform testing on day 1 of beta. Last minute fixes for AIX > or UnixWare are really becoming old jokes. then each beta will have to be "re-certified" for that beta, up until release ... doable, but I don't think you'll find many that will bother until we are close to release ... > 2. Have a complete account of the changes available at the start of beta, > so people know what to test. Bruce, when do you do your initial HISTORY file? Something to move to the start of beta, if not? > 3. Use a bug-tracking system so that "open items" are known early and by > everyone. Waiting to see anyone decide on which one to use ... willing to spend the time working to get it online ... > 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. We try that every release ... > 5. If need be, have a release management team that manages 0-4. Core does that, but we just don't feel that being totally rigid is (or has ever been) a requirement ... but, if you can provide suggestions on points 0 and 3, we're all ears ...