Add SubmittingPatches file
authorCyrill Gorcunov <gorcunov@gmail.com>
Sun, 3 Oct 2010 17:02:08 +0000 (21:02 +0400)
committerCyrill Gorcunov <gorcunov@gmail.com>
Sun, 3 Oct 2010 17:02:08 +0000 (21:02 +0400)
Adopted from Linux's Documentation/SubmittingPatches

Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com>
SubmittingPatches [new file with mode: 0644]

diff --git a/SubmittingPatches b/SubmittingPatches
new file mode 100644 (file)
index 0000000..168ab64
--- /dev/null
@@ -0,0 +1,116 @@
+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