commit 5a370618859573ed1eb5dabbe0ed2e773a579817 Author: Nick Mathewson nickm@torproject.org Date: Thu Nov 5 09:53:05 2015 -0500
Delete trailing whitespace in md files --- doc/HACKING/CodingStandards.md | 6 +++--- doc/HACKING/GettingStarted.md | 13 +++++-------- doc/HACKING/HelpfulTools.md | 5 ++--- doc/HACKING/ReleasingTor.md | 18 +++++++++--------- 4 files changed, 19 insertions(+), 23 deletions(-)
diff --git a/doc/HACKING/CodingStandards.md b/doc/HACKING/CodingStandards.md index f7541d7..d2fc784 100644 --- a/doc/HACKING/CodingStandards.md +++ b/doc/HACKING/CodingStandards.md @@ -81,7 +81,7 @@ in changes to make a draft changelog, and clear the directory. We'll 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 @@ -89,7 +89,7 @@ What needs a changes file? 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.
@@ -151,7 +151,7 @@ Functions not to write ----------------------
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
diff --git a/doc/HACKING/GettingStarted.md b/doc/HACKING/GettingStarted.md index 4ab26b7..0295adc 100644 --- a/doc/HACKING/GettingStarted.md +++ b/doc/HACKING/GettingStarted.md @@ -40,8 +40,8 @@ Once you've reached this point, here's what you need to know. 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 @@ -54,7 +54,7 @@ Once you've reached this point, here's what you need to know.
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 @@ -88,7 +88,7 @@ Once you've reached this point, here's what you need to know. 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. @@ -182,9 +182,6 @@ Once you've reached this point, here's what you need to know. 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. - - - diff --git a/doc/HACKING/HelpfulTools.md b/doc/HACKING/HelpfulTools.md index 810519c..a7f36e6 100644 --- a/doc/HACKING/HelpfulTools.md +++ b/doc/HACKING/HelpfulTools.md @@ -101,7 +101,7 @@ working connection to the internet:
Running gcov for unit test coverage ----------------------------------- - + ./configure --enable-coverage make make check @@ -243,7 +243,7 @@ We use the 'doxygen' utility to generate documentation from our 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. @@ -291,4 +291,3 @@ source code. Here's how to use it:
6. See the Doxygen manual for more information; this summary just scratches the surface. - diff --git a/doc/HACKING/ReleasingTor.md b/doc/HACKING/ReleasingTor.md index 845a61b..c58e349 100644 --- a/doc/HACKING/ReleasingTor.md +++ b/doc/HACKING/ReleasingTor.md @@ -6,20 +6,20 @@ Here are the steps Roger takes when putting out a new Tor release:
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.
@@ -55,7 +55,7 @@ Here are the steps Roger takes when putting out a new Tor release: 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. @@ -94,7 +94,7 @@ Here are the steps Roger takes when putting out a new Tor release: 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 @@ -103,12 +103,12 @@ Here are the steps Roger takes when putting out a new Tor release: `/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