On 16 Aug 2009, at 22:11, Dirkjan Ochtman wrote:
On Sun, Aug 16, 2009 at 18:21, Jan Lehnardt<[email protected]> 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 :)
* http://couchdbkit.org/
Cheers
Jan
--
