Changes between Version 75 and Version 76 of ReviewProcess


Ignore:
Timestamp:
01/23/17 01:14:30 (5 years ago)
Author:
Jean-Paul Calderone
Comment:

talk about the extra PR dance

Legend:

Unmodified
Added
Removed
Modified
  • ReviewProcess

    v75 v76  
    4646 * Make sure that it's **green**! [wiki:ContinuousIntegration/DeveloperWorkflow Trigger a build if it was not done yet].
    4747  * There is one caveat to this rule. If one of the tools that we use to verify the code, such as `pydoctor`, `twistedchecker` or `pyflakes`, causes a build to fail, but for a reason that has to do with a bug in the tool rather than a problem with the code, file the bug in the tool, and then link from the bug report to the twisted ticket where you saw the spurious failure.  You can [https://github.com/twisted/twistedchecker/issues file bugs in twistedchecker here], [https://github.com/twisted/pydoctor/issues pydoctor here], or [https://launchpad.net/pyflakes pyflakes here].  Don't block a branch on a tool bug, but also, don't let any spurious failures go without filing an appropriate bug on the relevant tool first.
     48  * If the contributor lacks permission to create branches in the official Twisted repository on github (`twisted/twisted`), you will need to push it to the official Twisted repository after a security review to cause all of the CI builders to process the branch.  After verifying the change is not an attack on the CI system, use `admin/pr_as_branch` to push the changes into the official Twisted repository.  Then create a new PR on github for the new branch and close the original PR.  Be sure to reference the original PR in the new one so that the review history is easily discoverable.
    4849 * Assign the ticket to yourself.
    4950 * Review the change, and write a detailed comment about all potential improvements to the branch (See [#Howtobeagoodreviewer below]).