On Wed, Jan 16, 2013 at 12:18 PM, Gary Martin <[email protected]> wrote: > 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!
Commit rights are easy. He sends in an ICLA, we issue an account request, and in a few hours he'll have an account. And with our relaxed ACL, he'll be able to start work on the branch right away. Easy peasy. Cheers, -g
