That's not fully correct. A committer can directly commit, all depends of the approach used in the project: commit and review or review and commit.
In Beam we decided to do review and commit. So a committer or a PMC or a contributor should create a PR. Other Apache projects allow to directly commit (or at least a PR merged quickly). Just my €0.01 ;) Regards JB Le 31 mai 2018 à 15:17, à 15:17, Robert Burke <rob...@frantil.com> 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. > >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 >>>> >>>
