diff options
author | Anas Nashif <anas.nashif@intel.com> | 2013-04-14 01:07:52 -0700 |
---|---|---|
committer | Anas Nashif <anas.nashif@intel.com> | 2013-04-14 01:07:52 -0700 |
commit | 02a48f17aa3a8080563593ab849bd2458a0c3113 (patch) | |
tree | e683d520d73e96fcb7a6827026d23537c0817788 /SubmittingPatches | |
parent | 300d4816804c8ceb4a4601a49ec3ec479c1951b5 (diff) | |
download | nasm-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-- | SubmittingPatches | 116 |
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 |