[Twisted-Python] Permissions to trigger buildbot tests

[exarkun at twistedmatrix.com]

On 10:04 am, adi at 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