coff: Better handling of section redefinition
[nasm.git] / SubmittingPatches
1 How to submit patches into the NASM
2 ===================================
4 Actually the rules are pretty simple
6 Obtaining the source code
7 -------------------------
9 The NASM sources are tracked by Git SCM at
10 repository. You either could download packed sources or use git tool itself
12         git clone git://
14 Changin the source code
15 -----------------------
17 When you change the NASM source code keep in mind -- we prefer tabs and
18 indentations to be 4 characters width, space filled.
20 Other "rules" could be learned from NASM sources -- just make your code
21 to look similar.
23 Producing patch
24 ---------------
26 There are at least two ways to make it right.
28  1) git format-patch
30     You might need to read documentation on Git SCM how to prepare patch
31     for mail submission. Take a look on and/or
32 for details. It should not be hard
33     at all.
35  2) Use "diff -up"
37     Use "diff -up" or "diff -uprN" to create patches.
39 Signing your work
40 -----------------
42 To improve tracking of who did what we've introduced a "sign-off" procedure
43 on patches that are being emailed around.
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:
50         Developer's Certificate of Origin 1.1
52         By making a contribution to this project, I certify that:
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
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
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.
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.
76 then you just add a line saying
78         Signed-off-by: Random J Developer <>
80 using your real name (please, no pseudonyms or anonymous contributions if
81 it possible)
83 An example of patch message
84 ---------------------------
86 From: Random J Developer <>
87 Subject: [PATCH] Short patch description
89 Long patch description (could be skipped if patch
90 is trivial enough)
92 Signed-off-by: Random J Developer <>
93 ---
94 Patch body here
96 Mailing patches
97 ---------------
99 The patches should be sent to NASM development mailing list
103 Please make sure the email client you're using doesn't screw
104 your patch (line wrapping and so on).
106 Wait for response
107 -----------------
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.
114     ---
115     With best regards,
116     NASM-team