From dev-return-5943-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Tue Aug 18 02:13:10 2009
Return-Path:
Delivered-To: apmail-couchdb-dev-archive@www.apache.org
Received: (qmail 36470 invoked from network); 18 Aug 2009 02:13:10 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
by minotaur.apache.org with SMTP; 18 Aug 2009 02:13:10 -0000
Received: (qmail 47392 invoked by uid 500); 18 Aug 2009 02:13:29 -0000
Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org
Received: (qmail 47307 invoked by uid 500); 18 Aug 2009 02:13:28 -0000
Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@couchdb.apache.org
Delivered-To: mailing list dev@couchdb.apache.org
Received: (qmail 47297 invoked by uid 99); 18 Aug 2009 02:13:28 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Aug 2009 02:13:28 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.210.204 as permitted sender)
Received: from [209.85.210.204] (HELO mail-yx0-f204.google.com) (209.85.210.204)
by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 Aug 2009 02:13:19 +0000
Received: by yxe42 with SMTP id 42so4537128yxe.13
for ; Mon, 17 Aug 2009 19:12:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:in-reply-to:references
:date:message-id:subject:from:to:content-type
:content-transfer-encoding;
bh=q0xqMfIDmwB0tEAmDuBEbmp459A/buzeYR/GgUGqTkM=;
b=kmBmnuK+xIM6UM2omOytqrZzf+DFR7Nlpd1aP3jsGyEiw51RKNNQVcgZVLqlhKNUrA
qxQ8EYlTxqhtbg7rkb4xufqRA24ttuFmNOuGIzm30DhLUf3x4CKQcLsY8epH+H1IruNs
kbYDv4ZTI7zcsM/Hrt1nlQrFCmueTVHBf48Xg=
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=GUN+NoPUlntyFR4snSonPE8/+pCQueKn62HOQENMU5JvbaZr88O+k3IyhSuolcMCnH
PTwiadhDcu5QwnK12Q0nFz5ZQB2b6i2Gm3MnkzAUCZouplgOG1gnMSp6IBF8qc2v+xOR
cJcjz6y+F86SCaxaHbX0FydRHSLmJkRX/FD10=
MIME-Version: 1.0
Received: by 10.101.57.4 with SMTP id j4mr4397963ank.104.1250561577743; Mon,
17 Aug 2009 19:12:57 -0700 (PDT)
In-Reply-To:
References:
<87900BD8-9FA2-4EA4-BA8B-A6F3CE1D826D@apache.org>
Date: Mon, 17 Aug 2009 22:12:57 -0400
Message-ID:
Subject: Re: Apache sub-projects
From: Paul Davis
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Checked: Checked by ClamAV on apache.org
On Mon, Aug 17, 2009 at 9:54 PM, Jan Lehnardt wrote:
>
> On 18 Aug 2009, at 03:13, Paul Davis wrote:
>
>>> My understanding is also that we want an official distribution to inclu=
de
>>> couchdb-lounge style clustering. There's two ways to go about it: 1) pu=
t
>>> it
>>> all into the source tree and disable and enable features on build time
>>> (--enable-cluster) or 2) have separate trees (e.g. a core and a cluster
>>> add
>>> on) that can be used to create two releases (packaging time):
>>> couchdb-1.0.tar.gz and couchdb-with-cluster.tar.gz
>>>
>>
>> Erlang should allow us the flexibility to make clustering a runtime
>> configuration. As you state, its can be thought of as a toolbox for
>> creating db environments. If people want to shed bits of the toolbox
>> to target a phone, then I think that's more of an end user concern.
>
> Or does the PMC want to public couchdb-mobile.tar.gz?
>
>>
>>> =A0- Do we want to ship whatever release (cluster or not or both) of
>>> CouchDB
>>> with a small ecosystem (Futon, CouchApp)?
>>>
>>> Futon is already in "core", sub-projecting it would be merely done to
>>> attract more Futon developers. Maybe that can be achieved in other ways=
,
>>> too.
>>
>> I think making it easier for developers to start hacking on Futon
>> would be pretty awesome. Though I'd put it more in the realm of us
>> being creative instead of creating a full on sub project for it.
>
> that might include confusion what it means to be a "full on sub project".
>
> IMHO that is just moving source files to couchdb/futon/trunk/... and sett=
ing
> up svn externals (guesswork) or symlinks for couchdb proper accordingly.
>
Well, I'm still operating under the "Its not nearly time for full on
subprojects" mental model. Making Futon more hackable by people
unfamiliar with the code base shouldn't require sub-project status. It
should just be easier. Granted I haven't the slightest on what that
might entail.
>
>>> I think CouchApp should be a packaging-time part of CouchDB and install=
ed
>>> by
>>> default. This would add Python as a build dependency. Maybe we can make
>>> ./configure smart enough to not install CouchApp and give a warning whe=
n
>>> the
>>> necessary dependencies are not met. Maybe we just add to the final `mak=
e
>>> install` output "Now go and install CouchApp from ...".
>>
>> It'd take a lot of convincing for me to be supportive of having
>> couchapp in an apache-couchdb tarball. Especially when `sudo
>> easy_install couchapp` is handy.
>
> Imagine a CouchDB distribution where a user has everything "ready to go"
> instead of having to figure out what bits and pieces are needed next.
> There's a long way to go with documentation and notices in the right
> places (like after make install), but e.g. package manager users don't
> get to see these.
>
I suppose this depends on your view of whether CouchApp is 'required'
for using CouchDB. I place it in the "tool" category and as such don't
really see it as appropriate for a release tarball. if it were a
single file that ran on versions of Python back to say 2.4 and was
conditionally installed as part of the build process, then I'd be more
willing.
>
>>
>>> =A0- Do we want to foster plugins, extensions and other infrastructure
>>> software or do we want to rely on the non CouchDB open source world to
>>> come
>>> up with them?
>>>
>>> I'd like to see a place like the Firefox extension development center b=
ut
>>> for CouchDB plugins hosted on http://couchdb.apache.org.
>>
>> I think having a place for plugins would be great. Though I tend to
>> wonder what type of requirements there would be if we hosted plugins
>> at the ASF. Somehow I'd think that requiring a signed legal document
>> on file would stifle widespread growth of the community.
>
> I agree. The actual code could be distributed from some other place,
> I'm not suggesting right away that all this has to be under the ASF/CLA
> umbrella. Although clear steps on how to "get in" should be
> documented.
>
Paul Davis