[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [tor/master] Add my draft (in-progress) guide to getting started on tor development
commit 9e461588a6c4bebe18e7172b37bbb9e482e1fc8d
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date: Thu Oct 8 11:52:27 2015 -0400
Add my draft (in-progress) guide to getting started on tor development
---
doc/GettingStarted.txt | 207 ++++++++++++++++++++++++++++++++++++++++++++++++
doc/HACKING | 5 +-
doc/include.am | 3 +-
3 files changed, 213 insertions(+), 2 deletions(-)
diff --git a/doc/GettingStarted.txt b/doc/GettingStarted.txt
new file mode 100644
index 0000000..1f4b434
--- /dev/null
+++ b/doc/GettingStarted.txt
@@ -0,0 +1,207 @@
+
+
+(DRAFT)
+
+
+
+Getting started in Tor development
+==================================
+
+Congratulations! You've found this file, and you're reading it! This
+means that you might be interested in getting started in developing Tor.
+
+(This guide is just about Tor itself--the small network program at the
+heart of the Tor network--and not about all the other programs in the
+whole Tor ecosystem.)
+
+
+If you are looking for a more bare-bones, less user-friendly information
+dump of important information, you might like reading doc/HACKING
+instead. You should probably read it before you write your first patch.
+
+
+Required background
+-------------------
+
+First, I'm going to assume that you can build Tor from source, and that
+you know enough of the C language to read and write it. (See the README
+file that comes with the Tor source for more information on building it,
+and any high-quality guide to C for information on programming.)
+
+I'm also going to assume that you know a little bit about how to use
+Git, or that you're able to fillow one of the several excellent guides
+at http://git-scm.org to learn.
+
+Most Tor developers develop using some Unix-based system, such as Linux,
+BSD, or OSX. It's okay to develop on Windows if you want, but you're
+going to have a more difficult time.
+
+
+Getting your first patch into Tor
+---------------------------------
+
+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
+ git clone https://git.torproject.org/git/tor
+
+ This will give you a checkout of the master branch. If you're
+ going to fix a bug that appears in a stable version, check out the
+ appropriate "maint" branch, as in:
+
+ git checkout maint-0.2.7
+
+ 2) Find your way around the source
+
+ 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
+ looking around it to see how it fits together!
+
+ We do some unusual things in our codebase. Our testing-related
+ practices and kludges are explained in doc/WritingTests.txt.
+
+ If you see something that doesn't make sense, we love to get
+ questions!
+
+ 3) Find something cool to hack on.
+
+ You may already have a good idea of what you'd like to work on, or
+ you might be looking for a way to contribute.
+
+ Many people have gotten started by looking for an area where they
+ personally felt Tor was underperforming, and investigating ways to
+ fix it. If you're looking for ideas, you can head to our bug
+ tracker at trac.torproject.org and look for tickets that have
+ received the "easy" tag: these are ones that developers think would
+ be pretty simple for a new person to work on. For a bigger
+ challenge, you might want to look for tickets with the "lorax"
+ keyword: these are tickets that the developers think might be a
+ good idea to build, but which we have no time to work on any time
+ soon.
+
+ Or you might find another open ticket that piques your
+ interest. It's all fine!
+
+ 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.
+
+ 4) Meet the developers!
+
+ We discuss stuff on the tor-dev mailing list and on the #tor-dev
+ IRC channel on OFTC. We're generally friendly and approachable,
+ and we like to talk about how Tor fits together. If we have ideas
+ about how something should be implemented, we'll be happy to share
+ them.
+
+ We currently have a patch workshop at least once a week, where
+ people share patches they've made and discuss how to make them
+ better. The time might change in the future, but generally,
+ there's no bad time to talk, and ask us about patch ideas.
+
+ 5) Do you need to write a design proposal?
+
+ If your idea is very large, or it will require a change to Tor's
+ protocols, there needs to be a written design proposal before it
+ can be merged. (We use this process to manage changes in the
+ protocols.) To write one, see the instructions at
+ https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt
+ . If you'd like help writing a proposal, just ask! We're happy to
+ help out with good ideas.
+
+ You might also like to look around the rest of that directory, to
+ see more about open and past proposed changes to Tor's behavior.
+
+ 6) Writing your patch
+
+ As you write your code, you'll probably want it to fit in with the
+ standards of the rest of the Tor codebase so it will be easy for us
+ to review and merge. You can learn our coding standards in
+ doc/HACKING.
+
+ If your patch is large and/or is divided into multiple logical
+ components, remember to divide it into a series of Git commits. A
+ series of small changes is much easier to review than one big lump.
+
+ 7) Testing your patch
+
+ We prefer that all new or modified code have unit tests for it to
+ ensure that it runs correctly. Also, all code should actually be
+ _run_ by somebody, to make sure it works.
+
+ See doc/WritingTests.txt for more information on how we test things
+ in Tor. If you'd like any help writing tests, just ask! We're
+ glad to help out.
+
+ 8) Submitting your patch
+
+ We review patches through tickets on our bugtracker at
+ trac.torproject.org. You can either upload your patches there, or
+ put them at a public git repository somewhere we can fetch them
+ (like github or bitbucket) and then paste a link on the appropriate
+ trac ticket.
+
+ Once your patches are available, write a short explanation of what
+ you've done on trac, and then change the status of the ticket to
+ needs_review.
+
+ 9) Review, Revision, and Merge
+
+ With any luck, somebody will review your patch soon! If not, you
+ can ask on the IRC channel; sometimes we get really busy and take
+ longer than we should. But don't let us slow you down: you're the
+ one who's offering help here, and we should respect your time and
+ contributions.
+
+ When your patch is reviewed, one of these things will happen:
+
+ * The reviewer will say "looks good to me" and your
+ patch will get merged right into Tor. [Assuming we're not
+ in the middle of a code-freeze window. If the codebase is
+ frozen, your patch will go into the next release series.]
+
+ * OR the reviewer will say "looks good, just needs some small
+ changes!" And then the reviewer will make those changes,
+ and merge the modified patch into Tor.
+
+ * OR the reviewer will say "Here are some questions and
+ comments," followed by a bunch of stuff that the reviewer
+ thinks should change in your code, or questions that the
+ reviewer has.
+
+ At this point, you might want to make the requested changes
+ yourself, and comment on the trac ticket once you have done
+ so. Or if you disagree with any of the comments, you should
+ 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.
+
+
+Where do I go from here?
+------------------------
+
+doc/HACKING
+
+doc/WritingTests.txt
+
+torguts.git
+
+torspec.git
+
+The design paper
+
+freehaven.net/anonbib
+
+XXXX describe these and add links.
diff --git a/doc/HACKING b/doc/HACKING
index e92d675..5a1454e 100644
--- a/doc/HACKING
+++ b/doc/HACKING
@@ -1,7 +1,7 @@
Hacking Tor: An Incomplete Guide
================================
-Getting started
+Important links
---------------
For full information on how Tor is supposed to work, look at the files in
@@ -19,6 +19,9 @@ discussion belong on the tor-dev mailing list. We hang around on
irc.oftc.net, with general discussion happening on #tor and development
happening on #tor-dev.
+For a nice quick-start guide to hacking on Tor, have a look at
+doc/GettingStarted.txt, included with the Tor distribution.
+
How we use Git branches
-----------------------
diff --git a/doc/include.am b/doc/include.am
index 41d3d2a..f33103b 100644
--- a/doc/include.am
+++ b/doc/include.am
@@ -39,7 +39,8 @@ EXTRA_DIST+= doc/HACKING doc/asciidoc-helper.sh \
doc/state-contents.txt \
doc/torrc_format.txt \
doc/TUNING \
- doc/WritingTests.txt
+ doc/WritingTests.txt \
+ doc/GettingStarted.txt
docdir = @docdir@
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits