commit 8d4bbc337b11e1d3a60158d7f97c90fae7d7bc65 Author: Alexander Færøy ahf@torproject.org Date: Tue May 25 11:33:58 2021 +0000
Rewrite documentation on primary branch usage for Tor.git.
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 --- doc/HACKING/CodingStandards.md | 4 ++-- doc/HACKING/GettingStarted.md | 2 +- doc/HACKING/HelpfulTools.md | 4 ++-- doc/HACKING/Maintaining.md | 10 +++++----- doc/HACKING/ReleaseSeriesLifecycle.md | 12 ++++++------ doc/HACKING/ReleasingTor.md | 8 ++++---- scripts/maint/findMergedChanges.pl | 24 ++++++++++++------------ 7 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/doc/HACKING/CodingStandards.md b/doc/HACKING/CodingStandards.md index cd3417d0b5..c5dd6c744f 100644 --- a/doc/HACKING/CodingStandards.md +++ b/doc/HACKING/CodingStandards.md @@ -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. diff --git a/doc/HACKING/GettingStarted.md b/doc/HACKING/GettingStarted.md index 6d61be9881..271e2d7517 100644 --- a/doc/HACKING/GettingStarted.md +++ b/doc/HACKING/GettingStarted.md @@ -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:
diff --git a/doc/HACKING/HelpfulTools.md b/doc/HACKING/HelpfulTools.md index 0ce59576f0..7849fc67c7 100644 --- a/doc/HACKING/HelpfulTools.md +++ b/doc/HACKING/HelpfulTools.md @@ -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.
diff --git a/doc/HACKING/Maintaining.md b/doc/HACKING/Maintaining.md index 4d5a7f6b76..267f6d0b58 100644 --- a/doc/HACKING/Maintaining.md +++ b/doc/HACKING/Maintaining.md @@ -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 diff --git a/doc/HACKING/ReleaseSeriesLifecycle.md b/doc/HACKING/ReleaseSeriesLifecycle.md index 8536fbbd08..e47ac90fa5 100644 --- a/doc/HACKING/ReleaseSeriesLifecycle.md +++ b/doc/HACKING/ReleaseSeriesLifecycle.md @@ -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. diff --git a/doc/HACKING/ReleasingTor.md b/doc/HACKING/ReleasingTor.md index 739ea38795..358b53a8db 100644 --- a/doc/HACKING/ReleasingTor.md +++ b/doc/HACKING/ReleasingTor.md @@ -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. diff --git a/scripts/maint/findMergedChanges.pl b/scripts/maint/findMergedChanges.pl index d6c4105b74..9b3496403d 100755 --- a/scripts/maint/findMergedChanges.pl +++ b/scripts/maint/findMergedChanges.pl @@ -9,7 +9,7 @@ sub nChanges { # requires perl 5.8. Avoids shell issues if we ever get a changes # file named by the parents of Little Johnny Tables. open F, "-|", "git", "log", "--no-merges", "--pretty=format:%H", $branches, "--", $fname - or die "$!"; + or die "$!"; my @changes = <F>; return scalar @changes } @@ -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,18 +37,18 @@ 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; if ($flag =~ /^--(weird|merged|unmerged|list)/) { - $look_for_type = $1; + $look_for_type = $1; } elsif ($flag =~ /^--branch=(\S+)/) { $target_branch = $1; } elsif ($flag =~ /^--head=(\S+)/) { $head = $1; } else { - die "Unrecognized flag $flag"; + die "Unrecognized flag $flag"; } }
@@ -58,16 +58,16 @@ for my $changefile (@ARGV) { my $type;
if ($n_merged != 0 and $n_postmerged == 0) { - $type = "merged"; + $type = "merged"; } elsif ($n_merged == 0 and $n_postmerged != 0) { - $type = "unmerged"; + $type = "unmerged"; } else { - $type = "weird"; + $type = "weird"; }
if ($type eq $look_for_type) { - print "$changefile\n"; + print "$changefile\n"; } elsif ($look_for_type eq 'list') { - printf "% 8s: %s\n", $type, $changefile; + printf "% 8s: %s\n", $type, $changefile; } }