mips: change in restoring debug working register
[openocd.git] / HACKING
blob395b5b3167c5ff09f7613f4ac06e3d7ad8315d36
1 // This file is part of the Doxygen Developer Manual
2 /** @page patchguide Patch Guidelines
4 \attention If you're behind a corporate wall with http only access to the
5 world, you can still use these instructions!
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.
11 @section gerrit Submitting patches to the OpenOCD Gerrit server
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.
17 The procedure to create a patch is essentially:
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
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.
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.
37 Add yourself to the GPL copyright for non-trivial changes.
39 @section stepbystep Step by step procedure
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   -# Add an SSH public key following the directions on github:
51      https://help.github.com/articles/generating-ssh-keys
52 -# Clone the git repository, rather than just download the source:
53  @code
54  git clone git://git.code.sf.net/p/openocd/code openocd
55  @endcode
56    or if you have problems with the "git:" protocol, use
57    the slower http protocol:
58  @code
59  git clone http://git.code.sf.net/p/openocd/code openocd
60  @endcode
61 -# Set up Gerrit with your local repository. All this does it
62 to instruct git locally how to send off the changes.
63   -# Add a new remote to git using Gerrit username:
64 @code
65 git remote add review ssh://USERNAME@openocd.zylin.com:29418/openocd.git
66 git config remote.review.push HEAD:refs/publish/master
67 @endcode
68   Or with http only:
69 @code
70 git remote add review http://USERNAME@openocd.zylin.com/p/openocd.git
71 git config remote.review.push HEAD:refs/publish/master
72 @endcode
73   The http password is configured from your gerrit settings - http://openocd.zylin.com/#/settings/http-password.
74   \note If you want to simplify http access you can also add your http password to the url as follows:
75 @code
76 git remote add review http://USERNAME:PASSWORD@openocd.zylin.com/p/openocd.git
77 @endcode
78   -# You will need to install this hook, we will look into a better solution:
79 @code
80 scp -p -P 29418 USERNAME@openocd.zylin.com:hooks/commit-msg .git/hooks/
81 @endcode
82   Or with http only:
83 @code
84 wget http://openocd.zylin.com/tools/hooks/commit-msg
85 mv commit-msg .git/hooks
86 chmod +x .git/hooks/commit-msg
87 @endcode
88   \note A script exists to simplify the two items above. execute:
89 @code
90 tools/initial.sh <username>
91 @endcode
92 With @<username@> being your Gerrit username.
93 -# Set up git with your name and email:
94 @code
95 git config --global user.name "John Smith"
96 git config --global user.email "john@smith.org"
97 @endcode
98 -# Work on your patches. Split the work into
99    multiple small patches that can be reviewed and
100    applied seperately and safely to the OpenOCD
101    repository.
102 @code
103 while(!done) {
104   work - edit files using your favorite editor.
105   run "git commit -s -a" to commit all changes.
106   run tools/checkpatch.sh to verify your patch style is ok.
108 @endcode
109    \note use "git add ." before commit to add new files.
111    Comment template, notice the short first line w/topic. The topic field
112    should identify the main part or subsystem the patch touches. Check
113    git log for examples.
114 @code
115 topic: Short comment
116 <blank line>
117 Longer comments over several lines, explaining (where applicable) the
118 reason for the patch and the general idea the solution is based on,
119 any major design decisions, etc...
120 <blank line>
121 Signed-off-by: ...
122 @endcode
123 -# Next you need to make sure that your patches
124    are on top of the latest stuff on the server and
125    that there are no conflicts:
126 @code
127 git pull --rebase origin master
128 @endcode
129 -# Send the patches to the Gerrit server for review:
130 @code
131 git push review
132 @endcode
133 -# Forgot something, want to add more? Just make the changes and do:
134 @code
135 git commit --amend
136 git push review
137 @endcode
139 Further reading: http://www.coreboot.org/Git
141 @section timeline When can I expect my contribution to be committed?
143 The code review is intended to take as long as a week or two to allow
144 maintainers and contributors who work on OpenOCD only in their spare
145 time oportunity to perform a review and raise objections.
147 With Gerrit much of the urgency of getting things committed has been
148 removed as the work in progress is safely stored in Gerrit and
149 available if someone needs to build on your work before it is
150 submitted to the official repository.
152 Another factor that contributes to the desire for longer cool-off
153 times (the time a patch lies around without any further changes or
154 comments), it means that the chances of quality regression on the
155 master branch will be much reduced.
157 If a contributor pushes a patch, it is considered good form if another
158 contributor actually approves and submits that patch.
160 It should be noted that a negative review in Gerrit ("-1" or "-2") may (but does
161 not have to) be disregarded if all conditions listed below are met:
163 - the concerns raised in the review have been addressed (or explained),
164 - reviewer does not re-examine the change in a month,
165 - reviewer does not answer e-mails for another month.
167 @section browsing Browsing Patches
168 All OpenOCD patches can be reviewed <a href="http://openocd.zylin.com/">here</a>.
170 /** @file
171 This file contains the @ref patchguide page.