Agree. When possible it would be great to have the branch merged on master quickly, even when it's not fully ready. It would give more visibility to potential contributors.
Regards JB On Oct 25, 2016, 23:34, at 23:34, Kenneth Knowles <k...@google.com.INVALID> wrote: >Hi all, > >While collaborating on the apex-runner branch, the issue of how best to >continuously merge master into the feature branch came up. IMO it >differs >somewhat from normal commits in two notable ways: > >1. Modulo fix-ups, it is actually not adding any new code to the >overall >codebase, so reviews don't serve to raise the quality bar for >contributions. >2. It is pretty important to do very frequently to keep out of trouble, >so >friction must be thoroughly justified. > >I really wouldn't want reviewing a daily merge from master to consume >someone's time every day. On the gearpump-runner branch we had some >major >review latency problems. Obviously, I'd like to hear from folks on >other >feature branches. How has this process been for the Python SDK? > >I will also throw out an idea for a variation in process: > >1. A committer merges master to their feature branch without >conflicts.* >2. They open a PR for the merge. >3a. If the tests pass without modifications _the committer self-merges >the >PR without waiting for review_. >3b. If there are any adjustments needed, these go in separate commits >on >the same PR and the review process is as usual (the reviewer can review >just the added commits). > >What do you think? Does this treat such merges too blithely? This is >meant >just as a starting point for discussion. > >Kenn > >* There should never be real conflicts unless something strange has >happened - the feature can't be edited on the master branch, and master >stuff shouldn't be touched on the feature branch.
