Re: inclusions WAS: Increased company involvement

Centuries ago, Nostradamus foresaw when josh(at)agliodbs(dot)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.