| How to submit patches into the NASM |
| =================================== |
| |
| Actually the rules are pretty simple |
| |
| Obtaining the source code |
| ------------------------- |
| |
| The NASM sources are tracked by Git SCM at http://repo.or.cz/w/nasm.git |
| repository. You either could download packed sources or use git tool itself |
| |
| git clone git://repo.or.cz/nasm.git |
| |
| Changin the source code |
| ----------------------- |
| |
| When you change the NASM source code keep in mind -- we prefer tabs and |
| indentations to be 4 characters width, space filled. |
| |
| Other "rules" could be learned from NASM sources -- just make your code |
| to look similar. |
| |
| Producing patch |
| --------------- |
| |
| There are at least two ways to make it right. |
| |
| 1) git format-patch |
| |
| You might need to read documentation on Git SCM how to prepare patch |
| for mail submission. Take a look on http://book.git-scm.com/ and/or |
| http://git-scm.com/documentation for details. It should not be hard |
| at all. |
| |
| 2) Use "diff -up" |
| |
| Use "diff -up" or "diff -uprN" to create patches. |
| |
| Signing your work |
| ----------------- |
| |
| To improve tracking of who did what we've introduced a "sign-off" procedure |
| on patches that are being emailed around. |
| |
| The sign-off is a simple line at the end of the explanation for the |
| patch, which certifies that you wrote it or otherwise have the right to |
| pass it on as a open-source patch. The rules are pretty simple: if you |
| can certify the below: |
| |
| Developer's Certificate of Origin 1.1 |
| |
| By making a contribution to this project, I certify that: |
| |
| (a) The contribution was created in whole or in part by me and I |
| have the right to submit it under the open source license |
| indicated in the file; or |
| |
| (b) The contribution is based upon previous work that, to the best |
| of my knowledge, is covered under an appropriate open source |
| license and I have the right under that license to submit that |
| work with modifications, whether created in whole or in part |
| by me, under the same open source license (unless I am |
| permitted to submit under a different license), as indicated |
| in the file; or |
| |
| (c) The contribution was provided directly to me by some other |
| person who certified (a), (b) or (c) and I have not modified |
| it. |
| |
| (d) I understand and agree that this project and the contribution |
| are public and that a record of the contribution (including all |
| personal information I submit with it, including my sign-off) is |
| maintained indefinitely and may be redistributed consistent with |
| this project or the open source license(s) involved. |
| |
| then you just add a line saying |
| |
| Signed-off-by: Random J Developer <random@developer.example.org> |
| |
| using your real name (please, no pseudonyms or anonymous contributions if |
| it possible) |
| |
| An example of patch message |
| --------------------------- |
| |
| From: Random J Developer <random@developer.example.org> |
| Subject: [PATCH] Short patch description |
| |
| Long patch description (could be skipped if patch |
| is trivial enough) |
| |
| Signed-off-by: Random J Developer <random@developer.example.org> |
| --- |
| Patch body here |
| |
| Mailing patches |
| --------------- |
| |
| The patches should be sent to NASM development mailing list |
| |
| nasm-devel@lists.sourceforge.net |
| |
| Please make sure the email client you're using doesn't screw |
| your patch (line wrapping and so on). |
| |
| Wait for response |
| ----------------- |
| |
| Be patient. Most NASM developers are pretty busy people so if |
| there is no immediate response on your patch -- don't |
| be surprised, sometimes a patch may fly around a week(s) before |
| gets reviewed. But definitely the patches will not go to /dev/null. |
| |
| --- |
| With best regards, |
| NASM-team |
