couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <robert.new...@gmail.com>
Subject Re: Apache sub-projects
Date Sun, 16 Aug 2009 20:27:06 GMT
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<jan@apache.org> wrote:
>
> On 16 Aug 2009, at 22:11, Dirkjan Ochtman wrote:
>
>> On Sun, Aug 16, 2009 at 18:21, Jan Lehnardt<jan@apache.org> 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
> --
>
>

Mime
View raw message