diff options
| author | Roger Dingledine <arma@torproject.org> | 2019-02-17 16:55:55 -0500 |
|---|---|---|
| committer | Roger Dingledine <arma@torproject.org> | 2019-02-17 16:55:55 -0500 |
| commit | 5dcd44cbe2f03f545c15510de1954cd90cea4521 (patch) | |
| tree | a2c97abb9774ab84f3ea08a79fb02c2edc35beaf | |
| parent | 6c173d00f5ecba150b1a70a68de6102428d65f51 (diff) | |
| download | tor-5dcd44cbe2f03f545c15510de1954cd90cea4521.tar.gz tor-5dcd44cbe2f03f545c15510de1954cd90cea4521.zip | |
fix some of the typos in Maintaining.md
| -rw-r--r-- | doc/HACKING/Maintaining.md | 16 |
1 files changed, 8 insertions, 8 deletions
diff --git a/doc/HACKING/Maintaining.md b/doc/HACKING/Maintaining.md index 22d62b5471..4d5a7f6b76 100644 --- a/doc/HACKING/Maintaining.md +++ b/doc/HACKING/Maintaining.md @@ -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. |