X-Original-To: pgsql-hackers@postgresql.org Received: from candle.pha.pa.us (momjian.navpoint.com [207.106.42.251]) by postgresql.org (Postfix) with ESMTP id 5529D475CE5; Tue, 11 Mar 2003 06:31:28 -0500 (EST) Received: (from pgman@localhost) by candle.pha.pa.us (8.11.6/8.10.1) id h2BBVQd25189; Tue, 11 Mar 2003 06:31:26 -0500 (EST) From: Bruce Momjian Message-Id: <200303111131.h2BBVQd25189@candle.pha.pa.us> Subject: Re: Beta schedule (was Roadmap for FE/BE protocol redesign) In-Reply-To: <2920.1047360721@sss.pgh.pa.us> To: Tom Lane Date: Tue, 11 Mar 2003 06:31:26 -0500 (EST) Cc: Justin Clift , pgsql-hackers@postgresql.org X-Mailer: ELM [version 2.4ME+ PL99 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Archive-Number: 200303/419 X-Sequence-Number: 36665 I agree, let's not wait for specific features. The issue was whether we had enough significant features done for a release --- I didn't think we did, so I am saying, let's get more features, rather than let's get feature X. As we fill in missing features, there will be less must-have features to add, so we are left with continuing with our present release pace or releasing less frequently with the same number of feature additions. --------------------------------------------------------------------------- Tom Lane wrote: > Justin Clift writes: > > With 7.1/7.2, Tom mentioned us being delayed because specific features > > we were waiting for became dependant on one person. > > > Would it be feasible to investigate approaches for having the Win32 and > > PITR work be shared amongst a few very-interested volunteers, so that > > people can cover for each other's downtime? > > It would certainly be good to bring as much manpower to bear on those > problems as we can. But that doesn't really address my concern: if the > schedule is defined as "we go beta when feature X is done", then no one > who's working on stuff other than feature X knows how to plan their > time. The only fair way to run the project is "we go beta at time T"; > that way everyone knows what they need to shoot for and can plan > accordingly. > > I don't mind setting the planned time T on the basis of what we think > it will take for certain popular feature X's to be done. But if the > guys working on X aren't done at T, it's not fair to everyone else to > hold our breaths waiting for them to be done at T-plus-who-knows-what. > > I don't really have any sympathy for the argument that "it won't be a > compelling release if we don't have feature X". If the release isn't > compelling for someone, they don't have to upgrade; they can wait for > the next release. The folks who *are* eager for what's been gotten done > will be glad of having a release now rather than N months from now. > And do I need to point out that "it runs on Windoze" is not of > earth-shattering importance for everyone? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073