+1 For a merge from master to the feature branch that does not require extra changes, RTC does not add value. It actually delays and burns reviewer time (even mechanics need some) that "real" PRs could benefit from. If adjustments are needed, then the regular process kicks in.
Thanks, Thomas On Wed, Oct 26, 2016 at 1:33 AM, Amit Sela <[email protected]> wrote: > 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 <[email protected]> > wrote: > > > On Tue, Oct 25, 2016 at 9:44 PM, Jean-Baptiste Onofré <[email protected]> > > 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. > > >
