summaryrefslogtreecommitdiff
path: root/SubmittingPatches
diff options
context:
space:
mode:
authorAnas Nashif <anas.nashif@intel.com>2013-04-14 01:07:52 -0700
committerAnas Nashif <anas.nashif@intel.com>2013-04-14 01:07:52 -0700
commit02a48f17aa3a8080563593ab849bd2458a0c3113 (patch)
treee683d520d73e96fcb7a6827026d23537c0817788 /SubmittingPatches
parent300d4816804c8ceb4a4601a49ec3ec479c1951b5 (diff)
downloadnasm-upstream-2.10.07.tar.gz
nasm-upstream-2.10.07.tar.bz2
nasm-upstream-2.10.07.zip
Imported Upstream version 2.10.07upstream/2.10.07upstream-2.10.07
Diffstat (limited to 'SubmittingPatches')
-rw-r--r--SubmittingPatches116
1 files changed, 116 insertions, 0 deletions
diff --git a/SubmittingPatches b/SubmittingPatches
new file mode 100644
index 0000000..168ab64
--- /dev/null
+++ b/SubmittingPatches
@@ -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