Committer Checklist

These are things that developers with commit access to the Twisted source repository should know. The first list is of policy items (i.e., things you should or should not try to do).

  1. All development is done in branches.

  2. All code committed to trunk must go through the Review Process .

  3. trunk commit messages must follow the format described on Review Process so that various pieces of automation can work.

  4. If you check in something that breaks trunk , revert it

  5. Everything you check in to Git is licensed under Twisted’s license

  6. Be in the IRC channel, at least when you’re going to be committing to trunk (don’t feel bad about avoiding the distraction when you’re trying to get stuff done though).

  7. Have fun, but not too much.

This second list includes various technical details about how you might go about doing Twisted development (and has overlap for organizational purposes):

  1. All development is done in branches

    1. Branch names must follow the naming convention so that various pieces of automation can work.

  2. trunk commit messages must follow the format described on Review Process so that various pieces of automation can work.

    1. If you check in something that breaks trunk , revert it

      1. If the bad revision was 07c854353d,

        1. cd ~/Projects/Twisted

        2. git revert -m 1 07c854353d .

      2. Use “Reopens ticket:NNNN” in the commit message to re-open the corresponding ticket

      3. Explain what broke and how and perhaps on which platform in the commit message

    2. If you need to re-merge the reverted branch, revert the reversion.

      1. Create a new branch or merge trunk into your branch with was previously reverted.

      2. Revert again the commit containing the revert and commit the reversion: git revert REVERT-SHA.

      3. Make your changes.

      4. Push the changes for re-review

  3. If you are merging a branch into trunk, you must commit exactly the merge. You may not make extra changes in the trunk working copy after the merge. It’s easiest to do this if you merge changes via the Github pull request UI.

Other documents that overlap and supplement this information include: