Great, let's document that in the feature branch section of the contribution guide: http://beam.incubator.apache.org/contribute/contribution-guide/#feature-branches
Anyone want to take that? On Thu, Oct 27, 2016 at 1:01 PM, Kenneth Knowles <k...@google.com.invalid> wrote: > In the spirit of explicitly summarizing and concluding threads on list: I > think we have affirmative consensus to go for it when a downstream > integration is completely conflict-free and fixup-free. > > On Thu, Oct 27, 2016 at 12:43 PM Robert Bradshaw > <rober...@google.com.invalid> wrote: > > > My concern was mostly about what to do in the face of conflicts, but > > it sounds like the consensus is that for a clean merge, with no > > conflicts or test breakage (or other concerns) a committer is free to > > push without any oversight which is fine by me. > > > > [If/when the Mergbot comes into action, and runs more extensive tests > > than standard precommit, it might make sense to still go through that > > rather than debug bad merges discovered in postcommit tests.] > > > > On Wed, Oct 26, 2016 at 9:07 PM, Davor Bonaci <da...@google.com.invalid> > > wrote: > > > +1 > > > > > > I concur it is fine to proceed with a downstream integration (master -> > > > feature branch -> sub-feature branch) without waiting for review for a > > > completely clean merge. Exactly as proposed -- I think there should > still > > > be a pull request and comment saying it is a clean merge. (In some > ideal > > > world, this would happen nightly by a tool automatically, but I think > > > that's not feasible in the short term.) > > > > > > I think other cases (upstream integration, merge conflict, any manual > > > action, etc.) should still wait for a normal review. > > > > > > On Wed, Oct 26, 2016 at 10:34 AM, Thomas Weise <t...@apache.org> wrote: > > > > > >> +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 <amitsel...@gmail.com> > > 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 > <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. > > >> > > > > >> > > > >> > > >
