fwiw: I've seen non-standard svn layouts before and it never ends well. +1 on trunk/tags/branches idiom.
B. On Sun, Aug 16, 2009 at 9:23 PM, Jan Lehnardt<[email protected]> wrote: > > 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 > -- > >
