mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-27 13:53:31 +01:00
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
This commit is contained in:
Alexander Færøy
parent
e247aab4ec
commit
8d4bbc337b
@ -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.
|
||||
|
||||
@ -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:
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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;
|
||||
}
|
||||
}
|
||||
|
||||
Loading…
Reference in New Issue
Block a user