flash/stm32*: Rewrite info functions
[openocd.git] / HACKING
diff --git a/HACKING b/HACKING
index 5718798..c2e841a 100644 (file)
--- a/HACKING
+++ b/HACKING
-Submitting patches to the OpenOCD mailing list:
-
-By the time you have read this, one supposes that 
-you have figured out how to clone the OpenOCD git
-repository.
-
-Below is a basic workflow and specific instructions 
-to get you going with git and patches.
-
-0. Clone the git repository, rather than just
-download the source. 
-
-git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
-
-or if you have problems with the "git:" protocol, use
-the slower http protocol:
-
-git clone http://repo.or.cz/r/openocd.git
-
-1. Set up git with your name and email:
-
+// This file is part of the Doxygen Developer Manual
+/** @page patchguide Patch Guidelines
+
+\attention If you're behind a corporate wall with http only access to the
+world, you can still use these instructions!
+
+\attention You can't send patches to the mailing list anymore at all. Nowadays
+you are expected to send patches to the OpenOCD Gerrit GIT server for a
+review.
+
+@section gerrit Submitting patches to the OpenOCD Gerrit server
+
+OpenOCD is to some extent a "self service" open source project, so to
+contribute, you must follow the standard procedures to have the best
+possible chance to get your changes accepted.
+
+The procedure to create a patch is essentially:
+
+- make the changes
+- create a commit
+- send the changes to the Gerrit server for review
+- correct the patch and re-send it according to review feedback
+
+Your patch (or commit) should be a "good patch": focus it on a single
+issue, and make it be easily reviewable. Don't make
+it so large that it's hard to review; split large
+patches into smaller ones. (That can also help
+track down bugs later on.) All patches should
+be "clean", which includes preserving the existing
+coding style and updating documentation as needed.
+
+Say in the commit message if it's a bugfix (describe the bug) or a new
+feature. Don't expect patches to merge immediately
+for the next release. Be ready to rework patches
+in response to feedback.
+
+Add yourself to the GPL copyright for non-trivial changes.
+
+@section stepbystep Step by step procedure
+
+-# Create a Gerrit account at: http://openocd.zylin.com
+  - On subsequent sign ins, use the full URL prefaced with 'http://'
+    For example: http://user_identifier.open_id_provider.com
+  -# Add a username to your profile.
+     After creating the Gerrit account and signing in, you will need to
+     add a username to your profile. To do this, go to 'Settings', and
+     add a username of your choice.
+     Your username will be required in step 3 and substituted wherever
+     the string 'USERNAME' is found.
+  -# Create an SSH public key following the directions on github:
+     https://help.github.com/articles/generating-ssh-keys . You can skip step 3
+     (adding key to Github account) and 4 (testing) - these are useful only if
+     you actually use Github or want to test whether the new key works fine.
+  -# Add this new SSH key to your Gerrit account:
+     go to 'Settings' > 'SSH Public Keys', paste the contents of
+     ~/.ssh/id_rsa.pub into the text field (if it's not visible click on
+     'Add Key ...' button) and confirm by clicking 'Add' button.
+-# Clone the git repository, rather than just download the source:
+ @code
+ git clone git://git.code.sf.net/p/openocd/code openocd
+ @endcode
+   or if you have problems with the "git:" protocol, use
+   the slower http protocol:
+ @code
+ git clone http://git.code.sf.net/p/openocd/code openocd
+ @endcode
+-# Set up Gerrit with your local repository. All this does it
+to instruct git locally how to send off the changes.
+  -# Add a new remote to git using Gerrit username:
+@code
+git remote add review ssh://USERNAME@openocd.zylin.com:29418/openocd.git
+git config remote.review.push HEAD:refs/publish/master
+@endcode
+  Or with http only:
+@code
+git remote add review http://USERNAME@openocd.zylin.com/p/openocd.git
+git config remote.review.push HEAD:refs/publish/master
+@endcode
+  The http password is configured from your gerrit settings - http://openocd.zylin.com/#/settings/http-password.
+  \note If you want to simplify http access you can also add your http password to the url as follows:
+@code
+git remote add review http://USERNAME:PASSWORD@openocd.zylin.com/p/openocd.git
+@endcode
+  -# You will need to install this hook, we will look into a better solution:
+@code
+scp -p -P 29418 USERNAME@openocd.zylin.com:hooks/commit-msg .git/hooks/
+@endcode
+  Or with http only:
+@code
+wget http://openocd.zylin.com/tools/hooks/commit-msg
+mv commit-msg .git/hooks
+chmod +x .git/hooks/commit-msg
+@endcode
+  \note A script exists to simplify the two items above. execute:
+@code
+tools/initial.sh <username>
+@endcode
+With @<username@> being your Gerrit username.
+-# Set up git with your name and email:
+@code
 git config --global user.name "John Smith"
 git config --global user.email "john@smith.org"
-
-2. Work on your patches. Split the work into 
-multiple small patches that can be reviewed and
-applied seperately and safely to the OpenOCD
-repository.
-
+@endcode
+-# Work on your patches. Split the work into
+   multiple small patches that can be reviewed and
+   applied seperately and safely to the OpenOCD
+   repository.
+@code
 while(!done) {
   work - edit files using your favorite editor.
-  run "git commit -a" to commit all changes. 
+  run "git commit -s -a" to commit all changes.
+  run tools/checkpatch.sh to verify your patch style is ok.
 }
-
-TIP! use "git add ." before commit to add new files.
-
-3. Next you need to make sure that your patches
-are on top of the latest stuff on the server and
-that there are no conflicts.
-
-git pull --rebase
-
-4. Generate the patch files. This will generate
-patches for all commits that are on top of
-the latest stuff on the server:
-
-git format-patch origin/master
-
-5. Email the patches to openocd-development@lists.berlios.de  
+@endcode
+   \note use "git add ." before commit to add new files.
+
+   Comment template, notice the short first line w/topic. The topic field
+   should identify the main part or subsystem the patch touches. Check
+   git log for examples.
+@code
+topic: Short comment
+<blank line>
+Longer comments over several lines, explaining (where applicable) the
+reason for the patch and the general idea the solution is based on,
+any major design decisions, etc...
+<blank line>
+Signed-off-by: ...
+@endcode
+-# Next you need to make sure that your patches
+   are on top of the latest stuff on the server and
+   that there are no conflicts:
+@code
+git pull --rebase origin master
+@endcode
+-# Send the patches to the Gerrit server for review:
+@code
+git push review
+@endcode
+-# Forgot something, want to add more? Just make the changes and do:
+@code
+git commit --amend
+git push review
+@endcode
+
+Further reading: http://www.coreboot.org/Git
+
+@section timeline When can I expect my contribution to be committed?
+
+The code review is intended to take as long as a week or two to allow
+maintainers and contributors who work on OpenOCD only in their spare
+time oportunity to perform a review and raise objections.
+
+With Gerrit much of the urgency of getting things committed has been
+removed as the work in progress is safely stored in Gerrit and
+available if someone needs to build on your work before it is
+submitted to the official repository.
+
+Another factor that contributes to the desire for longer cool-off
+times (the time a patch lies around without any further changes or
+comments), it means that the chances of quality regression on the
+master branch will be much reduced.
+
+If a contributor pushes a patch, it is considered good form if another
+contributor actually approves and submits that patch.
+
+It should be noted that a negative review in Gerrit ("-1" or "-2") may (but does
+not have to) be disregarded if all conditions listed below are met:
+
+- the concerns raised in the review have been addressed (or explained),
+- reviewer does not re-examine the change in a month,
+- reviewer does not answer e-mails for another month.
+
+@section browsing Browsing Patches
+All OpenOCD patches can be reviewed <a href="http://openocd.zylin.com/">here</a>.
+*/
+/** @file
+This file contains the @ref patchguide page.
+*/