SubmittingPatches

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