I generally agree with Kenneth. While working on the SparkRunnerV2 branch, it was a pain - i avoided frequent merges to avoid trivial PRs, but it cost me with very large and non-trivial merges later. I think that frequent merges for feature-branches should most of the time be trivial (no conflicts) and a committer should be allowed to self-merge once tests pass. As for conflicts, even for the smallest once I'd go with review just so it's very clear when self-merging is OK - we can always revisit this later and further discuss if we think we can improve this process.
I guess +1 from me. Thanks, Amit. On Wed, Oct 26, 2016 at 8:10 AM Frances Perry <f...@google.com.invalid> wrote: > On Tue, Oct 25, 2016 at 9:44 PM, Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > > > 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. > > > > This thread is about the opposite, I think -- merging master into feature > branches regularly to prevent them from getting out of sync. > > As for increasing the visibility of feature branches, we have these new > webpages: > http://beam.incubator.apache.org/contribute/work-in-progress/ > http://beam.incubator.apache.org/contribute/contribution- > guide/#feature-branches > with more changes coming in the basic SDK/Runner landing pages too. >
