|
|
@@ -4,7 +4,7 @@ This document details the duties and processes on maintaining the Tor code
|
|
|
base.
|
|
|
|
|
|
The first section describes who is the current Tor maintainer and what are the
|
|
|
-responsabilities. Tor has one main single maintainer but does have many
|
|
|
+responsibilities. Tor has one main single maintainer but does have many
|
|
|
committers and subsystem maintainers.
|
|
|
|
|
|
The second third section describes how the **alpha and master** branches are
|
|
|
@@ -21,14 +21,14 @@ This document does not cover how Tor is released, please see
|
|
|
The current maintainer is Nick Mathewson <nickm@torproject.org>.
|
|
|
|
|
|
The maintainer takes final decisions in terms of engineering, architecture and
|
|
|
-protocol design. Releasing Tor falls under their responsability.
|
|
|
+protocol design. Releasing Tor falls under their responsibility.
|
|
|
|
|
|
## Alpha and Master Branches
|
|
|
|
|
|
-The Tor repository always has at all time a **master** branch which contains
|
|
|
+The Tor repository always has at all times a **master** branch which contains
|
|
|
the upstream ongoing development.
|
|
|
|
|
|
-It may also contains a branch for a released feature freezed version which is
|
|
|
+It may also contain a branch for a released feature freezed version which is
|
|
|
called the **alpha** branch. The git tag and version number is always
|
|
|
postfixed with `-alpha[-dev]`. For example: `tor-0.3.5.0-alpha-dev` or
|
|
|
`tor-0.3.5.3-alpha`.
|
|
|
@@ -39,7 +39,7 @@ code base but only commit (in most cases) into the subsystem they maintain.
|
|
|
|
|
|
Upstream merges are restricted to the alpha and master branches. Subsystem
|
|
|
maintainers should never push a patch into a stable branch which is the
|
|
|
-responsability of the [stable branch maintainer](#stable-branches).
|
|
|
+responsibility of the [stable branch maintainer](#stable-branches).
|
|
|
|
|
|
### Who
|
|
|
|
|
|
@@ -68,7 +68,7 @@ maintain the following subsystems:
|
|
|
|
|
|
These are the tasks of a subsystem maintainer:
|
|
|
|
|
|
-1. Regurlarly go over `merge_ready` tickets relevant to the related subsystem
|
|
|
+1. Regularly go over `merge_ready` tickets relevant to the related subsystem
|
|
|
and for the current alpha or development (master branch) Milestone.
|
|
|
|
|
|
2. A subsystem maintainer is expected to contribute to any design changes
|
|
|
@@ -86,7 +86,7 @@ These are few important items to follow when merging code upstream:
|
|
|
**at least** one person that is not the original coder.
|
|
|
|
|
|
Example A: If Alice writes a patch then Bob, a Tor network team member,
|
|
|
- reviews it and flags it `merge_ready`. Then, the maintainter is required
|
|
|
+ reviews it and flags it `merge_ready`. Then, the maintainer is required
|
|
|
to look at the patch and makes a decision.
|
|
|
|
|
|
Example B: If the maintainer writes a patch then Bob, a Tor network
|
|
|
@@ -100,7 +100,7 @@ These are few important items to follow when merging code upstream:
|
|
|
3. Trivial patches such as comment change, documentation, syntax issues or
|
|
|
typos can be merged without a ticket or reviewers.
|
|
|
|
|
|
-4. Tor uses the "merge forward" method that is if a patch applies to the
|
|
|
+4. Tor uses the "merge forward" method, that is, if a patch applies to the
|
|
|
alpha branch, it has to be merged there first and then merged forward
|
|
|
into master.
|
|
|
|
Roger Dingledine