So you want to write some code? Great! We can't do it all
ourselves, so patches are welcomed and encouraged. But, before
you jump into the code and submit your modifications, there are few
things you can do to increase the likelihood that your patch will be
How to make a patch
- e-mail the discussion list with your idea first. To keep
down on bloat, we only add needed features. Sure, it would be
great if it could make you breakfast, but chances are another tool
could do it better.
- Check the roadmap. We've got a list of features and fixes
that the tools already need but we haven't coded yet. The roadmap
is almost our plea for help.
- Follow the Amended Indian Hill C Style Guide. We're picky about
what the code looks like, and will reject a patch if it's sloppy.
- Update everything. For a patch to be complete, it must
update all associated man pages, usages and comments. Everyone
knows that code is the fun part, but the other bits have to be done too.
- Understand the license. All code is released under the same
license. If you don't like it, you shouldn't submit a patch.
The best way to make a patch is to create it against the current CVS
repository. This helps guarantee the patch will work with the
current code and makes life easier for the developers.
Submitting the patch
- Get a copy of the source code from CVS
- Make your changes
- Compile, test, fix bugs, compile, test...
- Run cvs diff -u > /path/to/file.patch
- Review patch for expected changes
Now that you have your patch, send it to the development mail
list. Be sure to include a summary of what the patch does, what
code was changed, any known issues it might have and what version of
the code the patch is against. As developers and maintainers test
and give feedback on the patch, be ready to respond, incorporate
changes and create new patches.
Once its accepted, you can sleep better knowing that you've contributed
to the project.