Re: Trim the Fat (Was: Re: Open 7.3 items ) - Mailing list pgsql-hackers

From Marc G. Fournier
Subject Re: Trim the Fat (Was: Re: Open 7.3 items )
Date
Msg-id 20020801040535.O83339-100000@mail1.hub.org
Whole thread Raw
In response to Re: Trim the Fat (Was: Re: Open 7.3 items )  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Trim the Fat (Was: Re: Open 7.3 items )  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Trim the Fat (Was: Re: Open 7.3 items )  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Trim the Fat (Was: Re: Open 7.3 items )  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Thu, 1 Aug 2002, Tom Lane wrote:

> Thomas Lockhart <lockhart@fourpalms.org> writes:
> > Until we have folks who are excited enough about it to plan it out and
> > do the work, piecemeal rejection of components is not leading to a more
> > solid product.
>
> I'm lukewarm about whether to actually do the split or not ... but for
> sure I agree with Thomas' point here.  We need a plan and careful
> implementation, or a split-up will just make life worse.
>
> Stuff that is in the tree tends to get maintained in passing.  For
> example, I've got some changes to contrib/dblink/ in my in-progress
> version of Chris' DROP COLUMN patch, because a grep for references
> to rel->rd_att turned it up.  If dblink weren't in our CVS it'd have
> been broken by DROP COLUMN, and who knows whether we'd catch that
> during beta?  I realize that Marc wasn't proposing splitting off any
> server-side code, but I still want to tread carefully about breaking
> up the codebase.

Okay, well, the way I'm working it through right now, I'm doing it in such
a way that unless you go mucking in the repository directly, it will be
transparent to the coders, as well as to the distribution as a whole ...

In fact, based on a comment that Thomas made in another email, I'll even
fix up the whole 'cvs checkout pgsql' thing so that that goes back to its
previous incarnation of pulling everything, instead of needing to do
pgsql-all ...

So, from the 'client side', y'all will still see "everything as one big
package", while from the 'server side', I'll have the seperate modules
taht can be packaged independently ...

Next, unless Peter knows how to do it already, I've gotta learn to make
configure more intelligent, so that for all intents, the "pieces" look
like one package when building, not just when coding ...



pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: Trimming the Fat, Part Deux ...
Next
From: "Marc G. Fournier"
Date:
Subject: Re: Trimming the Fat, Part Deux ...