On Wednesday 25 November 2015, Steve Loughran <ste...@hortonworks.com> wrote:
> > > On 22 Nov 2015, at 22:34, Branko Čibej <br...@apache.org <javascript:;>> > wrote: > > > > > > The major question here, for me, is: if the project is RTC, then why > > would I make an effort to become a committer if at the end of the day > > I'm still not trusted to know when to ask for review? It'd be less work > > to throw patches at the developers and let them deal with the pain of > > reviewing and applying. > > > > what you gain as committer is not so much the right to do the housekeeping > of svn commit/git commit, it's the right to commit other people's code in > after reviewing it. > > And while anyone is encouraged to review patches on JIRA/github, etc, your > ability to +1 code says you are trusted to make changes to the code without > breaking things. That is: your knowledge of the code is deemed sufficient > to be able to review the work of others, to help guide them into a state > where it can be committed, and if not: explain why not. You just still have > to go through the same process of submission and review with your peers, so > there is a guarantee that 1 other person is always aware of what you do. > > That ability to +1 code is the right and the responsibility. I believe that to be an anti-pattern. At the Maven project, we started to track on votes which votes were from the PMC (ie binding for making a release with the legal protection of the foundation) The nett effect was a reduction of engagement from the community... When they saw these "+1 (binding)" votes being treated differently, they stopped voting on releases... So now we are trying to rebuild the engagement... Much harder after you have lost it than not to lose it in the first place. Now releases are more visible than commits, but I believe the same principle applies. With CTR anyone can be a "drive by" reviewer. With RTC the "drive by" reviewer doesn't have the same status... So it is harder to engage them and pull them into the community > > > > > How would it feel to get a mail like this: > > > > Congratulations! The developers of Project FOO invite you to become > > a committer. All your patches to date have been perfect and your > > other contributions outstanding. Of course we still won't let you > > commit your changes unless [brass hats] have reviewed and approved > > them; we operate by a review-then-commit process. The only real > > benefit of committer status is that you can now review other > > people's patches and have a binding opinion, unless [brass hats] > > have written otherwise in the bylaws. > > yes: you get to have a direct say in what goes into the codebase. > > you also get a duty: you need to review other people's work. We need to > encourage more of that in the Hadoop codebase. I know its a chore, but > Yetus is helping, as should the github integration. > > > > > P.S.: Any competent engineer will immediately see that the optimal > > way to proceed is to join an informal group of committers that > > mutually +1 each other's patches without unnecessary hassle, and/or > > ingratiate yourself with [brass hats] to achieve equivalent results. > > After all, it's all about building a healthy community, right? > > it would, though it'd stand out. And if you want things to work without > fielding support calls, you want the quality of what goes in to be high -no > matter from whom it came. > > If you work in specific part of the code, you do end up knowing the people > who also work there, their skills, their weaknesses: who is most likely to > break things. So you may show some favouritism to people you trust. > Explicit tradings of patches? Not me. > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > <javascript:;> > For additional commands, e-mail: general-h...@incubator.apache.org > <javascript:;> > -- Sent from my phone
