On Mon, Aug 17, 2009 at 9:54 PM, Jan Lehnardt<[email protected]> 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
