brian 98/04/27 22:30:30
Modified: . index.html
Added: . patches.html
Log:
New document describing patch process for newbies. yes, I know this is
covered in guidelines.html, but I thought having documentation specifically
for "lite" contributors would be good.
Revision Changes Path
1.21 +1 -0 apache-devsite/index.html
Index: index.html
===================================================================
RCS file: /export/home/cvs/apache-devsite/index.html,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- index.html 1998/04/20 05:50:13 1.20
+++ index.html 1998/04/28 05:30:29 1.21
@@ -44,6 +44,7 @@
>Archives</A>
of the Apache Mailing Lists.
</LI>
+ <LI> How to contribute <A HREF="patches.html">code patches</A> to Apache.
</UL>
<P>
1.1 apache-devsite/patches.html
Index: patches.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<TITLE>How to Contribute Patches to Apache
</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
<H1 ALIGN="CENTER">
How to Contribute Patches to Apache
</H1>
<P>
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.
</P>
<HR>
<H2>
Code Style
</H2>
<P>
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 <A HREF="styleguide.html">style
guide</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 expect the patch to be submitted in the form of
<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 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 <A
HREF="http://bugs.apache.org/">http://bugs.apache.org/</A>, marking
it as a "change-request".
<P>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.
<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.
<P>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 <A
HREF="http://www.apache.org/dist/contrib/">contributed area on
apache.org</A>.</P>
<!--#include virtual="footer.html" -->
</BODY>
</HTML>
Modified: . index.html
Added: . patches.html
Log:
New document describing patch process for newbies. yes, I know this is
covered in guidelines.html, but I thought having documentation specifically
for "lite" contributors would be good.
Revision Changes Path
1.21 +1 -0 apache-devsite/index.html
Index: index.html
===================================================================
RCS file: /export/home/cvs/apache-devsite/index.html,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- index.html 1998/04/20 05:50:13 1.20
+++ index.html 1998/04/28 05:30:29 1.21
@@ -44,6 +44,7 @@
>Archives</A>
of the Apache Mailing Lists.
</LI>
+ <LI> How to contribute <A HREF="patches.html">code patches</A> to Apache.
</UL>
<P>
1.1 apache-devsite/patches.html
Index: patches.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<TITLE>How to Contribute Patches to Apache
</TITLE>
</HEAD>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<BODY
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#000080"
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
<H1 ALIGN="CENTER">
How to Contribute Patches to Apache
</H1>
<P>
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.
</P>
<HR>
<H2>
Code Style
</H2>
<P>
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 <A HREF="styleguide.html">style
guide</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 expect the patch to be submitted in the form of
<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 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 <A
HREF="http://bugs.apache.org/">http://bugs.apache.org/</A>, marking
it as a "change-request".
<P>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.
<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.
<P>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 <A
HREF="http://www.apache.org/dist/contrib/">contributed area on
apache.org</A>.</P>
<!--#include virtual="footer.html" -->
</BODY>
</HTML>