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 EB12D9FB50D for ; Sat, 2 Sep 2006 13:03:27 -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 26000-01 for ; Sat, 2 Sep 2006 13:03:22 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id B8D5E9FB528 for ; Sat, 2 Sep 2006 13:03:15 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k82G3Auq003574; Sat, 2 Sep 2006 12:03:10 -0400 (EDT) To: Theo Schlossnagle cc: Alvaro Herrera , Peter Eisentraut , pgsql-hackers@postgresql.org, Josh Berkus , Bruce Momjian Subject: Re: Getting a move on for 8.2 beta In-reply-to: References: <200609012225.k81MPwJ02170@momjian.us> <200609011639.42280.josh@agliodbs.com> <26043.1157154656@sss.pgh.pa.us> <200609020209.36483.peter_e@gmx.net> <20060902014835.GB14288@alvh.no-ip.org> <3246.1157210938@sss.pgh.pa.us> Comments: In-reply-to Theo Schlossnagle message dated "Sat, 02 Sep 2006 11:41:48 -0400" Date: Sat, 02 Sep 2006 12:03:10 -0400 Message-ID: <3573.1157212990@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.124 tagged_above=0 required=5 tests=AWL, SPF_HELO_PASS, SPF_PASS X-Spam-Level: X-Archive-Number: 200609/140 X-Sequence-Number: 89669 Theo Schlossnagle writes: > Additionally, what problem is accepting incremental patches supposed > to solve? Keeping the individual patches reviewable is one useful goal. We may be talking at cross-purposes here. The sort of thing I think Alvaro is imagining is something like what I did a year or two back when I wanted to make the executor treat plan trees as read-only --- if memory serves, I did that in three or four commits spread over a week or two. I could have done it in one massive patch but it would have been unreadable to me or anyone else. And for that matter, the reason for doing it at all was as part of a much larger concept that's still unfinished (better caching and invalidation of plans). When you're talking about tasks of that magnitude, stepwise improvement is the only way you are going to get there at all. I really don't have any faith in the concept of doing very large tasks on a development branch and expecting to land them in one huge merge. For a nearby counterexample look at Postgres-R, which never has and probably never will manage to produce a patch that could apply to the core project's CVS head. At least not without thinking of some incremental way to do it, because by the time they bring all their changes up to HEAD, the tree has always drifted under them. There is no magic version control system that will fix that. regards, tom lane