Re: inclusions WAS: Increased company involvement - Mailing list pgsql-hackers

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