Version 1 (modified by Jean-Paul Calderone, 8 years ago) (diff)

Not exactly what I had imagined, but the best I can do it seems. Guidelines for committers, hopefully not too redundant with existing text.

This is a list of things that developers with commit access to the Twisted source repository should know:

  1. SVN access is via svn+ssh scheme
  2. You can convert a read-only checkout to a read-write checkout
    1. svn switch --relocate svn:// svn+ssh://
  3. All development is done in branches
    1. Branch names must follow the naming convention so that various pieces of automation can work.
    2. Branches must be copied from trunk with no changes in the initial revision so that they can be merged properly. Use server-side copies. Or use Combinator.
  4. trunk commit messages must follow the format described on ReviewProcess so that various pieces of automation can work.
    1. If you merge a branch with the correct "Fixes #NNNN" message and the ticket is not automatically closed:
      1. Make sure you got the ticket number right
      2. trac is buggy
        1. Log on to the shell
        2. Look at the end of ~/.post-commit.log for a line like "+ /svn/Twisted/hooks/trac-post-commit-pb-client ..." which corresponds to your trunk commit
        3. Cross your fingers
        4. Re-run that command with all the same arguments
        5. With sufficient delays to allow trac to catch up, try again one or two more times if it still doesn't work.
        6. If it still doesn't work, find someone in the IRC channel to help
    2. If you check in something that breaks trunk, revert it
      1. If the bad revision was 12345,
        1. cd ~/Projects/Twisted/trunk
        2. svn merge -c -12345 .
      2. Use "Reopens #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
  5. 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.
  6. Use [browser:sandbox/exarkun/] if you want to test a branch on all supported builders before merging
    1. No, really, use it. It saves a lot of time.
    2. Also, update it somewhat frequently, to keep the list of supported builders up to date.
  7. 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).
  8. Have fun, but not too much.