couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Apache sub-projects
Date Tue, 18 Aug 2009 01:54:32 GMT

On 18 Aug 2009, at 03:13, Paul Davis wrote:

>> My understanding is also that we want an official distribution to  
>> include
>> couchdb-lounge style clustering. There's two ways to go about it:  
>> 1) put it
>> all into the source tree and disable and enable features on build  
>> time
>> (--enable-cluster) or 2) have separate trees (e.g. a core and a  
>> cluster add
>> on) that can be used to create two releases (packaging time):
>> couchdb-1.0.tar.gz and couchdb-with-cluster.tar.gz
> Erlang should allow us the flexibility to make clustering a runtime
> configuration. As you state, its can be thought of as a toolbox for
> creating db environments. If people want to shed bits of the toolbox
> to target a phone, then I think that's more of an end user concern.

Or does the PMC want to public couchdb-mobile.tar.gz?

>>  - Do we want to ship whatever release (cluster or not or both) of  
>> CouchDB
>> with a small ecosystem (Futon, CouchApp)?
>> Futon is already in "core", sub-projecting it would be merely done to
>> attract more Futon developers. Maybe that can be achieved in other  
>> ways,
>> too.
> I think making it easier for developers to start hacking on Futon
> would be pretty awesome. Though I'd put it more in the realm of us
> being creative instead of creating a full on sub project for it.

that might include confusion what it means to be a "full on sub  

IMHO that is just moving source files to couchdb/futon/trunk/... and  
up svn externals (guesswork) or symlinks for couchdb proper accordingly.

>> I think CouchApp should be a packaging-time part of CouchDB and  
>> installed by
>> default. This would add Python as a build dependency. Maybe we can  
>> make
>> ./configure smart enough to not install CouchApp and give a warning  
>> when the
>> necessary dependencies are not met. Maybe we just add to the final  
>> `make
>> install` output "Now go and install CouchApp from ...".
> It'd take a lot of convincing for me to be supportive of having
> couchapp in an apache-couchdb tarball. Especially when `sudo
> easy_install couchapp` is handy.

Imagine a CouchDB distribution where a user has everything "ready to go"
instead of having to figure out what bits and pieces are needed next.
There's a long way to go with documentation and notices in the right
places (like after make install), but e.g. package manager users don't
get to see these.

>>  - Do we want to foster plugins, extensions and other infrastructure
>> software or do we want to rely on the non CouchDB open source world  
>> to come
>> up with them?
>> I'd like to see a place like the Firefox extension development  
>> center but
>> for CouchDB plugins hosted on
> I think having a place for plugins would be great. Though I tend to
> wonder what type of requirements there would be if we hosted plugins
> at the ASF. Somehow I'd think that requiring a signed legal document
> on file would stifle widespread growth of the community.

I agree. The actual code could be distributed from some other place,
I'm not suggesting right away that all this has to be under the ASF/CLA
umbrella. Although clear steps on how to "get in" should be


View raw message