X-Original-To: pgsql-hackers-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 8ED929FA10E for ; Fri, 1 Sep 2006 20:44:44 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 53827-06-5 for ; Fri, 1 Sep 2006 20:44:24 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from localhost.localdomain (host86-130-26-100.range86-130.btcentralplus.com [86.130.26.100]) by postgresql.org (Postfix) with ESMTP id 7B4D19FB277 for ; Fri, 1 Sep 2006 20:42:51 -0300 (ADT) Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by localhost.localdomain with esmtp (Exim 4.62) (envelope-from ) id 1GJIf0-0001eH-PE; Sat, 02 Sep 2006 00:42:54 +0100 To: Tom Lane Cc: josh@agliodbs.com, Bruce Momjian , pgsql-hackers@postgresql.org Subject: Re: Getting a move on for 8.2 beta In-Reply-To: <25583.1157151710@sss.pgh.pa.us> (Tom Lane's message of "Fri, 01 Sep 2006 19:01:50 -0400") X-Draft-From: ("nnimap+webmail.enterprisedb.com:Inbox" 1209) References: <200609012120.k81LKdq21856@momjian.us> <200609011509.21725.josh@agliodbs.com> <25583.1157151710@sss.pgh.pa.us> From: Gregory Stark Organization: EnterpriseDB Date: Sat, 02 Sep 2006 00:42:54 +0100 Message-ID: <87odtzi269.fsf@enterprisedb.com> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.721 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO, RCVD_IN_NJABL_DUL X-Spam-Level: * X-Archive-Number: 200609/82 X-Sequence-Number: 89611 Tom Lane writes: >> If you look at the two "incomplete" patches, and the "misfired" one >> (Bitmaps, Updatable Views, and WITH RECURSIVE) all of them are patches >> where the submitter had been working on them months ago, and might have >> made the release (or let us know they weren't on schedule) if we'd held >> them to an earlier deadline. > > Perhaps, but I'm not sure what we can or should do about it. Moving > deadlines up will either create a dead zone where we all sit around > twiddling our thumbs, or people will keep on coding till the last minute > anyway. I don't think that's what would happen at all. In fact what I think would happen is that it would free up people like you to work on stuff you're interested in instead of reviewing patches. As an extreme example consider the new Linux release cycle. They have a non-freeze period of a couple weeks, followed by months of frozen time. Users who want to try out new features on different hardware can do so and often turn up problems developers reviewing the patches missed. Developers spend the months of frozen time working on new patches which, if they're ready on time, all go into the queue in the first few weeks of a new release. If they miss the window they'll make the next one. As a result they don't get things like what we saw with 8.0 where major new features like PITR, nested transactions and so on all hit the tree in the final days before the freeze. Instead they go in early and if they turn out to be immature they get pulled long before the actual release. I would love to see the bitmap indexes and updatable views get merged into the tree just weeks after the release comes out rather than disappear again until just before the next release. If I were a user depending on these new features it would give me a hell of a lot more confidence if people could say they've been in the CVS version for months and nobody's had problems with them than to be told they were reviewed by one person three weeks ago and nobody else has had much of a chance to use it. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com