then edit the draft changelog into a nice readable format.
What needs a changes file?
-
+
* A not-exhaustive list: Anything that might change user-visible
behavior. Anything that changes internals, documentation, or the build
system enough that somebody could notice. Big or interesting code
did that happen, and/or why did we do that" 6 months down the line.
Why use changes files instead of Git commit messages?
-
+
* Git commit messages are written for developers, not users, and they
are nigh-impossible to revise after the fact.
----------------------
Try to never hand-write new code to parse or generate binary
-formats. Instead, use trunnel if at all possible. See
+formats. Instead, use trunnel if at all possible. See
https://gitweb.torproject.org/trunnel.git/tree
1. Get the source.
We keep our source under version control in Git. To get the latest
- version, run
-
+ version, run
+
git clone https://git.torproject.org/git/tor
This will give you a checkout of the master branch. If you're
Our overall code structure is explained in the "torguts" documents,
currently at
-
+
git clone https://git.torproject.org/user/nickm/torguts.git
Find a part of the code that looks interesting to you, and start
For your first patch, it is probably NOT a good idea to make
something huge or invasive. In particular, you should probably
avoid:
-
+
* Major changes spread across many parts of the codebase.
* Major changes to programming practice or coding style.
* Huge new features or protocol changes.
say so! And if you won't have time to make some of the
changes, you should say that too, so that other developers
will be able to pick up the unfinished portion.
-
+
Congratulations! You have now written your first patch, and gotten
it integrated into mainline Tor.
-
-
-
Running gcov for unit test coverage
-----------------------------------
-
+
./configure --enable-coverage
make
make check
source code. Here's how to use it:
1. Begin every file that should be documented with
-
+
/**
* \file filename.c
* \brief Short description of the file.
6. See the Doxygen manual for more information; this summary just
scratches the surface.
-
1. Use it for a while, as a client, as a relay, as a hidden service,
and as a directory authority. See if it has any obvious bugs, and
- resolve those.
-
+ resolve those.
+
As applicable, merge the `maint-X` branch into the `release-X` branch.
2. Gather the `changes/*` files into a changelog entry, rewriting many
of them and reordering to focus on what users and funders would find
interesting and understandable.
- 1. Make sure that everything that wants a bug number has one.
+ 1. Make sure that everything that wants a bug number has one.
Make sure that everything which is a bugfix says what version
it was a bugfix on.
-
+
2. Concatenate them.
-
+
3. Sort them by section. Within each section, sort by "version it's
a bugfix on", else by numerical ticket order.
If a given changes stanza showed up in a different release (e.g.
maint-0.2.1), be sure to make the stanzas identical (so people can
distinguish if these are the same change).
-
+
5. Merge them in.
6. Clean everything one last time.
in their approved versions list.
7. Sign the tarball, then sign and push the git tag:
-
+
gpg -ba <the_tarball>
git tag -u <keyid> tor-0.2.x.y-status
git push origin tag tor-0.2.x.y-status
`/srv/dist-master.torproject.org/htdocs/` on dist-master. When you want
it to go live, you run "static-update-component dist.torproject.org"
on dist-master.
-
+
Edit `include/versions.wmi` and `Makefile` to note the new version.
9. Email the packagers (cc'ing tor-assistants) that a new tarball is up.
The current list of packagers is:
-
+
- {weasel,gk,mikeperry} at torproject dot org
- {blueness} at gentoo dot org
- {paul} at invizbox dot io
projects / thirdparty / tor.git / commitdiff
