Merge Policy

For information on how to merge, see the MergeProcess document.

SCOPE

This policy describes when we merge things to the main tor.git repository, and to other repositories owned by the network team.

THE GENERAL RULE

In general, every branch should be reviewed and approved by somebody other than the author before it is merged.

In other words, you can merge your own commits if somebody else has reviewed and approved them; you can merge other people's commits after you review them and approve them.

There are exceptions to this rule, listed below.

REQUESTING ADDITIONAL REVIEW

If the author or reviewer of a branch believes that it needs an additional reviewer, they should ask for such to a specific reviewer in the ticket.

This is especially recommended for:

• tricky code code without test coverage security sensitive code security
• fixes changes to code that has caused bugs in the past code that cannot be
• tested with CI code that, for some reason, does not conform to our regular
• PR requirements, testing standards, or so on

Additional review is always required for any security patch that we intend to keep secret until release.

For nontrivial contributions from external volunteers, additional review is strongly recommended.

WHEN IS REVIEW NOT NEEDED

The following items do not need a reviewer or a separate merger:

• Putting out releases: Creating the ChangeLog and ReleaseNotes Bumping the

• version number Creating a signed tag

• Typo/grammar/spelling ("editorial") fixes in comments.

• Typo/grammar/spelling ("editorial") fixes in documentation.

• Whitespace fixes.

• Running "make autostyle".

• Editing a changes file.

WHEN NOT TO MERGE

For a day or two before a release, please do not merge anything at all into the release's branch without first checking with the release manager.

WHAT TO CHECK BEFORE MERGING

These issues are hard to notice (or hard to fix) after merging, so PLEASE be sure that you check them first.

• Is there a changes file?

• Is the patch based against the correct branch?

• Is there a spec branch corresponding to any protocol change?

OTHER NOTES

All mergers should make sure they are using our scripts and git hooks.

Only merge when you are sober, awake, and alert.

If you feel funny about something, don't merge it, and tell the other team members.

Remember, above all, that Tor exists for its users, not for its developers: we all have the duty to protect user security and privacy. [This should be obvious, but it's useful to have a policy saying so.]