You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by rb...@locus.apache.org on 2000/12/03 19:04:25 UTC
cvs commit: apr-site patches.html index.html
rbb 00/12/03 10:04:24
Modified: . index.html
Added: . patches.html
Log:
Add a doc about contributing patches.
Revision Changes Path
1.9 +4 -0 apr-site/index.html
Index: index.html
===================================================================
RCS file: /home/cvs/apr-site/index.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- index.html 2000/12/01 23:05:16 1.8
+++ index.html 2000/12/03 18:04:24 1.9
@@ -39,6 +39,10 @@
</p>
<p>
See the <a href="guidelines.html">project's guidelines</a> for
+ more information about how the project works.
+ </p>
+ <p>
+ Please read <a href="patches.html">How to contribute code</a> for
more information.
</p>
1.1 apr-site/patches.html
Index: patches.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<title>How to Contribute Patches</title>
</head>
<body>
<h1>Creating Patches</h1>
<p>
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.
</p>
<HR>
<H2>
Code Style
</H2>
<P>
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, <A HREF="http://dev.apache.org:/styleguide.html">here</A>.
</P>
<P>
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.</P>
<HR>
<H2>
Patch Format
</H2>
<P>We prefer that patches be submitted in unified diff format:
<BLOCKQUOTE><CODE>diff -u file-old.c file.c</CODE></BLOCKQUOTE>
<P>but that isn't available on all platforms. If your platform doesn't
support unified diffs, please use a context diff instead:
<BLOCKQUOTE><CODE>diff -C3 file-old.c file.c</CODE></BLOCKQUOTE>
<P>where <CODE>file.c</CODE> 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 <code>-C3</code> 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.</P>
<HR>
<H2>
Submitting your Patch
</H2>
<P>
<B>If</B> you are a subscriber to dev@apr.apache.org, 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.
<P>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.
<hr>
<address><a href="mailto:rbb@apache.org">Ryan Bloom</a></address>
<!-- Created: Fri Nov 24 16:27:22 PST 2000 -->
<!-- hhmts start -->
Last modified: Fri Nov 24 16:42:42 PST 2000
<!-- hhmts end -->
</body>
</html>