Sub-Projects

[Ryan Ramage <ry...@gmail.com>]

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

Re: Sub-Projects

[Paul Davis <pa...@gmail.com>]

On Wed, Oct 24, 2012 at 11:15 AM, Ryan Ramage <ry...@gmail.com> 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).