Re: Trim the Fat (Was: Re: Open 7.3 items )

On Wed, 31 Jul 2002, Tom Lane wrote:

> nconway(at)klamath(dot)dyndns(dot)org (Neil Conway) writes:
> > Mentioning that on -hackers would have been nice -- I've spent a while
> > this week hacking autoconf / Makefiles to integrate libpqxx...
>
> Marc's opinion is not the same thing as a done deal ;-) --- we still
> have to discuss this, and if someone's already doing the integration
> work I think that's an important factor.
>
> > If we're going to start removing interfaces, I'd vote for the removal of
> > perl5 & libpq++ as well as libpqxx.
>
> Agreed on that point. We shouldn't be promoting old, crufty interface
> libraries when there are better ones available.
>
> I would personally prefer to see libpqxx integrated now, and then we
> could plan to remove libpq++ in a release or two (after giving people
> a reasonable opportunity to switch over). If anyone still cares about
> libpq++ at that point, it could be given a home on gborg.
>
> One reason for wanting to integrate libpqxx is that I don't think we'll
> find out anything about its portability until we get a lot of people
> trying to build it. If it's a separate distro that won't happen quickly.

Who cares? Those that need a C++ interface will know where to find it,
and will report bugs that they have ... why should it be tested on every
platform when we *might* only have those on the Linux platform using it?

What happens if/when libpqxx becomes the 'old, crufty interface' and
something newer and shinier comes along? Where do we draw the line at
what is in the distribution? For instance, why pgaccess vs a platform
independent version of PgAdmin vs PHPPgAdmin? Hell, IMHO, PHPPgAdmin
would most likely be more useful as more sites out there are running PHP
then likely have TCL installed ... but someone that is using TCL/AolServer
would definitely think otherwise ...

By branching out the fat, we make it *easier* for someone to take on
development of it ... would libpqxx ever have been developed if Joergen
could have just worked on libpq++ in the first place, without having to
submit patches?

I really do not want to keep adding more users onto postgresql.org's
servers just because "hey, their interface is cool and useful so let's add
it into the main CVS repository and give them CVS access to save them
having to submit patches" when we have a fully functioning collaborative
development environment that gives them *more* then what we can give them
now ...

1. the ability to pull in their own group of developers / committers on a
per project basis
2. the ability to make releases *as required*, instead of having to wait
for us to do the next release

The benefit to us ... a much much smaller package of programs that have to
be maintained and tested and debugged before a release ...

Hell, how many packages do we currently have integrated with the whole
distribution that rely *nothing* on the server other then to be able to
use libpq to compile, that would benefit from being able to do releases?
If, for instance, the libpq++ interface gets patched up to fix a race
condition, or a vulnerability, the way things are right now, ppl have two
choices: wait for v7.3 to be released sometime in October, or upgrade to
the latest code via anon-cvs/cvsup ... and for package maintainers (rpm,
deb, pkg), they pretty much have no choice but to wait ...

Move libpq++ out as its own, independent project, and that patch would
force a quick packaging and release of the new code, which those same
package maintainers could jump on quickly and get out to *their* users ...

How many packages/interfaces do we have 'integrated' right now that rely
in no way on our release cycle *except* for the fact that they are
integrated?

The way we do things now made sense 7 years ago when we started out trying
to get it as visible to the masses as possible ... and when we *didn't*
have a clean/easy way to manage them externally ... it doesn't make any
sense to do anymore, and hasn't for a fair time now ...