Agree, it sounds good to me. That's basically what I proposed to the Euphoria DSL team ;)
Regards JB On 31/05/2018 20:35, Pablo Estrada wrote: > In that case, does it make sense to say: > > - A code review by a committer is enough to merge. > - Committers can have their PRs reviewed by non-committers that are > familiar with the code > - Non-committers may have their code reviewed by non-committers, but > should have a committer do a lightweight review before merging. > > Do these seem like reasonable principles? > -P. > > On Thu, May 31, 2018 at 11:25 AM Jean-Baptiste Onofré <j...@nanthrax.net > <mailto:j...@nanthrax.net>> wrote: > > In that case, the contributor should be a committer pretty fast. > > I would prefer to keep at least a final validation from a committer to > guarantee the consistency of the project and anyway, only committer role > can merge a PR. > However, I fully agree that the most important is the Beam community. I > have no problem that non committer does the review and ask a committer > for final one and merge. > > Regards > JB > > On 31/05/2018 19:33, Andrew Pilloud wrote: > > If someone is trusted enough to review a committers code shouldn't > they > > also be trusted enough to review another contributors code? As a > > non-committer I would get much quicker reviews if I could have other > > non-committers do the review, then get a committer who trusts us > to merge. > > > > Andrew > > > > On Thu, May 31, 2018 at 9:03 AM Henning Rohde <hero...@google.com > <mailto:hero...@google.com> > > <mailto:hero...@google.com <mailto:hero...@google.com>>> wrote: > > > > +1 > > > > On Thu, May 31, 2018 at 8:55 AM Thomas Weise <t...@apache.org > <mailto:t...@apache.org> > > <mailto:t...@apache.org <mailto:t...@apache.org>>> wrote: > > > > +1 to the goal of increasing review bandwidth > > > > In addition to the proposed reviewer requirement change, > perhaps > > there are other ways to contribute towards that goal as well? > > > > The discussion so far has focused on how more work can get > done > > with the same pool of committers or how committers can get > their > > work done faster. But ASF is really about "community over > code" > > and in that spirit maybe we can consider how community growth > > can lead to similar effects? One way I can think of is that > > besides code contributions existing committers and especially > > the PMC members can help more towards growing the committer > > base, by mentoring contributors and helping them with their > > contributions and learning the ASF way of doing things. That > > seems a way to scale the project in the long run. > > > > I'm not super excited about the concepts of "owner" and > > "maintainer" often found in (non ASF) projects like Kenn > > mentions. Depending on the exact interpretation, these > have the > > potential of establishing an artificial barrier and limiting > > growth/sustainability in the contributor base. Such powers > tend > > to be based on historical accomplishments vs. current > situation. > > > > Thanks, > > Thomas > > > > > > On Thu, May 31, 2018 at 7:35 AM, Etienne Chauchot > > <echauc...@apache.org <mailto:echauc...@apache.org> > <mailto:echauc...@apache.org <mailto:echauc...@apache.org>>> wrote: > > > > 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 <mailto:eh...@google.com> > >> <mailto:eh...@google.com <mailto: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 <mailto:k...@google.com> > <mailto:k...@google.com <mailto: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 <mailto:tg...@apache.org> > <mailto:tg...@apache.org <mailto: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 > > > > > > -- > -- > Jean-Baptiste Onofré > jbono...@apache.org <mailto:jbono...@apache.org> > http://blog.nanthrax.net > Talend - http://www.talend.com > > -- > Got feedback? go/pabloem-feedback -- -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
