On Wed, Oct 24, 2012 at 11:15 AM, Ryan Ramage <[email protected]> wrote: > Hey all, > > I just wanted to poke around how to approach the idea of couchdb > 'sub-projects' or project dependencies. I will give two up and coming > examples: > > 1. Futon.Next > 2. Bundled ddoc/couchapp tool ( > https://issues.apache.org/jira/browse/COUCHDB-1574) > > I *think* both of these projects probably would be best handled > outside of the couchdb source tree and be integrated into couch via > the build process. Maybe git submodules, or something that is still to > be decided. Regardless of the technology choice, here are some > questions I have no idea about. > > 1. Licence. For sure they will be Apache licensed to be compatible. > But is there some 'donate to Apache' process we have to go through? > 2. Management. It would be nice to have releases of these projects > that fall outside the cadence of the couchdb release process. Just a > confirming that this is ok? > 3. Commit bits. It would be nice if the projects were just github > first, pull request accepting, forking style projects, with no > structured overhead. The couchdb project would just point to the best > fork. > > I tread lightly here, and hope not to stir bees. I ask out of my > ignorance, and for some clarity direction for those involved in the > work. > > Thanks! > > Ryan
There's two basic approaches that we can take here. Either we can make these actual ASF sub-projects (and thus, subject to all ASF rules/regulations/benefits) or we can just refer to community run projects and be sure to note that they are not official Apache products. For the couchapp tool, I think that a community project is probably the best method. We could probably include a section in the CouchDB docs that gives a brief description of the general class of tool and how they work and why, and then leave links to some of the more popular projects. For Futon, I think we'd be wanting to distribute the code along with each Apache CouchDB release which means it should be under the purview of the ASF. Although, I also don't think that this should be an actual sub-project with a different release cycle (unless we're planning on decoupling Futon from CouchDB, but I haven't seen any mention of that). Thus, I would just say that as new people start working on Futon.Yay we just need to be proactive in recruiting them as committers to encourage continued development (as opposed to just the bugfixes that Futon.Old has been living on for a few years).
