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

On Wed, Jul 31, 2002 at 02:08:33PM -0300, Marc G. Fournier wrote:
>
> 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?

Well, portability's actually a lot better than that OS-wise. The thing
to worry about is compilers. I've got some changes from Clinton James
waiting in the wings until libpqxx's status and development home are
settled. Those changes will make it compile on the latest version of
Visual C++ (and I'll take some changes out again once they're no longer
needed for that purpose), and most of it seems to work.

> 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 ...

Looking at it that way, it seems to me that the proper approach is to
cut out all interfaces that don't talk to the backend themselves--e.g.
the ones that build on top of libpq, like libpq++ and libpqxx do.

Of course my humble but thoroughly biased opinion is that libpq++ be
marked "legacy."

> 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?

Yes. Now STOP BRUTALIZING MY NAME!

...

Phew. I feel better now. What was I saying?

Ah, yes. What you say pretty much describes how libpqxx came to be: get
a local copy of libpq++, try to fix it on a carte-blanche basis, find
nothing salvageable, write from scratch building on libpq++'s experience.

That said, I do support the idea of separately administered projects for
the reasons you give. Looking at specifics first, the problem I'm stuck
with for now is that I can't really work on the thing until this point is
decided. Well I could, but not until the doctor lets me get back to it.
Which requires, among other things, that it not give me headaches. :-)

For the more general case, there's the problem of release management: who's
going to be taking care of synchronizing releases? This may require some
new infrastructure, such as a mailing list dedicated to the process, or one
restricted to subproject maintainers. Or something.

Perhaps the unbundling of subprojects justifies that version bump to 8.0
after all...

Jeroen

(Juliet Echo Romeo Oscar Echo November. Jeroen. No G. Note intricate
order of vowels. Phonetic spelling in English would be Yeroon. Try to
roll the "r" a little.)