httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject cvs commit: apache-devsite patches.html index.html
Date Tue, 28 Apr 1998 05:30:31 GMT
brian       98/04/27 22:30:30

  Modified:    .        index.html
  Added:       .        patches.html
  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 @@
   	of the Apache Mailing Lists.
  +   <LI> How to contribute <A HREF="patches.html">code patches</A> to
  1.1                  apache-devsite/patches.html
  Index: patches.html
    <TITLE>How to Contribute Patches to Apache
  <!-- Background white, links blue (unvisited), navy (visited), red (active) -->
  <!--#include virtual="header.html" -->
     How to Contribute Patches to Apache
    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.
     Code Style
    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
    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>
     Patch Format
    <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
     Submitting your Patch
    <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=""></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="">contributed area on</A>.</P>
  <!--#include virtual="footer.html" -->

View raw message