How to send patches for my open source libraries
I'm maintaining a lot of Common Lisp open source projects on this server. This is fun, but it also is
a lot of work I'm doing in my spare time while I'm otherwise pretty
busy hacking Lisp code to pay my rent. Apart from answering a dozen
or more questions per week (and thus providing some kind of free
support) I spend a fair amount of time handling request for new
features. Now, if you desperately want something that's not in there,
there are several ways to get it - you can for example ask me to do it
and wait until I find enough time, or you can even offer to pay me if
it's really urgent. But the best way is probably to write the new
feature yourself and send a patch.
However, and that's the reason why this page exists, I often get
patches where I finally end up re-writing most of what I received, and
that obviously doesn't really save time. And sometimes I simply
reject what I get for these reasons. So, if you have a patch you're
planning to send, please make sure it adheres to the following
Yes, I'm anal about this, sorry. If you think I'm overdoing it and
you shouldn't be bothered with "rules" like these, that's fine. But
don't be surprised if I reject or simply ignore your submissions.
- Follow the coding and indentation conventions used elsewhere in
the code. These might not be the same you are using
in your code, but remember you're sending a patch for someone
else's code. When in Rome, do as the Romans do...
- Don't use TAB characters for indentation.
- Every new function you add should have a reasonable documentation
string. If you change an existing function, change its docstring as
well if necessary.
- The same applies to global variables, classes, class slots, and
everything else you can attach a docstring to.
- If you're exporting new functionality or if you're changing
exported functionality, update the library's HTML documentation as
- Send patches that were created with
against the latest release.
- If the library you created patches for has a mailing list, use this
mailing list to send the patch.
- If you modify existing behavior, always try to be backwards
compatible or to at least provide a simple transition path for users
of previous releases.
- If the library has a test suite (not all of them have one,
unfortunately), try to integrate your new features into it.
- Don't update the version number of the library or the ChangeLog
file. I'll take care of that.
- If you're going to send a patch which makes significant changes,
ask me first if I'm actually willing to integrate your changes before you end
up doing a lot of work in vain.
- Some of my libraries are now maintained
on github. Please check there
Thanks for your time...
$Header: /usr/local/cvsrep/weitz.de/patches.html,v 1.6 2011-08-30 20:53:56 edi Exp $
BACK TO MY HOMEPAGE