Received: from localhost (maia-3.hub.org [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 7AD919FB850 for ; Mon, 30 Apr 2007 14:03:59 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 82215-01 for ; Mon, 30 Apr 2007 14:03:53 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from davinci.ethosmedia.com (server227.ethosmedia.com [209.128.84.227]) by postgresql.org (Postfix) with ESMTP id 7683A9FB82E for ; Mon, 30 Apr 2007 14:03:55 -0300 (ADT) X-EthosMedia-Virus-Scanned: no infections found Received: from [63.195.55.98] (account josh@agliodbs.com HELO [192.168.2.3]) by davinci.ethosmedia.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 12046691 for pgsql-hackers@postgresql.org; Mon, 30 Apr 2007 10:08:00 -0700 From: Josh Berkus Organization: PostgreSQL @ Sun To: pgsql-hackers@postgresql.org Subject: Re: Feature freeze progress report Date: Mon, 30 Apr 2007 10:04:25 -0700 User-Agent: KMail/1.8.2 References: <200704270313.l3R3DwF16449@momjian.us> <1177792836.3663.61.camel@silverbirch.site> <46349EF4.2010304@enterprisedb.com> In-Reply-To: <46349EF4.2010304@enterprisedb.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704301004.25297.josh@agliodbs.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200704/1253 X-Sequence-Number: 102586 Heikki, > We're having a short 8.3 cycle because we wanted to shift our release > schedule from Autumn to Spring. That would get us back to releasing in > Autumn. Er, no. We wanted to change the cycle to avoid having Feature Freeze occur at midsummer (N. hemisphere) when many of our committers are unavailable due to conferences or vacation. ----------- Question #559: Would changing version control systems help us on this at all? I'm specifically thinking of preventing bitrot; would using a decentralized VCS allow patch authors to easily prevent bitrot on their own? ----------- I do like the idea of a web management interface for patches. It has a number of additional advantages: -- Advocacy volunteers would know what's under development and thus what they can talk about at user groups -- Advanced users who are interested in a specific patch could download that patch early, test it for their own applications, and supply feedback to the community even before feature freeze. -- A more organized queue would make backporting by the backports project easier. -- We could save the patches by applied date and index them, and then have a place to point users when they ask: "When was X fixed? Do I *have* to upgrade to 8.1 or just 8.0?" -- It would make it easier to manage Google Summer of Code students and their work. -- The status of a partially complete patch abandoned by its author would be much clearer and thus more likely to get picked up by someone else. -- The patch manager could eventually be integrated with the Buildfarm to do automated patch testing. Overall, I think this would be an excellent direction to move for 8.4. As web applications go, it doesn't even sound hard; I think I could write it if I weren't on airplanes all the time. -- Josh Berkus PostgreSQL @ Sun San Francisco