On Tue, Aug 16, 2011 at 6:45 AM, Jan Lehnardt <[email protected]> wrote: > 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 > -- >
Early morning pre-caffeine but this sounds like a pretty good idea to my addled brain. > > 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 > >
