SubmittingPatches 3.7 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117
  1. How to submit patches into the NASM
  2. ===================================
  3. Actually the rules are pretty simple
  4. Obtaining the source code
  5. -------------------------
  6. The NASM sources are tracked by Git SCM at http://repo.or.cz/w/nasm.git
  7. repository. You either could download packed sources or use git tool itself
  8. git clone git://repo.or.cz/nasm.git
  9. Changin the source code
  10. -----------------------
  11. When you change the NASM source code keep in mind -- we prefer tabs and
  12. indentations to be 4 characters width, space filled.
  13. Other "rules" could be learned from NASM sources -- just make your code
  14. to look similar.
  15. Producing patch
  16. ---------------
  17. There are at least two ways to make it right.
  18. 1) git format-patch
  19. You might need to read documentation on Git SCM how to prepare patch
  20. for mail submission. Take a look on http://book.git-scm.com/ and/or
  21. http://git-scm.com/documentation for details. It should not be hard
  22. at all.
  23. 2) Use "diff -up"
  24. Use "diff -up" or "diff -uprN" to create patches.
  25. Signing your work
  26. -----------------
  27. To improve tracking of who did what we've introduced a "sign-off" procedure
  28. on patches that are being emailed around.
  29. The sign-off is a simple line at the end of the explanation for the
  30. patch, which certifies that you wrote it or otherwise have the right to
  31. pass it on as a open-source patch. The rules are pretty simple: if you
  32. can certify the below:
  33. Developer's Certificate of Origin 1.1
  34. By making a contribution to this project, I certify that:
  35. (a) The contribution was created in whole or in part by me and I
  36. have the right to submit it under the open source license
  37. indicated in the file; or
  38. (b) The contribution is based upon previous work that, to the best
  39. of my knowledge, is covered under an appropriate open source
  40. license and I have the right under that license to submit that
  41. work with modifications, whether created in whole or in part
  42. by me, under the same open source license (unless I am
  43. permitted to submit under a different license), as indicated
  44. in the file; or
  45. (c) The contribution was provided directly to me by some other
  46. person who certified (a), (b) or (c) and I have not modified
  47. it.
  48. (d) I understand and agree that this project and the contribution
  49. are public and that a record of the contribution (including all
  50. personal information I submit with it, including my sign-off) is
  51. maintained indefinitely and may be redistributed consistent with
  52. this project or the open source license(s) involved.
  53. then you just add a line saying
  54. Signed-off-by: Random J Developer <random@developer.example.org>
  55. using your real name (please, no pseudonyms or anonymous contributions if
  56. it possible)
  57. An example of patch message
  58. ---------------------------
  59. From: Random J Developer <random@developer.example.org>
  60. Subject: [PATCH] Short patch description
  61. Long patch description (could be skipped if patch
  62. is trivial enough)
  63. Signed-off-by: Random J Developer <random@developer.example.org>
  64. ---
  65. Patch body here
  66. Mailing patches
  67. ---------------
  68. The patches should be sent to NASM development mailing list
  69. nasm-devel@lists.sourceforge.net
  70. Please make sure the email client you're using doesn't screw
  71. your patch (line wrapping and so on).
  72. Wait for response
  73. -----------------
  74. Be patient. Most NASM developers are pretty busy people so if
  75. there is no immediate response on your patch -- don't
  76. be surprised, sometimes a patch may fly around a week(s) before
  77. gets reviewed. But definitely the patches will not go to /dev/null.
  78. ---
  79. With best regards,
  80. NASM-team