nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-27 13:53:31 +01:00
Code Issues Packages Projects Releases Wiki Activity

Rewrite documentation on primary branch usage for Tor.git.

Browse Source 
This patch is part of a series of patches where we try to change our
primary branch name of tor.git from master to main.

See: tpo/core/team#2
This commit is contained in:
Alexander Færøy 2021-05-25 11:33:58 +00:00
parent e247aab4ec
commit 8d4bbc337b
7 changed files with 32 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/HACKING/CodingStandards.md
View File

@ -59,7 +59,7 @@ Some compatible licenses include:
Each main development series (like 0.2.1, 0.2.2, etc) has its main work
applied to a single branch. At most one series can be the development series
at a time; all other series are maintenance series that get bug-fixes only.
The development series is built in a git branch called "master"; the
The development series is built in a git branch called "main"; the
maintenance series are built in branches called "maint-0.2.0", "maint-0.2.1",
and so on. We regularly merge the active maint branches forward.
@ -75,7 +75,7 @@ If you're working on a bugfix for a bug that occurs in a particular version,
base your bugfix branch on the "maint" branch for the first supported series
that has that bug. (As of June 2013, we're supporting 0.2.3 and later.)
If you're working on a new feature, base it on the master branch. If you're
If you're working on a new feature, base it on the main branch. If you're
working on a new feature and it will take a while to implement and/or you'd
like to avoid the possibility of unrelated bugs in Tor while you're
implementing your feature, consider branching off of the latest maint- branch.

2
doc/HACKING/GettingStarted.md
View File

@ -41,7 +41,7 @@ Once you've reached this point, here's what you need to know.
$ git clone https://git.torproject.org/git/tor
```
This will give you a checkout of the master branch. If you're
This will give you a checkout of the main branch. If you're
going to fix a bug that appears in a stable version, check out the
appropriate "maint" branch, as in:

4
doc/HACKING/HelpfulTools.md
View File

@ -33,8 +33,8 @@ OFTC. If they don't, ask #tor-dev (also on OFTC).
It's CI/builders. Looks like this: https://jenkins.torproject.org
Runs automatically on commits merged to git.torproject.org. We CI the
master branch and all supported tor versions. We also build nightly debian
packages from master.
main branch and all supported tor versions. We also build nightly debian
packages from main.
Builds Linux and Windows cross-compilation. Runs Linux tests.

10
doc/HACKING/Maintaining.md
View File

@ -7,7 +7,7 @@ The first section describes who is the current Tor maintainer and what are the
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
The second third section describes how the **alpha and main** branches are
maintained and by whom.
Finally, the last section describes how the **stable** branches are maintained
@ -25,7 +25,7 @@ protocol design. Releasing Tor falls under their responsibility.
## Alpha and Master Branches
The Tor repository always has at all times a **master** branch which contains
The Tor repository always has at all times a **main** branch which contains
the upstream ongoing development.
It may also contain a branch for a released feature freezed version which is
@ -37,7 +37,7 @@ Tor is separated into subsystems and some of those are maintained by other
developers than the main maintainer. Those people have commit access to the
code base but only commit (in most cases) into the subsystem they maintain.
Upstream merges are restricted to the alpha and master branches. Subsystem
Upstream merges are restricted to the alpha and main branches. Subsystem
maintainers should never push a patch into a stable branch which is the
responsibility of the [stable branch maintainer](#stable-branches).
@ -69,7 +69,7 @@ maintain the following subsystems:
These are the tasks of a subsystem maintainer:
1. Regularly go over `merge_ready` tickets relevant to the related subsystem
and for the current alpha or development (master branch) Milestone.
and for the current alpha or development (main branch) Milestone.
2. A subsystem maintainer is expected to contribute to any design changes
(including proposals) or large patch set about the subsystem.
@ -102,7 +102,7 @@ These are few important items to follow when merging code upstream:
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.
into main.
5. Maintainer should always consult with the network team about any doubts,
mis-understandings or unknowns of a patch. Final word will always go to the

12
doc/HACKING/ReleaseSeriesLifecycle.md
View File

@ -87,17 +87,17 @@ they do not apply to security-related patch release versions.
(Ideally, do this immediately after a release.)
1. Start a new maint-x.y.z branch based on master, and a new
release-x.y.z branch based on master. They should have the same
1. Start a new maint-x.y.z branch based on main, and a new
release-x.y.z branch based on main. They should have the same
starting point.
Push both of these branches to the master git repository.
Push both of these branches to the canonical git repository.
2. In master, change the version to "0.x.y.0-alpha-dev". Run the
2. In the main branch, change the version to "0.x.y.0-alpha-dev". Run the
update_versions.py script, and commit this version bump.
3. Tag the version bump with "tor-0.x.y.0-alpha-dev". Push the tag
and master.
and main branch.
4. Open tickets for connecting the new branches to various other
places. See section 2 above for a list of affected locations.
@ -107,7 +107,7 @@ they do not apply to security-related patch release versions.
target in the maint-x.y.z branch only.
* Delete the file scripts/maint/practracker/.enable_practracker_in_hooks
in the maint-x.y.z branch only.
* Merge to release-x.y.z, but do not forward-port to master.
* Merge to release-x.y.z, but do not forward-port to the main branch.
6. Finally, make sure this document is up to date with our latest
process.

8
doc/HACKING/ReleasingTor.md
View File

@ -110,7 +110,7 @@ new Tor release:
note added to each section. So in this case, once you have the items
from the changes files copied together, don't use them to build a new
changelog: instead, look up the corrected versions that were merged
into ChangeLog in the master branch, and use those.
into ChangeLog in the main branch, and use those.
Add "backport from X.Y.Z" in the section header for these entries.
@ -142,7 +142,7 @@ new Tor release:
places, and commit. Then merge `maint-0.?.x` into `release-0.?.x`.
When you merge the maint branch forward to the next maint branch, or into
master, merge it with "-s ours" to avoid conflict with the version
main, merge it with "-s ours" to avoid conflict with the version
bump.
2. Make distcheck, put the tarball up in somewhere (how about your
@ -222,13 +222,13 @@ $ git push origin tag tor-0.4.x.y-<status>
1. If it's a stable release, bump the version number in the
`maint-x.y.z` branch to "newversion-dev", and do a `merge -s ours`
merge to avoid taking that change into master.
merge to avoid taking that change into main.
2. If there is a new `maint-x.y.z` branch, create a Travis CI cron job that
builds the release every week. (It's ok to skip the weekly build if the
branch was updated in the last 24 hours.)
3. Forward-port the ChangeLog (and ReleaseNotes if appropriate) to the
master branch.
main branch.
4. Keep an eye on the blog post, to moderate comments and answer questions.

8
scripts/maint/findMergedChanges.pl
View File

@ -22,13 +22,13 @@ Usage:
findMergedChanges.pl [--merged/--unmerged/--weird/--list] [--branch=<branchname] [--head=<branchname>] changes/*
A change is "merged" if it has ever been merged to release-0.2.4 and it has had
no subsequent changes in master.
no subsequent changes in main.
A change is "unmerged" if it has never been merged to release-0.2.4 and it
has had changes in master.
has had changes in main.
A change is "weird" if it has been merged to release-0.2.4 and it *has* had
subsequent changes in master.
subsequent changes in main.
Suggested application:
findMergedChanges.pl --merged changes/* | xargs -n 1 git rm
@ -37,7 +37,7 @@ EOF
}
my $target_branch = "origin/release-0.2.4";
my $head = "origin/master";
my $head = "origin/main";
while (@ARGV and $ARGV[0] =~ /^--/) {
my $flag = shift @ARGV;