debuggers: import openocd-0.7.0
Initial check-in of openocd-0.7.0 as it can be downloaded from http://sourceforge.net/projects/openocd/files/openocd/0.7.0/ Any modifications will follow. Change-Id: I6949beaefd589e046395ea0cb80f4e1ab1654d55
This commit is contained in:
178
debuggers/openocd/HACKING
Normal file
178
debuggers/openocd/HACKING
Normal file
@ -0,0 +1,178 @@
|
||||
// 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"
|
||||
@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 -s -a" to commit all changes.
|
||||
run tools/checkpatch.sh to verify your patch style is ok.
|
||||
}
|
||||
@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.
|
||||
*/
|
||||
Reference in New Issue
Block a user