You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

146 lines
4.3 KiB

  1. NB! If you're behind a corporate wall with http only access to the
  2. world, you can still use these instructions!
  3. Submitting patches to the OpenOCD Gerrit server:
  4. OpenOCD is to some extent a "self service" open source project, so to
  5. contribute, you must follow the standard procedures to have the best
  6. possible chance to get your changes accepted.
  7. The procedure to create a patch is essentially:
  8. - make the changes
  9. - create a commit
  10. - send the changes to the Gerrit server for review
  11. - correct the patch and re-send it according to review feedback
  12. 0. Create a Gerrit account at:
  14. - On subsequent sign ins, use the full URL prefaced with 'http://'
  15. For example:
  17. 0.1. Add a username to your profile.
  18. After creating the Gerrit account and signing in, you will need to
  19. add a username to your profile. To do this, go to 'Settings', and
  20. add a username of your choice.
  21. Your username will be required in step 2 and substituted wherever
  22. the string 'USERNAME' is found.
  23. 0.2. Add an SSH public key
  24. Following the directions for your specific platform:
  25. for Windows:
  26. for OSX:
  27. for Linux:
  28. While these pages describe the setting up of git as well,
  29. you should scroll down the page till you get to the section:
  30. 'Next: Set Up SSH Keys', and follow the steps described.
  31. 1. Clone the git repository, rather than just
  32. download the source.
  33. git clone git://
  34. or if you have problems with the "git:" protocol, use
  35. the slower http protocol:
  36. git clone
  37. 2. Set up Gerrit with your local repository. All this does it
  38. to instruct git locally how to send off the changes.
  39. Add a new remote to git using Gerrit username:
  40. git remote add review ssh://
  41. git config HEAD:refs/for/master
  42. Or with http only:
  43. git remote add review
  44. git config HEAD:refs/for/master
  45. You will need to install this hook, we will look into a better
  46. solution:
  47. scp -p -P 29418 .git/hooks/
  48. Or with http only:
  49. wget
  50. mv commit-msg .git/hooks
  51. chmod +x .git/hooks/commit-msg
  52. 3. Set up git with your name and email:
  53. git config --global "John Smith"
  54. git config --global ""
  55. 4. Work on your patches. Split the work into
  56. multiple small patches that can be reviewed and
  57. applied seperately and safely to the OpenOCD
  58. repository.
  59. while(!done) {
  60. work - edit files using your favorite editor.
  61. run "git commit -s -a" to commit all changes.
  62. run tools/ to verify your patch style is ok.
  63. }
  64. TIP! use "git add ." before commit to add new files.
  65. --- example comment, notice the short first line w/topic ---
  66. topic: short comment
  67. <blank line>
  68. longer comments over several
  69. lines...
  70. -----
  71. 5. Next you need to make sure that your patches
  72. are on top of the latest stuff on the server and
  73. that there are no conflicts.
  74. git pull --rebase origin/master
  75. 6. Send the patches to the Gerrit server for review.
  76. git push review
  77. 7. Forgot something, want to add more? Just make the changes and do:
  78. git commit --amend
  79. git push review
  80. Further reading:
  82. When can I expect my contribution to be committed?
  83. ==================================================
  84. The code review is intended to take as long as a week or two to allow
  85. maintainers and contributors who work on OpenOCD only in their spare
  86. time oportunity to perform a review and raise objections.
  87. With Gerrit much of the urgency of getting things committed has been
  88. removed as the work in progress is safely stored in Gerrit and
  89. available if someone needs to build on your work before it is
  90. submitted to the official repository.
  91. Another factor that contributes to the desire for longer cool-off
  92. times (the time a patch lies around without any further changes or
  93. comments), it means that the chances of quality regression on the
  94. master branch will be much reduced.
  95. If a contributor pushes a patch, it is considered good form if another
  96. contributor actually approves and submits that patch.