HACKING

   1 // This file is part of the Doxygen Developer Manual
   2 /** @page patchguide Patch Guidelines
   3
   4 \attention If you're behind a corporate wall with http only access to the
   5 world, you can still use these instructions!
   6
   7 \attention You can't send patches to the mailing list anymore at all. Nowadays
   8 you are expected to send patches to the OpenOCD Gerrit GIT server for a
   9 review.
  10
  11 @section gerrit Submitting patches to the OpenOCD Gerrit server
  12
  13 OpenOCD is to some extent a "self service" open source project, so to
  14 contribute, you must follow the standard procedures to have the best
  15 possible chance to get your changes accepted.
  16
  17 The procedure to create a patch is essentially:
  18
  19 - make the changes
  20 - create a commit
  21 - send the changes to the Gerrit server for review
  22 - correct the patch and re-send it according to review feedback
  23
  24 Your patch (or commit) should be a "good patch": focus it on a single
  25 issue, and make it be easily reviewable. Don't make
  26 it so large that it's hard to review; split large
  27 patches into smaller ones. (That can also help
  28 track down bugs later on.) All patches should
  29 be "clean", which includes preserving the existing
  30 coding style and updating documentation as needed.
  31
  32 Say in the commit message if it's a bugfix (describe the bug) or a new
  33 feature. Don't expect patches to merge immediately
  34 for the next release. Be ready to rework patches
  35 in response to feedback.
  36
  37 Add yourself to the GPL copyright for non-trivial changes.
  38
  39 @section stepbystep Step by step procedure
  40
  41 -# Create a Gerrit account at: http://openocd.zylin.com
  42   - On subsequent sign ins, use the full URL prefaced with 'http://'
  43     For example: http://user_identifier.open_id_provider.com
  44   -# Add a username to your profile.
  45      After creating the Gerrit account and signing in, you will need to
  46      add a username to your profile. To do this, go to 'Settings', and
  47      add a username of your choice.
  48      Your username will be required in step 3 and substituted wherever
  49      the string 'USERNAME' is found.
  50   -# Create an SSH public key following the directions on github:
  51      https://help.github.com/articles/generating-ssh-keys . You can skip step 3
  52      (adding key to Github account) and 4 (testing) - these are useful only if
  53      you actually use Github or want to test whether the new key works fine.
  54   -# Add this new SSH key to your Gerrit account:
  55      go to 'Settings' > 'SSH Public Keys', paste the contents of
  56      ~/.ssh/id_rsa.pub into the text field (if it's not visible click on
  57      'Add Key ...' button) and confirm by clicking 'Add' button.
  58 -# Clone the git repository, rather than just download the source:
  59  @code
  60  git clone git://git.code.sf.net/p/openocd/code openocd
  61  @endcode
  62    or if you have problems with the "git:" protocol, use
  63    the slower http protocol:
  64  @code
  65  git clone http://git.code.sf.net/p/openocd/code openocd
  66  @endcode
  67 -# Set up Gerrit with your local repository. All this does it
  68 to instruct git locally how to send off the changes.
  69   -# Add a new remote to git using Gerrit username:
  70 @code
  71 git remote add review ssh://USERNAME@openocd.zylin.com:29418/openocd.git
  72 git config remote.review.push HEAD:refs/publish/master
  73 @endcode
  74   Or with http only:
  75 @code
  76 git remote add review http://USERNAME@openocd.zylin.com/p/openocd.git
  77 git config remote.review.push HEAD:refs/publish/master
  78 @endcode
  79   The http password is configured from your gerrit settings - http://openocd.zylin.com/#/settings/http-password.
  80   \note If you want to simplify http access you can also add your http password to the url as follows:
  81 @code
  82 git remote add review http://USERNAME:PASSWORD@openocd.zylin.com/p/openocd.git
  83 @endcode
  84   -# You will need to install this hook, we will look into a better solution:
  85 @code
  86 scp -p -P 29418 USERNAME@openocd.zylin.com:hooks/commit-msg .git/hooks/
  87 @endcode
  88   Or with http only:
  89 @code
  90 wget http://openocd.zylin.com/tools/hooks/commit-msg
  91 mv commit-msg .git/hooks
  92 chmod +x .git/hooks/commit-msg
  93 @endcode
  94   \note A script exists to simplify the two items above. execute:
  95 @code
  96 tools/initial.sh <username>
  97 @endcode
  98 With @<username@> being your Gerrit username.
  99 -# Set up git with your name and email:
 100 @code
 101 git config --global user.name "John Smith"
 102 git config --global user.email "john@smith.org"
 103 @endcode
 104 -# Work on your patches. Split the work into
 105    multiple small patches that can be reviewed and
 106    applied seperately and safely to the OpenOCD
 107    repository.
 108 @code
 109 while(!done) {
 110   work - edit files using your favorite editor.
 111   run "git commit -s -a" to commit all changes.
 112   run tools/checkpatch.sh to verify your patch style is ok.
 113 }
 114 @endcode
 115    \note use "git add ." before commit to add new files.
 116
 117    Comment template, notice the short first line w/topic. The topic field
 118    should identify the main part or subsystem the patch touches. Check
 119    git log for examples.
 120 @code
 121 topic: Short comment
 122 <blank line>
 123 Longer comments over several lines, explaining (where applicable) the
 124 reason for the patch and the general idea the solution is based on,
 125 any major design decisions, etc...
 126 <blank line>
 127 Signed-off-by: ...
 128 @endcode
 129 -# Next you need to make sure that your patches
 130    are on top of the latest stuff on the server and
 131    that there are no conflicts:
 132 @code
 133 git pull --rebase origin master
 134 @endcode
 135 -# Send the patches to the Gerrit server for review:
 136 @code
 137 git push review
 138 @endcode
 139 -# Forgot something, want to add more? Just make the changes and do:
 140 @code
 141 git commit --amend
 142 git push review
 143 @endcode
 144
 145 Further reading: http://www.coreboot.org/Git
 146
 147 @section timeline When can I expect my contribution to be committed?
 148
 149 The code review is intended to take as long as a week or two to allow
 150 maintainers and contributors who work on OpenOCD only in their spare
 151 time oportunity to perform a review and raise objections.
 152
 153 With Gerrit much of the urgency of getting things committed has been
 154 removed as the work in progress is safely stored in Gerrit and
 155 available if someone needs to build on your work before it is
 156 submitted to the official repository.
 157
 158 Another factor that contributes to the desire for longer cool-off
 159 times (the time a patch lies around without any further changes or
 160 comments), it means that the chances of quality regression on the
 161 master branch will be much reduced.
 162
 163 If a contributor pushes a patch, it is considered good form if another
 164 contributor actually approves and submits that patch.
 165
 166 It should be noted that a negative review in Gerrit ("-1" or "-2") may (but does
 167 not have to) be disregarded if all conditions listed below are met:
 168
 169 - the concerns raised in the review have been addressed (or explained),
 170 - reviewer does not re-examine the change in a month,
 171 - reviewer does not answer e-mails for another month.
 172
 173 @section browsing Browsing Patches
 174 All OpenOCD patches can be reviewed <a href="http://openocd.zylin.com/">here</a>.
 175 */
 176 /** @file
 177 This file contains the @ref patchguide page.
 178 */