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

On Thu, Aug 01, 2002 at 09:07:46PM -0300, Marc G. Fournier wrote:
> 
> > Of course my humble but thoroughly biased opinion is that libpq++ be
> > marked "legacy."
> 
> No doubt, but, if we didn't "push" one interface over another, then it
> would be up to the end-users themselves to decide which one to install ...
In theory, yes.  In this case, however, I see two arguments for making
the distinction anyway:

1. Some people won't want to go to the trouble of comparing available 
interfaces, so they may default to libpq++ because it's what they found
first, or because they find mentions of it as the official C++ interface.
I think it would be a shame to have new users default to libpq++ "by 
accident."  I think many users would prefer to rely on the PostgreSQL 
team's judgment--as they do by choosing Postgres in the first place.

2. I get the impression that libpq++ sort of got stuck before it was
completed.  For the time being libpqxx appears to have better maintenance
prospects.  Users will want to be aware of this before making a choice.


> Okay, then let's word it another way ... if libpq++ *wasn't* in the
> repository and part of the distribution, would you have a) started working
> on it sooner?  b) would you have made it public earlier?  c) would ppl
> have started to use it and stop'd using libpq++?
I'm not sure there's much point to going into a single example in detail,
but for completeness' sake I'll just answer these:

a) Yes.
b) No, because in my case I was encouraged by team members' endorsement of
first my suggestions for libpq++, and later a full replacement.  Without
that, and without an active libpq++ maintainer around, libpqxx might never 
have gotten off the ground.
c) I'd like to think so, yes--but exposure would have been harder.


> Basically, with libpq++ in the distribution, we are endorsing its use, so
> if we didn't put libpqxx into the repository, would ppl switch from the
> 'endorsed' to the 'unendorsed' version?
> 
> By having libpq++ in the repository, we are adding weight to it that it
> wouldn't have if it were outside of the repository, making it more
> difficult for 'alternatives' to pop in ...
I definitely agree here.  See above.


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

This reminds me of another potential complication: how would unbundling
affect the licensing situation?  Mixing and matching components is good
in many ways, but it could complicate the situation for end-users--who
probably like to be able to rely on the team's judgment on this issue as 
well.

I feel compelled at this point to admit that I prefer the GPL.  This is
a personal preference, which I set aside because I wanted and expected 
libpqxx to become the standard C++ interface.  Had these interfaces not
been bundled, I would have had less incentive to conform to Postgres'
licensing conditions.  I think having a different license would have
made everyone's life a little harder.


Jeroen

(and yes, I'm trying to repair my From: lines!)