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

Centuries ago, Nostradamus foresaw when josh@agliodbs.com (Josh Berkus) would write:
> 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.

There have been efforts in 7.4 and ongoing to make it easier to have
more software behave rather like the /contrib stuff.

The thing that has been a Real Pain is when extensions required a full
source tree simply because of needing access to a few extra #includes
and such.

In v8, the expansion of the default #includes means that what used to
require a tarball can now just point to #includes and libraries,
making it way easier to live outside /contrib.

This is a Good Thing, particularly for those building .deb and .rpm
packages, as they can build these without needing some
near-arbitrarily-big PG build tree.

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

Of course, he's in the process of "git'ting" to a new system called
"git."

And it's worth observing that BK/git/whatever are only being used to
manage the Linux kernel.

A fairer comparison would be the BSD core systems.  I believe that
most of them have a considerably larger set of stuff in the "central
CVS"...

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

Of course.  For me, these _are_ technically easy problems ;-).  

Just kidding!  Those sound like potentially valuable things that are
doubtless difficult to achieve...
-- 
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','gmail.com').
http://linuxdatabases.info/info/emacs.html
MICROS~1:  Where do you  want to  go today?   Linux: Been  there, done
that.