incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Source tree refactoring - TESTERS NEEDED
Date Mon, 27 Dec 2010 16:35:41 GMT
On Mon, Dec 27, 2010 at 7:23 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:
> On Mon, Dec 27, 2010 at 1:31 AM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
>> On Sun, Dec 26, 2010 at 7:23 PM, Benoit Chesneau <bchesneau@gmail.com> wrote:
>>> On Mon, Dec 27, 2010 at 12:53 AM, Paul Davis
>>> <paul.joseph.davis@gmail.com> 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  with 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,  *if the process allows it*. This is imo a big priority, we
> already see a lot of "bricolage"  (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?

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.

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.

Mime
View raw message