Re: inclusions WAS: Increased company involvement

Andrew,

> I was not around at the time of the libpq++/libpqxx issue. But, honestly,
> fear of making a wrong decision should not be a reason not to make one.

OK, *you* choose. I'm getting a little annoyed with how many people tell me
"oh, it should be easy to pick the stuff to include with standard
PostgreSQL", and then expect core to do the choosing. Well, it's not easy,
and core made choices. If you don't like them, then make a proposal,
including a set of objective criteria that can be used to evaluate future
projects -- and even to evaluate when to drop one.

Apache does this; they have a 5-step process for accepted projects that took
Brian & co a year to work out. And the process has its cost; evaluation of
acceptance is highly political and not infrequently results in people getting
pissed off and/or impatient with the bureaucracy and leaving Apache to start
independent projects. And even Apache doesn't tar up everything in one big
package; mod_perl, geronimo, PHP, etc. are all separate.

The advantage of a "small kernel" approach is the independence it gives add-in
projects. You can start a pgFoundry project based on a weekend's
enthusiasm; add whomever you want, use whatever OSS license you want, release
on your own schedule. It means that add-in developers can prove the
usefulness of their code by demonstration rather than having to meet some
qualification process.

Look at other large projects with lots of options. Apache, Perl, Linux, Java,
emacs, KDE, etc., all of them strike a balance between including stuff and
leaving stuff as add-ins (some more narrowly than others), and exclude a lot
of popular and useful stuff on a variety of criteria. Our current balance is
on the minimalist side, and somewhat arbitrary if you look at the /contrib
directory. If you think there's a better balance, propose it. Seriously.

> As for CVS - if we can't do development the way we want using it then it's
> time to replace it. I have been convinced for quite a while that it is
> living on borrowed time, but I am far less certain about what should be
> used to replace it. But making macro content decisions on the basis of what
> we can do with CVS is just crazy.

Again, you're saying that you don't have a solution but you think it should be
fixed. Great. I think it should be fixed, too. Afaik, there is *no*
versioning system that allows for both completely independent control of
branches and directories while at the same time allowing for a cohesive
build. Maybe BK does, that would explain why Linus liked it so much.

I, personally, would *love* to find a way for the drivers to be included with
the core build while still letting the various teams -- particularly JDBC and
Python -- have control over their own groups. And I think we need a way for
add-ins to build in a completely integrated way with the backend, including
building in docs. But these are not technically easy problems.

(I hope people understand here that I'm speaking for me, personally)

--
Josh Berkus
Aglio Database Solutions
San Francisco