openocd/HACKING

NB! If you're behind a corporate wall with http only access to the
world, you can still use these instructions!

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


0. 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

0.1. 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 2 and substituted wherever
the string 'USERNAME' is found.

0.2. Add an SSH public key

Following the directions for your specific platform:

	for Windows: help.github.com/win-set-up-git/#_set_up_ssh_keys
	for OSX:     help.github.com/mac-set-up-git/#_set_up_ssh_keys
	for Linux:   help.github.com/linux-set-up-git/#_set_up_ssh_keys

While these pages describe the setting up of git as well,
you should scroll down the page till you get to the section:
'Next: Set Up SSH Keys', and follow the steps described.

1. 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

2. 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:

git remote add review ssh://USERNAME@openocd.zylin.com:29418/openocd.git
git config remote.review.push HEAD:refs/for/master

Or with http only:

git remote add review http://openocd.zylin.com/p/openocd.git
git config remote.review.push HEAD:refs/for/master

You will need to install this hook, we will look into a better
solution:

scp -p -P 29418 USERNAME@openocd.zylin.com:hooks/commit-msg .git/hooks/

Or with http only:

wget http://openocd.zylin.com/tools/hooks/commit-msg
mv commit-msg .git/hooks
chmod +x .git/hooks/commit-msg

3. Set up git with your name and email:

git config --global user.name "John Smith"
git config --global user.email "john@smith.org"

4. Work on your patches. Split the work into
multiple small patches that can be reviewed and
applied seperately and safely to the OpenOCD
repository.

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.
}

TIP! use "git add ." before commit to add new files.

--- example comment, notice the short first line w/topic ---
topic: short comment
<blank line>
longer comments over several
lines...
-----

5. 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 origin/master

6. Send the patches to the Gerrit server for review.

git push review

7. Forgot something, want to add more? Just make the changes and do:

git commit --amend
git push review

Further reading:

http://www.coreboot.org/Git


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.