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.

HACKING 5.8 KiB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163
  1. // This file is part of the Doxygen Developer Manual
  2. /** @page patchguide Patch Guidelines
  3. @b NB! If you're behind a corporate wall with http only access to the
  4. world, you can still use these instructions!
  5. @b NB2! You can't send patches to the mailing list anymore at all. Nowadays
  6. you are expected to send patches to the OpenOCD Gerrit GIT server for a
  7. review.
  8. @section gerrit Submitting patches to the OpenOCD Gerrit server
  9. OpenOCD is to some extent a "self service" open source project, so to
  10. contribute, you must follow the standard procedures to have the best
  11. possible chance to get your changes accepted.
  12. The procedure to create a patch is essentially:
  13. - make the changes
  14. - create a commit
  15. - send the changes to the Gerrit server for review
  16. - correct the patch and re-send it according to review feedback
  17. Your patch (or commit) should be a "good patch": focus it on a single
  18. issue, and make it be easily reviewable. Don't make
  19. it so large that it's hard to review; split large
  20. patches into smaller ones. (That can also help
  21. track down bugs later on.) All patches should
  22. be "clean", which includes preserving the existing
  23. coding style and updating documentation as needed.
  24. Say in the commit message if it's a bugfix (describe the bug) or a new
  25. feature. Don't expect patches to merge immediately
  26. for the next release. Be ready to rework patches
  27. in response to feedback.
  28. Add yourself to the GPL copyright for non-trivial changes.
  29. @section stepbystep Step by step procedure
  30. -# Create a Gerrit account at: http://openocd.zylin.com
  31. - On subsequent sign ins, use the full URL prefaced with 'http://'
  32. For example: http://user_identifier.open_id_provider.com
  33. -# Add a username to your profile.
  34. After creating the Gerrit account and signing in, you will need to
  35. add a username to your profile. To do this, go to 'Settings', and
  36. add a username of your choice.
  37. Your username will be required in step 3 and substituted wherever
  38. the string 'USERNAME' is found.
  39. -# Add an SSH public key following the directions for your specific platform:
  40. - for Windows: http://help.github.com/win-set-up-git/#_set_up_ssh_keys
  41. - for OSX: http://help.github.com/mac-set-up-git/#_set_up_ssh_keys
  42. - for Linux: http://help.github.com/linux-set-up-git/#_set_up_ssh_keys<br>
  43. .
  44. While these pages describe the setting up of git as well,
  45. you should scroll down the page till you get to the section:
  46. <i>Next: Set Up SSH Keys</i>, and follow the steps described.
  47. -# Clone the git repository, rather than just download the source:
  48. @code
  49. git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd
  50. @endcode
  51. or if you have problems with the "git:" protocol, use
  52. the slower http protocol:
  53. @code
  54. git clone http://repo.or.cz/r/openocd.git
  55. @endcode
  56. -# Set up Gerrit with your local repository. All this does it
  57. to instruct git locally how to send off the changes.
  58. -# Add a new remote to git using Gerrit username:
  59. @code
  60. git remote add review ssh://USERNAME@openocd.zylin.com:29418/openocd.git
  61. git config remote.review.push HEAD:refs/publish/master
  62. @endcode
  63. Or with http only:
  64. @code
  65. git remote add review http://openocd.zylin.com/p/openocd.git
  66. git config remote.review.push HEAD:refs/publish/master
  67. @endcode
  68. -# You will need to install this hook, we will look into a better solution:
  69. @code
  70. scp -p -P 29418 USERNAME@openocd.zylin.com:hooks/commit-msg .git/hooks/
  71. @endcode
  72. Or with http only:
  73. @code
  74. wget http://openocd.zylin.com/tools/hooks/commit-msg
  75. mv commit-msg .git/hooks
  76. chmod +x .git/hooks/commit-msg
  77. @endcode
  78. @b NOTE A script exists to simplify the two items above. execute:
  79. @code
  80. tools/initial.sh <username>
  81. @endcode
  82. With @<username@> being your Gerrit username.
  83. -# Set up git with your name and email:
  84. @code
  85. git config --global user.name "John Smith"
  86. git config --global user.email "john@smith.org"
  87. @endcode
  88. -# Work on your patches. Split the work into
  89. multiple small patches that can be reviewed and
  90. applied seperately and safely to the OpenOCD
  91. repository.
  92. @code
  93. while(!done) {
  94. work - edit files using your favorite editor.
  95. run "git commit -s -a" to commit all changes.
  96. run tools/checkpatch.sh to verify your patch style is ok.
  97. }
  98. @endcode
  99. @b TIP! use "git add ." before commit to add new files.
  100. @code
  101. --- example comment, notice the short first line w/topic ---
  102. topic: short comment
  103. <blank line>
  104. longer comments over several
  105. lines...
  106. <blank line>
  107. Signed-off-by: ...
  108. -----
  109. @endcode
  110. -# Next you need to make sure that your patches
  111. are on top of the latest stuff on the server and
  112. that there are no conflicts:
  113. @code
  114. git pull --rebase origin master
  115. @endcode
  116. -# Send the patches to the Gerrit server for review:
  117. @code
  118. git push review
  119. @endcode
  120. -# Forgot something, want to add more? Just make the changes and do:
  121. @code
  122. git commit --amend
  123. git push review
  124. @endcode
  125. Further reading: http://www.coreboot.org/Git
  126. @section timeline When can I expect my contribution to be committed?
  127. The code review is intended to take as long as a week or two to allow
  128. maintainers and contributors who work on OpenOCD only in their spare
  129. time oportunity to perform a review and raise objections.
  130. With Gerrit much of the urgency of getting things committed has been
  131. removed as the work in progress is safely stored in Gerrit and
  132. available if someone needs to build on your work before it is
  133. submitted to the official repository.
  134. Another factor that contributes to the desire for longer cool-off
  135. times (the time a patch lies around without any further changes or
  136. comments), it means that the chances of quality regression on the
  137. master branch will be much reduced.
  138. If a contributor pushes a patch, it is considered good form if another
  139. contributor actually approves and submits that patch.
  140. @section browsing Browsing Patches
  141. All OpenOCD patches can be reviewed <a href="http://openocd.zylin.com/">here</a>.
  142. */
  143. /** @file
  144. This file contains the @ref patchguide page.
  145. */