On 16/01/13 17:12, Greg Stein wrote:
> On Wed, Jan 16, 2013 at 11:55 AM, Gary Martin <gary.martin@wandisco.com> wrote:
>> On 16/01/13 16:17, Andrej Golcov wrote:
>>> Hi,
>>>
>>> Last few weeks I worked on prototype of Improved Search Architecture #285
>>> [1]
>>> It looks like resulting code becoming bigger and more complex than it
>>> was expected at the begging. That leads to sending of big patch files
>>> which are difficult to review and manage.
>>>
>>> I suggest a new "bhsearch" branch is created where I have commit
>>> access. In this cas, I can commit more granular changes on this branch
>>> and people can see changes and feedback earlier. When functionality is
>>> stable, merge request to trunk will be asked.
>>>
>>> What do you think?
>>
>> Unfortunately I don't think we can do that at this point. Give us a little
>> time and we may be able to come up with other solutions but in my
>> experience, more little patches tend to be easier to review and provide
>> better opportunities to discuss ideas as they shape up.
> Huh? For large or complicated features, what is wrong with a branch
> where we can observe the incremental progress?
>
> This is especially good for experiments, where it isn't certain the
> result will be accepted. At any point, we can simply say "darn. didn't
> work." and rm the branch with no effect to trunk.
>
> (in general, I prefer trunk for all *known-accepted* work)
>
> Cheers,
> -g

Well, I was only referring to commit rights unless you know better!

I have nothing specific against the branch idea although I think that 
this work could be developed on trunk anyway as it is functionality that 
can be turned off.

Cheers,
     Gary