Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 1047E9FB1D4; Tue, 1 May 2007 11:52:30 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 62928-02; Tue, 1 May 2007 11:52:19 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from momjian.us (momjian.us [70.90.9.53]) by postgresql.org (Postfix) with ESMTP id 331ED9FA462; Tue, 1 May 2007 11:52:26 -0300 (ADT) Received: (from bruce@localhost) by momjian.us (8.11.6/8.11.6) id l41EqPN10520; Tue, 1 May 2007 10:52:25 -0400 (EDT) From: Bruce Momjian Message-Id: <200705011452.l41EqPN10520@momjian.us> Subject: Re: Feature freeze progress report In-Reply-To: <4636F29F.8000001@postgresql.org> To: Dave Page Date: Tue, 1 May 2007 10:52:25 -0400 (EDT) CC: Tom Lane , Heikki Linnakangas , Simon Riggs , PostgreSQL-development X-Mailer: ELM [version 2.4ME+ PL123] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200705/10 X-Sequence-Number: 102612 Dave Page wrote: > > The bottom line is that there is a lot of thinking that the patch queue > > is so large because no one knows what to do. "Oh, if we were better > > communicators, more would be done". The patch queue is large because we > > have lots of March 31 patches, and because we don't have enough people > > to review them quickly. > > Thats is true, but there are also patches in there that have been there > for quite some time adn have had little or no feedback. Consider > Heikki's grouped index items patch > (http://momjian.us/mhonarc/patches/msg00032.html). That thread starts on > 7th March when he posted an update because the old one had bitrotted. > There are six messages in the thread on the patch queue, four of which > say "message no available", and the last means little without the > preceeding messages. > > When a committer comes to look at this, if he's not sure of something > he's going to be wasting time searching the archives to find all the > different thread fragments that make up the various discussions on the > topic, and those related to each individual revision of the patch. That > has got to be part of what makes reviewing patches both hard, and > uninteresting work. If we can make it easier and quicker, even with just > the current committers we might have found that one of you were able > (and keen) to review much more quickly. The bottom line is if you had a system that was 100% perfect in capturing all information about a patch, it only helps us 2% toward reviewing the patch, and what is the cost of keeping 100% information? -- Bruce Momjian http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +