couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Apache sub-projects
Date Tue, 18 Aug 2009 02:12:57 GMT
On Mon, Aug 17, 2009 at 9:54 PM, Jan Lehnardt<> wrote:
> 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 project".
> IMHO that is just moving source files to couchdb/futon/trunk/... and setting
> up svn externals (guesswork) or symlinks for couchdb proper accordingly.

Well, I'm still operating under the "Its not nearly time for full on
subprojects" mental model. Making Futon more hackable by people
unfamiliar with the code base shouldn't require sub-project status. It
should just be easier. Granted I haven't the slightest on what that
might entail.

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

I suppose this depends on your view of whether CouchApp is 'required'
for using CouchDB. I place it in the "tool" category and as such don't
really see it as appropriate for a release tarball. if it were a
single file that ran on versions of Python back to say 2.4 and was
conditionally installed as part of the build process, then I'd be more

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

Paul Davis

View raw message