torproject / tor Public
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doc: Add Maintaining.md documentation #451
Conversation
Closes #28225 Signed-off-by: David Goulet <dgoulet@torproject.org>
Pull Request Test Coverage Report for Build 2620
|
doc/HACKING/Maintaining.md
Outdated
| # Maintaining Tor | ||
|
|
||
| This document details the roles and processes on maintaining the Tor code | ||
| base. We do have many policies in place and the maintainers are there as a |
They are kind of all in the git tree in doc/HACKING/:
- CodingStandards.md and CodingStandardsRust.md
- CodeStructure.md
- HowToReview.md
- WritingTests.md
- GettingStarted.md
doc/HACKING/Maintaining.md
Outdated
|
|
||
| This document details the roles and processes on maintaining the Tor code | ||
| base. We do have many policies in place and the maintainers are there as a | ||
| last line of defense to enforce them. |
IMO this paragraph is a little iffy. I don't agree that the main role of the maintainer is to defend against bad code. We're trying to make a better Tor, but that happens not only by rejecting things that are plainly noncompliant. We have to encourage people to get better, and try to help every release of Tor to be better than the one before.
I think our job isn't rejecting; it's oversight and teaching.
Not sure this paragraph mentions "bad code" or anything about rejecting? ... But it is rather to enforce our code standard policies which is the "oversight" there that you mention.
Fixup commit to remove that last sentence: 633135f
doc/HACKING/Maintaining.md
Outdated
|
|
||
| These are the tasks of a subsystem maintainer: | ||
|
|
||
| 1. Regurlarly go over `merge_ready` tickets tagged with the keyword of the |
I suggest "relevant to the related subsystem" instead of "tagged with the keyword" here.
doc/HACKING/Maintaining.md
Outdated
| related subsystems and for the current alpha or development (master) | ||
| Milestone. | ||
|
|
||
| 2. A subsystem maintainer is also in charge of contributing to any design |
|
squashed and merged! |
Looks good.
I made a few trivial suggestions that we can fix when we do the stable maintainer part.
| 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 |
|
|
||
| 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). |
| These are few important items to follow when merging code upstream: | ||
|
|
||
| 1. To merge code upstream, the patch must have passed our CI (currently | ||
| github.com/torproject), have a corresponding ticket and reviewed by |
If you want the full link in markdown, it's [our CI on GitHub](https://github.com/torproject/tor)
Closes #28225
Signed-off-by: David Goulet dgoulet@torproject.org
The text was updated successfully, but these errors were encountered: