Submitting Patches

The best way to submit a patch is to do it via the email list; the best way to submit that is (assuming the patch is short) is with a “unified” diff that shows +/- changes as well as context.

You can generate this with the following command:

 diff -U 3 file.old file.new 

which will generate some text. Putting this text in your email message means everyone on the mailing list will immediately easily be able to read it.

  • Please don't submit big rollups of patches to the list - the list auto-caps at 40Kbytes per message and although the listmasters can override this on a per-message basis, at a minimum it will delay your patch. Also, it's much easier for the list to “vet” a patch if it's one-improvement-per-patch.
  • Patches don't get applied “automatically”; Bill Yerazunis personally looks at every line of every patch and often the patch really just goes to stimulate a better way of doing things overall. So, the easier it is to understand the why of your patch, the more likely it will make it into the mainline.

Note- by submitting a patch for CRM114, you affirm that you have authority to grant full license to the patch submitted AND you assign full rights to the patch (including license to relicense in any way desired) to the author(s) of the code being patched. If your patch is *big*, and you want to reuse the code for other things, then please ask that the new code be licensed with full rights to relicense to both yourself and all current licensees. That way, everyone can have their cake and everyone can eat it too.

 
 
submitting_patches.txt · Last modified: Y/m/d H:i:s O (T) by wsy
 
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki