Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 0E8FA1337B6E for ; Wed, 9 Feb 2011 08:53:32 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 68804-03 for ; Wed, 9 Feb 2011 12:53:24 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mail.postgresql.org (Postfix) with SMTP id 21BAC1337B5D for ; Wed, 9 Feb 2011 08:53:23 -0400 (AST) Received: (qmail invoked by alias); 09 Feb 2011 12:53:22 -0000 Received: from fsgw.f-secure.com (EHLO [10.128.133.18]) [193.110.108.33] by mail.gmx.net (mp009) with SMTP; 09 Feb 2011 13:53:22 +0100 X-Authenticated: #495269 X-Provags-ID: V01U2FsdGVkX18VQahIiTQVabdDfxOdMp75T4m6gnVourSZlZxgcW IBhsVcfXTnlNx+ Subject: Re: Sync Rep for 2011CF1 From: Peter Eisentraut To: Robert Haas Cc: Tom Lane , Simon Riggs , Aidan Van Dyk , Heikki Linnakangas , pgsql-hackers@postgresql.org In-Reply-To: References: <1295127631.3282.100.camel@ebony> <4D397FE4.2020709@enterprisedb.com> <1295616270.1803.10799.camel@ebony> <4D39A761.1020105@enterprisedb.com> <1295629194.1803.11957.camel@ebony> <14761.1295633002@sss.pgh.pa.us> <1295703074.1803.19835.camel@ebony> <1297096419.1770.5824.camel@ebony> <21347.1297100595@sss.pgh.pa.us> Content-Type: text/plain; charset="UTF-8" Date: Wed, 09 Feb 2011 14:53:20 +0200 Message-ID: <1297256000.8685.217.camel@fsopti579.F-Secure.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.909 tagged_above=-5 required=5 tests=BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201102/724 X-Sequence-Number: 181513 On mån, 2011-02-07 at 12:55 -0500, Robert Haas wrote: > On Mon, Feb 7, 2011 at 12:43 PM, Tom Lane wrote: > > Robert Haas writes: > >> ... Well, the current CommitFest ends in one week, ... > > > > Really? I thought the idea for the last CF of a development cycle was > > that it kept going till we'd dealt with everything. Arbitrarily > > rejecting stuff we haven't dealt with doesn't seem fair. > > Uh, we did that with 8.4 and it was a disaster. The CommitFest lasted > *five months*. We've been doing schedule-based CommitFests ever since > and it's worked much better. The previous three commit fests contained about 50 patches each and lasted one month each. The current commit fest contains about 100 patches, so it shouldn't be surprising that it will take about 2 months to get through it. Moreover, under the current process, it is apparent that reviewing is the bottleneck. More code gets written than gets reviewed. By insisting on the current schedule, we would just push the growing review backlog ahead of ourselves. The solution (at least short-term, while maintaining the process) has to be to increase the resources (in practice: time) dedicated to reviewing relative to coding.