Hi Benoit,
thanks for raising this again. I think we have a good plan to get started but
it wouldn't hurt to get a little more organised. I think the plan is as follows:
1. Move to git, this makes all the subsequent steps more easy.
2. srcmv, reorganising the source code so we are prepared to do all the things
you mention and all the other things we talked about in the past :)
3. Profit.
--
As for my wish list, all this post the git move:
We could release 1.2 based off of current trunk + a few of the more
useful JIRA patches that we haven't committed yet.
After 1.2.x is branched, srcmv trunk and start the internal refactoring
and pluginnifying and release 1.3 off that.
At some point merging between before and after srcmv merging
patches is going to be a pain, so I'd like to keep that time as short
as possible and thus keep the differences between 1.2 and 1.3 (given
that these are the border cases) as small as possible.
Cheers
Jan
--
On Aug 16, 2011, at 1:20 PM, Benoit Chesneau wrote:
> Hi devs;
>
> Today I see lot of interesting things coming in CouchDB, but also lot of
> different interests and different usages. Sometimes you need to extend
> couch for your usage. But today if you except the current work on the
> view engine by paul, the couchdb code become more and more monolithic or
> an aggregation of code adding some specific features/changes, while not
> envisioning what could be done by others. Also the way you have to
> extend couchdb make it difficult today to use/merge/... different forks
> around like the one done by cloudant, couchbase and even mine in
> refuge/upondata probably some others too). Couch core should be
> lighter and more open (in its strict sense).
>
> For example today, http layer(?), replicator(?), proxy, external
> daemons, couchapp engine, rewriter, vhosts, compaction daemon, some auth
> handler could be available as plugins. couch_config could be more
> generic and not relying on an ini file. More specifically we could have
> a couch core looking more like a mnesia alternative, the couchdb
> application, which could be couch core + plugins, distributed as a
> standalone app (like couchdb is actually). This would also maybe allow
> cloudant, couchbase and other to reuse the same core rather than forking
> it while adding their own plugins. Official Plugins could also be
> maintained as standalone projects maybe.
>
>
> I wish we could concentrate on that topic for 2.0x and make it a
> priority. That would imply to define what is the couch core, split the
> code [1] and what is a plugin [2]. Maybe the couchdb app can also be a
> full erlang release [3] built with autotools. I think that this
> plugabble structure should be done for example before adding any new
> daemon like the compaction daemon. Don't get me wrong I really like the
> idea to have a default compaction daemon in the couchdb app, and this is
> just an example. But I also want the possibility to add mine working
> differently (or not) and this should be done for the default couchdb
> release, couch core imo should be more neutral.
>
> Maybe we could start by opening tickets about different tasks to track
> them? What is blocking the split currently since the 1.0.3 is out? Do
> we wait for the svn-to-git conversion?
>
> - benoît
>
> [1] https://github.com/davisp/couchdb-srcmv
> [2] https://issues.apache.org/jira/browse/COUCHDB-1012
> [3] http://www.erlang.org/doc/design_principles/release_structure.html
