couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Apache sub-projects
Date Sun, 16 Aug 2009 20:23:03 GMT

On 16 Aug 2009, at 22:11, Dirkjan Ochtman wrote:

> On Sun, Aug 16, 2009 at 18:21, Jan Lehnardt<> wrote:
>> In a project as big as PHP, this makes sense and was needed
>> badly. CouchDB is not that big yet. I'd say let's figure out how
>> to incorporate sub projects into our subversion tree (e.g.
>> couchdb/trunk is couchdb-trunk, where do sub projects go?
>> couchdb/projects/...?) and how to make releases (separate or
>> bundled with CouchDB, Futon e.g. could be bundled and
>> couchdb-lucene a separate package) and worry about splitting
>> out independent sub projects when when the need arises.
> As someone who is involved in a lot of repository migrations (to
> DVCS), please don't do any weird layouts. If you're going to do
> trunk/tags/branches, put every project on the same level and t/b/t in
> each of them. For source code, facilitating your way out of a specific
> system is a good idea.

That'd mean reorganising SVN, but I'd be okay with that unless
somebody can point out significant drawbacks.

>> Futon:
>>  - The developers are currently the CouchDB committers and we
>>   got contributions small and big from users through patches.
>>  - A future Futon-only developer doesn't necessarily have to know
>>   any Erlang and I'd trust her to not touch that part of the code
>>   until everybody feeling comfortable with this. (Besides, Erlang is
>>   so simple on the couch_http_*-end that small fixes in the HTTP
>>   API could be done without much hassle). And we're using SVN,
>>   if any unwanted changes, accidental or deliberate are introduced,
>>   we'll revert them.
>>  - Futon always has to be current with CouchDB, even through
>>   trunk-only development phases. Splitting this out to a separate
>>   schedule doesn't make much sense to me.
>>  - Working on Futon is a great way for new developers to get into
>>   CouchDB via simpler, more familiar means (web development).
> Having Futon as a somewhat separate project sounds interesting. I've
> been porting another site to CouchDB over the past week, and I've been
> having some ideas (but putting up a CouchDB snapshot has prevented me
> from hacking on it so far -- making that easier would be
> interesting...). A major detriment to my last Futon patch was also the
> fact that it sat untouched in JIRA for months, which wasn't very
> motivating. (It eventually got applied, but without mentioning so on
> the bug, so I didn't even know about that... Kind of a pity, that.)

I'm sorry to hear, we need to be more careful. Sometimes something
gets patched that corresponds to a ticket that the committer is not
aware of.

> Relatedly, I wonder if couchdb-python would also be a good fit for
> being a subproject. Note that both Futon and couchdb-python have
> suffered a bit in the past from the fact that the primary author has
> had little time to deal with patches, bugs, etc. That happens to
> everyone, but it would be nice if we could prevent the projects from
> stalling as much as possible.

I'd be -1 on client libraries to becoming sub-projects. At least for now
where there's still significant styles being worked out. Down the road,
I can see that being useful.

That said, couchdb-python could do with a larger, more active
community. E.g. Benoit's couchdbkit* kicks couchdb-python's
online presence's butt :) Not blaming anyone, just trying to
encourage :)



View raw message