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