> On 22 Nov 2015, at 22:34, Branko Čibej <br...@apache.org> 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. > 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 For additional commands, e-mail: general-h...@incubator.apache.org
