incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Source tree refactoring - TESTERS NEEDED
Date Mon, 27 Dec 2010 17:24:26 GMT
On Mon, Dec 27, 2010 at 5:35 PM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> 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?

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.

Mime
View raw message