X-Git-Url: https://review.openocd.org/gitweb?p=openocd.git;a=blobdiff_plain;f=HACKING;h=96b05f2d62b20e41818726e977ce406743f68069;hp=42c50f0a7aec223ade6f4d2d1904c2c03ac403d1;hb=af9daf4433e006197942121a069a5e9d7ec28671;hpb=4e80a9128e69d67d8aed8e5a83995246913bc98a diff --git a/HACKING b/HACKING index 42c50f0a7a..96b05f2d62 100644 --- a/HACKING +++ b/HACKING @@ -1,4 +1,21 @@ -Submitting patches to the OpenOCD Gerrit server: +// This file is part of the Doxygen Developer Manual +/** @page patchguide Patch Guidelines + +\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. + +\attention If you already have a Gerrit account and want to try a +different sign in method, please first sign in as usually, press your +name in the upper-right corner, go to @a Settings, select @a +Identities pane, press Link Another Identity button. In case +you already have duplicated accounts, ask administrators for manual +merging. + +\attention If you're behind a corporate wall with http only access to the +world, you can still use these instructions! + +@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 @@ -10,74 +27,242 @@ The procedure to create a patch is essentially: - 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: +Your patch (or commit) should be a "good patch": focus it on a single +issue, and make it easily reviewable. Don't make +it so large that it's hard to review; split large +patches into smaller ones (this will also help +to track down bugs later). All patches should +be "clean", which includes preserving the existing +coding style and updating documentation as needed. When adding a new +command, the corresponding documentation should be added to +@c doc/openocd.texi in the same commit. OpenOCD runs on both Little +Endian and Big Endian hosts so the code can't count on specific byte +ordering (in other words, must be endian-clean). -http://openocd.zylin.com +There are several additional methods of improving the quality of your +patch: -1. Clone the git repository, rather than just -download the source. +- Runtime testing with Valgrind Memcheck -git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd + This helps to spot memory leaks, undefined behaviour due to + uninitialized data or wrong indexing, memory corruption, etc. -or if you have problems with the "git:" protocol, use -the slower http protocol: +- Clang Static Analyzer -git clone http://repo.or.cz/r/openocd.git + Using this tool uncovers many different kinds of bugs in C code, + with problematic execution paths fully explained. It is a part of + standard Clang installation. -2. Set up Gerrit with your local repository. All this does it -to instruct git locally how to send off the changes. + To generate a report, run this in the OpenOCD source directory: + @code + mkdir build-scanbuild; cd build-scanbuild + scan-build ../configure + scan-build make CFLAGS="-std=gnu99 -I. -I../../jimtcl" + @endcode -Add a new remote to git using Gerrit username: +- Runtime testing with sanitizers -git remote add review ssh://USERNAME@openocd.zylin.com:29418/openocd.git -git config remote.review.push HEAD:refs/for/master + Both GCC and LLVM/Clang include advanced instrumentation options to + detect undefined behaviour and many kinds of memory + errors. Available with @c -fsanitize=* command arguments. -You will need to install this hook, we will look into a better -solution: + Example usage: + @code + mkdir build-sanitizers; cd build-sanitizers + ../configure CC=clang CFLAGS="-fno-omit-frame-pointer \ + -fsanitize=address -fsanitize=undefined -ggdb3" + make + export ASAN_OPTIONS=detect_stack_use_after_return=1 + src/openocd -s ../tcl -f /path/to/openocd.cfg + @endcode -scp -p -P 29418 USERNAME@openocd.zylin.com:hooks/commit-msg .git/hooks/ +Please consider performing these additional checks where appropriate +(especially Clang Static Analyzer for big portions of new code) and +mention the results (e.g. "Valgrind-clean, no new Clang analyzer +warnings") in the commit message. -3. Set up git with your name and email: +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. -git config --global user.name "John Smith" -git config --global user.email "john@smith.org" +Add yourself to the GPL copyright for non-trivial changes. -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. +@section stepbystep Step by step procedure +-# Create a Gerrit account at: https://review.openocd.org + - 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@review.openocd.org:29418/openocd.git +git config remote.review.push HEAD:refs/for/master +@endcode + Or with http only: +@code +git remote add review https://USERNAME@review.openocd.org/p/openocd.git +git config remote.review.push HEAD:refs/for/master +@endcode + The http password is configured from your gerrit settings - https://review.openocd.org/#/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 https://USERNAME:PASSWORD@review.openocd.org/p/openocd.git +@endcode + \note All contributions should be pushed to @c refs/for/master on the +Gerrit server, even if you plan to use several local branches for different +topics. It is possible because @c for/master is not a traditional Git +branch. + -# You will need to install this hook, we will look into a better solution: +@code +scp -p -P 29418 USERNAME@review.openocd.org:hooks/commit-msg .git/hooks/ +@endcode + Or with http only: +@code +wget https://review.openocd.org/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 +@endcode +With @ 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 separately 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 "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. -TIP! use "git add ." before commit to add new files. - ---- example comment, notice the short first line w/topic --- -topic: short comment + Commit message template, notice the short first line. + The field 'specify touched area' + should identify the main part or subsystem the patch touches. +@code{.unparsed} +specify touched area: short comment -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. +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... + +Signed-off-by: ... +@endcode + Examples: +@code{.unparsed} +flash/nor/atsame5: add SAME59 support -git pull --rebase origin/master +Add new device ID +@endcode +@code{.unparsed} +flash/nor: flash driver for XYZ123 -6. Send the patches to the Gerrit server for review. +Add new flash driver for internal flash of ... +@endcode +@code{.unparsed} +target/cortex_m: fix segmentation fault in cmd 'soft_reset_halt' -git push review +soft_reset_halt command failed reproducibly under following conditions: ... +Test for NULL pointer and return error ... -7. Forgot something, want to add more? Just make the changes and do: +Reported-by: John Reporter +Fixes: 123456789abc ("target: the commit where the problem started") +BugLink: https://sourceforge.net/p/openocd/tickets/999/ +@endcode +@code{.unparsed} +doc: fix typos +@endcode + See "git log" for more examples. +-# 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 opportunity 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. -Further reading: +@section browsing Browsing Patches +All OpenOCD patches can be reviewed here. -http://www.coreboot.org/Git \ No newline at end of file +@section reviewing Reviewing Patches +From the main Review +page select the patch you want to review and click on that patch. On the +appearing page select the download method (top right). Apply the +patch. After building and testing you can leave a note with the "Reply" +button and mark the patch with -1, 0 and +1. +*/ +/** @file +This file contains the @ref patchguide page. +*/