apr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@locus.apache.org
Subject cvs commit: apr-site patches.html index.html
Date Sun, 03 Dec 2000 18:04:25 GMT
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>
  
  
  

Mime
View raw message