From dev-return-13925-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Mon Dec 27 17:24:55 2010 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 90427 invoked from network); 27 Dec 2010 17:24:55 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 27 Dec 2010 17:24:55 -0000 Received: (qmail 503 invoked by uid 500); 27 Dec 2010 17:24:54 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 470 invoked by uid 500); 27 Dec 2010 17:24:54 -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 462 invoked by uid 99); 27 Dec 2010 17:24:54 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Dec 2010 17:24:54 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,RFC_ABUSE_POST,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of bchesneau@gmail.com designates 209.85.210.180 as permitted sender) Received: from [209.85.210.180] (HELO mail-iy0-f180.google.com) (209.85.210.180) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Dec 2010 17:24:47 +0000 Received: by iyi12 with SMTP id 12so8297377iyi.11 for ; Mon, 27 Dec 2010 09:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ojsqziOItdLScxNiCz6a68AP0VtXm51reTZGmrV2Uds=; b=FXeWtEAXHvOPCfrUpOdBDY6OssqiAFbwB584/sQwllHRifArP4QR7S9++uGUdPpsOL qVIVbTeLU13MOZHPrVEuz+phVC146P0uTnTzNgMPkxqZ+7IKqjVya9HAI1cAycb5Lvqy Ov5eSzBrzYOOIG2I1lQRrw35L+sI6Y4RqKqZY= 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=FEd3HGSvq7sADzl7TswgD2A4p6tb7KZ+NfklnXLZqwvlswdJP6IS0aAPIVcv0aI5jv J0gMYBrkMigxkuYw8z5Zh2Ul3inpw6luvh3yIRRjUSfvL79uTlTPCU/MDytwwrdsv98K 8Qcx5iJRkz9rFxJz1q/SdTsg/ZfbcAhgLeOL8= MIME-Version: 1.0 Received: by 10.231.144.21 with SMTP id x21mr12381684ibu.30.1293470666219; Mon, 27 Dec 2010 09:24:26 -0800 (PST) Received: by 10.231.205.130 with HTTP; Mon, 27 Dec 2010 09:24:26 -0800 (PST) In-Reply-To: References: Date: Mon, 27 Dec 2010 18:24:26 +0100 Message-ID: Subject: Re: Source tree refactoring - TESTERS NEEDED From: Benoit Chesneau 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, Dec 27, 2010 at 5:35 PM, Paul Davis w= rote: > On Mon, Dec 27, 2010 at 7:23 AM, Benoit Chesneau wr= ote: >> On Mon, Dec 27, 2010 at 1:31 AM, Paul Davis wrote: >>> On Sun, Dec 26, 2010 at 7:23 PM, Benoit Chesneau = wrote: >>>> On Mon, Dec 27, 2010 at 12:53 AM, Paul Davis >>>> wrote: >>>> >>>>> >>>>> Its not being done in trunk. The change is being prepared as a script >>>>> and set of patches that people can test independently which people >>>>> have been doing. >>>>> >>>> Not what I say. Was about testing it first in it's own branch. But >>>> right patches are enough. Just actually i'm not sure how i can edit >>>> one or go further ? Another patch ? What's your process to make such >>>> patches at first ? stashes ? >>>> >>> >>> I use the generated git repo to formulate all of the various patches. >>> There are git-save and git-restore commands for the srcmv.py script >>> that work as expected by saving patches to the couchdb.patches >>> directory. >>> >> Will try to work =A0with that then. >> >>> This is a scenario that is so distant I'm not going to spend time >>> thinking about it right now. The current work would in no way allow >>> for someone to do such things and it will be many many months before >>> we have things to a point before we can entertain such notions. >>> >> >> It could be months or days. Depends on the the time each others can >> put in it, =A0*if the process allows it*. This is imo a big priority, we >> already see a lot of "bricolage" =A0(makeshift?) coming in the code. >> >> The goal I wished in the thread I launched was to use rebar and mix it >> with configure (based on bigcouch work and patches like these one). I >> don't see how the question is so distant seeing the result of these >> patches. Neither I see why we shouldn't target this right now. Anyway, >> maybe we can open a ticket and track progress in it ? > > I'm so confused. What process are you talking about? What breakage (I > assume that's what you mean) do you see coming? I'm speaking about a way to work with such changes. Patches are good, but in the mean time vcs are here for a reason. A quick way to test/merge etc. I'm just looking for a way to work with the patch between different person. Trying to find a way to make the process easy. > > You're describing two entirely different, completely unrelated use > cases for rebar. One, which was part of the motivation for this patch > set, was to integrate it into the build system. This is perfectly > acceptable. It is why this patch set exists; to make using rebar to > build CouchDB *possible*. After this very large patch set is committed > then we can start working on supporting rebar. > Well I don't describe unrelated use, just describing what I wished, and started thread, that wasn't closed nor really discussed. Now I understand that the patches won't go as far as I would like. > The situation you described earlier is a bajillion percent different. > Perhaps in a distant future we will support using only various parts > of CouchDB but this is a scenario so far distant that I am not going > to spend any time considering it. > I understand that.