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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
