On 10:04 am, adi@roiban.ro wrote:
Hi,
To help with the review process I would like to ask permissions for triggering buildbot builds.
Is there a wiki page describing what are the steps required for a regular contributor to get permissions to run buildbot tests and get write access to the repo?
I'll send you the credentials off-list. FWIW, this is password protected only because spambots found the form and kept triggering garbage builds. There's no standard policy or procedure for granting commit access to the repository. Usually it goes like "someone asks for it, someone gives it to them".
--------
In the same time, maybe we can write a few words about the steps required for a new contributor to become a full reviewer. Ex.
There is no official process but the frequently discussed unofficialy process is just getting commit access. The project doesn't distinguish between committers in any way as far as the development workflow is concerned. Perhaps it should and we should discuss how it could do this.
1. Contribute a few patches (ex 10) and learn the basic review process. Observe how reviewers respond to your patch.
2. Start doing review as junior reviewer, without merging. Once you are ok with the patch, invite another core developer to take a final view and merge the patch
3. Once you have reviewed a few patches without errors (ex 10) you can ask for full review permission or a core developer will let you know that you can merge the patch without asking someone else.
This can be part of the current review process page: https://twistedmatrix.com/trac/wiki/ReviewProcess
What do you think?
I think this process probably involves little enough learning that it won't make a significant difference to the quality of code reviews done for the project (so it will only add overhead to the process of keeping track of different kinds of reviewers and where in their progression "junior" reviewers are). A modification that would help very slightly (but I think still not enough to be worthwhile, particularly since it adds even more overhead) would be to require a correct review covering each of the many relevant areas - for example, howto-style docs, example-style docs, api-style docs, unit test coverage, coding convention compliance (whitespace, variable naming, etc), etc. After demonstrating competence in all areas the "junior" reviewer could advance to normal review status. Unfortunately notice I didn't say anything about the software being built or changed itself. I don't know of an easy way to test folks for competence at that kind of thing except to see them write a lot of code. Jean-Paul