Third-party patches are essential to the success of Apache - the "core" developers don't have access to all platforms, and we certainly aren't using Apache in all the different ways it can be used. To that end, we try to make it as easy as possible to contribute code. However, we do have some expectations of contributors, and a process to all this, simply to help us manage the flood of contributions we could get. This page describes that process.

We have a fairly firmly-set code format we use in our code; it was one we arrived at through no small amount of debate. The format is described in our official style guide.

We also have very high expectations for code quality; and to us this means the avoidance of excessive static buffers, using the memory pool mechanism (which ensures proper cleanup), and otherwise writing thread-safe code. We also expect one or two levels of optimizations to be applied, too - is a bitmask faster for this? Is a strchr() faster than an index()? Etc. Of course it'd be nice if we had a real document describing this all, but we don't yet.

We prefer that patches be submitted in unified diff format:

diff -u file-old.c file.c

but that isn't available on all platforms. If your platform doesn't support unified diffs, please use a context diff instead:

diff -C3 file-old.c file.c

where file.c is the file affected. We should be able to feed the patch directly into the "patch" program and have it update the file or set of files. The -C3 is very important - line numbers can change on a daily basis in some code files, so having context is crucial to knowing where it all really goes.

If you are a subscriber to new-httpd, you can simply post your patch there, with the string "[PATCH]" prefixing your subject line, so everyone knows it's a patch. However, it's not guaranteed that your Patch will find an advocate within the developers' group; if we're too busy working on something else or everyone's on vacation, it could get lost in the noise. A good way to make sure it gets on our plate is to submit it through the bug database, at http://bugs.apache.org/, marking it as a "change-request".

Be aware that the core developers tend to be very conservative about what makes it into the core of Apache. Apache has a very flexible API, and any advanced functionality is likely to be pushed to be a third-party module. Portability fixes are the most important; protocol correctness is also critical for us; and we're sure there's more dumb mistakes in the code than we could shake a stick at. Those will get priority; new functionality may not.

Also, there are often times when the core developers are in "feature freeze", when they are trying to iron out the remaining bugs in the code in preparation for a release.

If your patch doesn't make it into the core, but you're still willing to let the core distribute your work, then your patch might make it to the contributed area on apache.org.