On 16/01/13 17:12, Greg Stein wrote:
On Wed, Jan 16, 2013 at 11:55 AM, Gary Martin <[email protected]> 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
