[nasm:travis-osx] Format SubmittingPatches in markdown

[nasm-bot for Cyrill Gorcunov]

Commit-ID:  669c8bd855ca86ae783f1d705b4171fe4312dd1b
Gitweb:     http://repo.or.cz/w/nasm.git?a=commitdiff;h=669c8bd855ca86ae783f1d705b4171fe4312dd1b
Author:     Cyrill Gorcunov <gorcunov at gmail.com>
AuthorDate: Sun, 16 Dec 2018 12:21:37 +0300
Committer:  Cyrill Gorcunov <gorcunov at gmail.com>
CommitDate: Sun, 16 Dec 2018 12:40:08 +0300

Format SubmittingPatches in markdown

Signed-off-by: Cyrill Gorcunov <gorcunov at gmail.com>


---
 SubmittingPatches    | 116 ---------------------------------------------------
 SubmittingPatches.md |  99 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 99 insertions(+), 116 deletions(-)

diff --git a/SubmittingPatches b/SubmittingPatches
deleted file mode 100644
index 168ab640..00000000
--- a/SubmittingPatches
+++ /dev/null
@@ -1,116 +0,0 @@
-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 at 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 at 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 at developer.example.org>
----
-Patch body here
-
-Mailing patches
----------------
-
-The patches should be sent to NASM development mailing list
-
-    nasm-devel at 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
diff --git a/SubmittingPatches.md b/SubmittingPatches.md
new file mode 100644
index 00000000..8b2fa0e0
--- /dev/null
+++ b/SubmittingPatches.md
@@ -0,0 +1,99 @@
+How to submit patches
+=====================
+
+Obtaining the source code
+-------------------------
+The NASM sources are tracked by Git SCM at [nasm.git](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`.
+
+Changing 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
+[book](http://book.git-scm.com/) and/or
+[documentation](http://git-scm.com/documentation) for details.
+It should not be that hard at all.
+2. Use `diff -up` or `diff -uprN` to create patches.
+
+Signing your work
+-----------------
+To improve tracking of who did what we have 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 at developer.example.org>
+```
+using your real name (please, no pseudonyms or anonymous contributions if
+it possible)
+
+An example of a patch message
+```
+From: Random J Developer <random at developer.example.org>
+Subject: [PATCH] Short patch description
+
+Long patch description (could be skipped if the patch
+is trivial enough)
+
+Signed-off-by: Random J Developer <random at developer.example.org>
+---
+Patch body here
+```
+
+Mailing patches
+---------------
+The patches should be sent to NASM development mailing list
+```
+nasm-devel at lists.sourceforge.net
+```
+Please make sure the email client you are using does not 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 -- do not 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, the NASM team.