[Twisted-Python] Permissions to trigger buildbot tests

[Adi Roiban]

On 16 November 2014 22:44, <exarkun at twistedmatrix.com> wrote:

> 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".


I got them.

Is there a wiki page describing how buildbot should be used?

I found some notes hidden in the review process page... it looks like
builds are triggered from the web page with click.
The review page also talks about a misterious force-builds.py script which
is not part of the main twisted repo.. or at least, I could not found it

I was expecting a buidbot try scheduler  and use buildbot command line
tools to trigger remote tests



>> --------
>>
>> 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.
>

Ok. In this case, maybe just a note that developers should send enough
patches and do enough "junior reviews" until their patches are submitted
for the first time without major errors and no major errors pass their
initial review.. this is close to common sense, but some might argue that
there is no such thing as common sense.


-- 
Adi Roiban
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20141117/34e361ac/attachment-0002.html>