Received: from candle.pha.pa.us (pgman@nav-43.dsl.navpoint.com [162.33.245.46]) by hub.org (8.10.1/8.10.1) with ESMTP id e9842VJ35718 for ; Sun, 8 Oct 2000 00:02:31 -0400 (EDT) Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id AAA02394; Sun, 8 Oct 2000 00:02:00 -0400 (EDT) From: Bruce Momjian Message-Id: <200010080402.AAA02394@candle.pha.pa.us> Subject: Re: Re: [ANNOUNCE] Announce: Release of PyGreSQL version 3.0 In-Reply-To: "from Marc G. Fournier at Oct 7, 2000 11:55:09 pm" To: "Marc G. Fournier" Date: Sun, 8 Oct 2000 00:02:00 -0400 (EDT) CC: Tom Lane , "D'Arcy J.M. Cain" , PostgreSQL-development X-Mailer: ELM [version 2.4ME+ PL77 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Archive-Number: 200010/168 > > Well, a third party author always has the option to release his code > > separately on whatever timeline seems good to him. But I think that for > > third-party code included in the distribution, the same standards ought > > to apply as for the Postgres code itself: we don't want people sticking > > alpha-quality code into a Postgres release tarball, whether it's core > > functionality or not. It's not as if "no new features for a month" is > > a particularly onerous standard to meet ;-) > > agreed about the alpha quality, but if someone like D'Arcy or Constantin > releases a new version of their code, is there any reason to hold off on > bringing that in? Haven't we done that in the past with pgaccess as it > is? I seem to recall Bruce bringing in a new release of PgAccess close to > the release, but am not 100% certain of this ... Yes, that is true. I don't have a problem with 3rd party stuff that does not install by default. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026