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