As with most major software packages, third-party patches are key to development of ht://Dig. Contributed patches have brought many new features and bug-fixes to ht://Dig. To make installing patches easier for both the core developers and contributers, here are a few guidelines.
This ensures you won't be duplicating work, such as fixing a bug in the latest release that has been fixed in the tree. Since the CVS code changes fairly frequently, this also ensures that your patch will have accurate line numbers (and will go into the CVS tree faster).
diff -c3p oldfile newfile" or
"diff -up oldfile newfile"
If you don't have a version of diff that supports these options, grab the latest version of GNU diff. These options add several lines of context around your patch. As mentioned earlier, the CVS tree changes frequently, so sometimes the patch won't fit exactly into the source. With some context, it's easier to find the proper location.
We're human--it's much easier to understand exactly what a patch is doing if it's not trying to add 20 features or fix 20 bugs. (Hopefully there won't be a need to fix 20 bugs!) If you want to add several features or fix several bugs, break the patch up into one for each request. The faster someone can understand your patch, the faster it will go into the source. Everyone benefits from faster, quality development.
We don't have access to every platform and don't expect that you do either. But if you can test a patch or have someone reliable test a patch thoroughly, it's very helpful. In particular, it's helpful to have someone test a patch on a different system. Maybe your patch relied on an external program that needs to be instaled, or that header file you need has a different format on another system.
Hopefully this is pretty obvious. List members are sources of inspiration and reliable testers. Besides, this ensures that people get the patch before the next release. If you include something like [PATCH] in the subject, it's likely to catch people's attention too. :-)
Since the releases obviously have to have documentation, patches with documentation and examples already supplied will be accepted much sooner. Obviously small bug-fixes do not need documentation.
The documentation for attributes is now generated from htcommon/defaults.cc by script. So all features adding attributes must include changes to defaults.cc for categorizing the attribute and documentation.
The biggest problem in merging patches is figuring out what they're supposed to do. This will help document the patch for anyone applying it and make it easier to maintain the ChangeLog. :-)
These aren't hard and fast rules. We'll take contributions in any form--it may not be obvious, but we do read all the e-mail we get. So keep those patches and feature requests coming!