On 10:04 am, a...@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
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
