Le jeudi 31 mai 2018 à 06:17 -0700, Robert Burke a écrit :
+1 I also thought this was the norm.
My read of the committer/contributor guide was that a committer couldn't
unilaterally merge their own code (approval/LGTM needs to come from someone
familiar with the component), rather than every review needs two committers. I
don't recall a requirement than each PR have two committees attached, which I
agree is burdensome especially for new contributors.
Yes me too, I thought exactly the same
>
> On Wed, May 30, 2018, 2:23 PM Udi Meiri <eh...@google.com> wrote:
> > I thought this was the norm already? I have been the sole reviewer a few
> > PRs by committers and I'm only a
> > contributor.
> > +1
> > On Wed, May 30, 2018 at 2:13 PM Kenneth Knowles <k...@google.com> wrote:
> > > ++1
> > > This is good reasoning. If you trust someone with the committer
> > > responsibilities [1] you should trust them to find
> > > an appropriate reviewer.
> > > Also:
> > >
> > > - adds a new way for non-committers and committers to bond
> > > - makes committers seem less like gatekeepers because it goes both ways
> > > - might help clear PR backlog, improving our community response latency
> > > - encourages committers to code*
> > >
> > > Kenn
> > >
> > > [1] https://beam.apache.org/contribute/become-a-committer/
> > >
> > > *With today's system, if a committer and a few non-committers are working
> > > together, then when the committer writes
> > > code it is harder to get it merged because it takes an extra committer.
> > > It is easier to have non-committers write
> > > all the code and the committer just does reviews. It is 1 committer vs 2
> > > being involved. This used to be fine when
> > > almost everyone was a committer and all working on the core, but it is
> > > not fine any more.
> > > On Wed, May 30, 2018 at 12:50 PM Thomas Groh <tg...@apache.org> wrote:
> > > > Hey all;
> > > > I've been thinking recently about the process we have for committing
> > > > code, and our current process. I'd like to
> > > > propose that we change our current process to require at least one
> > > > committer is present for each code review,
> > > > but remove the need to have a second committer review the code prior to
> > > > submission if the original contributor
> > > > is a committer.
> > > >
> > > > Generally, if we trust someone with the ability to merge code that
> > > > someone else has written, I think it's
> > > > sensible to also trust them to choose a capable reviewer. We expect
> > > > that all of the people that we have
> > > > recognized as committers will maintain the project's quality bar - and
> > > > that's true for both code they author and
> > > > code they review. Given that, I think it's sensible to expect a
> > > > committer will choose a reviewer who is versed
> > > > in the component they are contributing to who can provide insight and
> > > > will also hold up the quality bar.
> > > >
> > > > Making this change will help spread the review load out among regular
> > > > contributors to the project, and reduce
> > > > bottlenecks caused by committers who have few other committers working
> > > > on their same component. Obviously, this
> > > > requires that committers act with the best interests of the project
> > > > when they send out their code for reviews -
> > > > but this is the behavior we demand before someone is recognized as a
> > > > committer, so I don't see why that would be
> > > > cause for concern.
> > > >
> > > > Yours,
> > > >
> > > > Thomas
>
>
