generating a patch

Andrew Moore amoore at mooresystems.com
Mon Mar 1 21:56:04 CST 2004


On Mon, Mar 01, 2004 at 02:58:37PM -0600, Jason Clinton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Well, I've done it. I've downloaded the source and made my first set of
> modifications to an open source product and now the maintainer would
> like me to submit a patch back to him. Question is: how do I do that? :)
 
It seems to me that most people like unified diffs. Get two versions of
the source, and use "diff -u" on them. If you have just changed one
file you can get away with diffing just those files. If you have
changed several, you would be better off diff'ing the entire source
directories, I think.

Check to see if they have a CVS tree and diff against that, otherwise,
use the latest release.

Then, check to see that you can apply your patch with "patch -p1".

> Also, if you were maintaining an OSS project, would you be insulted if
> someone submitted a patch that fixed problems but also reformatted all
> the code to make it more readable? (I removed a ton of perlisms and
> replaced them with English.)

One diff per problem, please, typically. Make a diff for fixing each
problem. One diff for fixing a bunch of trivial perlisms is fine. One
diff for fixing readability may be fine, but don't be surprised if it's
not applied. Don't be afraid to ask the author or mailing list what they
like. In fact, if there is a mailing list, check the archives first and
subscribe for a few days after you submit your patch.

There are a few documents around that describe how to help hacking the
kernel. They give you guidelines like this and may be useful to you
also.

Good work on giving a little back to the project. I can assure you that
your work will be appreciated. I can also assure you that you are not
likely to receive much praise or thanks for your work.

-Andy




More information about the Kclug mailing list