[tor-commits] [bridgedb/master] Add doc/HACKING.md and move the "Maintenance Notes" from README to it.

[isis at torproject.org]

commit e7c8b8fbaddf141c57da52f7a271278b23bcceb5
Author: Isis Lovecruft <isis at torproject.org>
Date:   Tue Oct 15 06:36:59 2013 +0000

    Add doc/HACKING.md and move the "Maintenance Notes" from README to it.
---
 README         |   31 -------------------------------
 doc/HACKING.md |   56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 56 insertions(+), 31 deletions(-)

diff --git a/README b/README
index 12c6c18..0ebb164 100644
--- a/README
+++ b/README
@@ -241,34 +241,3 @@ equal to "get bridges" will get answered, assuming the domain is okay.
 
 ### Support
 Send your questions to isis (A) torproject (circle) org.
-
-### Maintainer's Notes
-
-#### Bumping the version number
-
-Bumping the version number at release time (which, for BridgeDB really means
-deploy time, as of right now) means doing the following:
-
-    $ git checkout develop
-    [merge some fix/bug/feature/etc branches]
-    $ git checkout -b release-0.0.2 develop
-    $ git tag -a -s bridgedb-0.0.2
-    [pip maintainance commands *would* go here, if we ever have any]
-    $ git checkout master
-    $ git merge -S --no-ff release-0.0.2
-    $ git checkout develop
-    $ git merge -S --no-ff master
-    $ git push <remote> master develop
-
-And be sure not to forget to do:
-
-    $ git push --tags
-
-If the currently installed version is *not* from one of the signed tags, the
-version number attribute created by versioneer will be the short ID of the git
-commit from which the installation took place, prefixed with the most recent
-tagged release at that point, i.e.:
-
-    >>> import bridgedb
-    >>> bridgedb.__version__
-    0.0.1-git528ff30c
diff --git a/doc/HACKING.md b/doc/HACKING.md
new file mode 100644
index 0000000..0fda25a
--- /dev/null
+++ b/doc/HACKING.md
@@ -0,0 +1,56 @@
+
+# -*- mode: markdown ; coding: utf-8 -*-
+
+HACKING
+=======
+
+Hack on whatever you like. Ticket are [here][trac]. If you're doing something
+big that doesn't have a ticket, you should probably make one. If you don't
+want to register for a Trac account, you can use the ```cypherpunks``` account
+with password ```writecode```.
+
+## Git Workflow
+
+See this article on git branching [workflow][workflow]. The only modifications
+we make are:
+
+  * Tagging is done in the ```release-*``` branches, rather than in master.
+  * It's okay to use either the ```feature/*``` and ```fix/*``` branch naming
+    scheme, or follow little-t Tor's branch naming scheme,
+    i.e. ```bug666-description-r1```.
+
+## Making a release
+
+### Bumping the version number
+
+Bumping the version number at release time (which, for BridgeDB really means
+deploy time, as of right now) means doing the following:
+
+    $ git checkout develop
+    [merge some fix/bug/feature/etc branches]
+    $ git checkout -b release-0.0.2 develop
+    $ git tag -a -s bridgedb-0.0.2
+    [pip maintainance commands *would* go here, if we ever have any]
+    $ git checkout master
+    $ git merge -S --no-ff release-0.0.2
+    $ git checkout develop
+    $ git merge -S --no-ff master
+    $ git push <remote> master develop
+
+And be sure not to forget to do:
+
+    $ git push --tags
+
+If the currently installed version is *not* from one of the signed tags, the
+version number attribute created by versioneer will be the short ID of the git
+commit from which the installation took place, prefixed with the most recent
+tagged release at that point, i.e.:
+
+    >>> import bridgedb
+    >>> bridgedb.__version__
+    0.0.1-git528ff30c
+
+References
+----------
+[trac]: https://trac.torproject.org/projects/tor/query?status=accepted&status=assigned&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&component=BridgeDB&groupdesc=1&group=priority&col=id&col=summary&col=status&col=type&col=priority&col=changetime&report=34&order=priority
+[workflow]: http://nvie.com/posts/a-successful-git-branching-model/