From firstname.lastname@example.org Sun Dec 3 18:04:25 2000
See the project's guidelines for + more information about how the project works. ++
+ Please read How to contribute code for more information.1.1 apr-site/patches.html Index: patches.html ===================================================================
Like most Open Source projects, APR thrives on contributions from people who use it in their own projects. We want to make it as easy as possible for people to contribute code. However, we do have some expectations of code that is contributed. This is to help us review code as quickly as possible. If code is contributed that doesn't follow these guidelines, it will still be reviewed, but it will most likely take longer.
Currently APR is using the same code format as Apache. The Apache style-guide was debated for a long time before it the Apache Group settled on it, and because APR grew out of Apache code, it made sense to continue the same style. It is unlikely that this style will change at any time. The style-guide can currently be found on the Apache dev site, here.
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
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
If you are a subscriber to email@example.com, 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.
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.