couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
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<jan@apache.org> 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
willing.

>
>>
>>>  - 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 http://couchdb.apache.org.
>>
>> 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

Mime
View raw message