nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-10 05:03:43 +01:00
Code Issues Packages Projects Releases Wiki Activity

fix some of the typos in Maintaining.md

Browse Source
This commit is contained in:
Roger Dingledine 2019-02-17 16:55:55 -05:00
parent 6c173d00f5
commit 5dcd44cbe2
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
doc/HACKING/Maintaining.md
View File

@ -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.