Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of robert.newson@gmail.com
 designates 209.85.218.209 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=v9vTZPRsVuz84uf5hxWR8hvaMZ48CpvXC8+NMKk+fwchxD8YGFipNOekZpyv1Dk7wW
         VrwbopHfMk+T43zc1fwZe7RGzhaOhUrI5yuAOcKBBjtU1mnSkyigN+trLV2x6xUZRqt3
         QV/vrb6vjTGcQ1PWJ4CRIgipkORjA53uYzy1Q=
MIME-Version: 1.0
In-Reply-To: <78B8AD65-124B-4F18-9B4F-DF5D420F8709@apache.org>
References: <e282921e0908132352u506f09dfjdcf4fad0145d7c0d@mail.gmail.com>
	 <29A7E6D0-4C8A-4986-9C02-4316A36FFD90@apache.org>
	 <ea2499da0908161311y6e08494s8d114438805e42c7@mail.gmail.com>
	 <78B8AD65-124B-4F18-9B4F-DF5D420F8709@apache.org>
Date: Sun, 16 Aug 2009 21:27:06 +0100
Message-ID: <46aeb24f0908161327v7e901344hae11b1e1f19d9ba1@mail.gmail.com>
Subject: Re: Apache sub-projects
From: Robert Newson <robert.newson@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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:
>>>
>>> =A0- The developers are currently the CouchDB committers and we
>>> =A0got contributions small and big from users through patches.
>>>
>>> =A0- A future Futon-only developer doesn't necessarily have to know
>>> =A0any Erlang and I'd trust her to not touch that part of the code
>>> =A0until everybody feeling comfortable with this. (Besides, Erlang is
>>> =A0so simple on the couch_http_*-end that small fixes in the HTTP
>>> =A0API could be done without much hassle). And we're using SVN,
>>> =A0if any unwanted changes, accidental or deliberate are introduced,
>>> =A0we'll revert them.
>>>
>>> =A0- Futon always has to be current with CouchDB, even through
>>> =A0trunk-only development phases. Splitting this out to a separate
>>> =A0schedule doesn't make much sense to me.
>>>
>>> =A0- Working on Futon is a great way for new developers to get into
>>> =A0CouchDB 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
> --
>
>