Thread: [OpenE-dev] [cvs] opene/src/doc cvs.xml

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Added:       src/doc  cvs.xml
Log:

By David Blevins, on 02d/02/04 23:11:05

Revision  Changes    Path
1.1                  opene/src/doc/cvs.xml

Index: cvs.xml
===================================================================
<?xml version="1.0" encoding="ISO-8859-1"?>
<document url="http://opene.sf.net/cvs.xml">
  <body>
    <title>CVS Access</title>

    <section title="Getting the Source">
    <p>
    Getting involved in any Open Source project requires the source.  The 
    standard tool for managing source code in open source projects is CVS. 
    If you are not familiar with CVS, take a moment to read our 
    <a href="cvs-faq.html">CVS FAQ</a>.
    </p>

    <p>    
    If you have cvs already installed and are ready to go, the following two commands
    are all you need to get the source. The first command logs you into the system, when 
    it prompts you for the CVS password, simply hit the Enter key.
    </p>    
    <p>    
    <command>cvs -d:pserver:ano...@cv...:/cvsroot/opene login</command>
    </p>    
    <p>    
    <command>cvs -z3 -d:pserver:ano...@cv...:/cvsroot/opene co opene</command>
    </p>    

    <p>    
    NOTE: The 'cvs ....' commands above should be on one line and executed as one command. 
    </p>    

    <p>    
    If you are a new user to cvs, the above steps may seem overly simplistic to you.
    For a more detailed explanation of the login/checkout process, <a href="quickstart-cvs.html">click here</a>.
    </p>    

    </section>

    <section title="Guidelines For Code Contribution">

      <p>All code contributions must be under the license and copyright of the
         project to which you contribute. By contributing code you agree that we
         can distribute the contribution under the terms of the license, that it
         can be distributed without any royalties, copyright, trademark, patent or
         other legal lock ups. Open source means no discrimination against any
         group or individual that may wish to use the code.</p>

      <p>When making a contribution you are granting us a world wide, royalty free,
         unlimited in time license to re-distribute the code under the Exolab license.
         In case you wonder, you remain the original author and copyright holder
         of the contribution, you just give other people a license to use it as well.
         Thank you.</p>

      <p>It's perfectly ok to put your name and e-mail address in the code.</p>

      <p>When sending patches, diff files with context (3 lines before, 3 lines
         after) work best:
<pre><![CDATA[
  cvs diff -c <file>
or
  diff -c <file>
]]></pre>
      </p>

    </section>

    <section title="Guidelines For Committers">

        <section title="Familiarize yourself" ref-id="rule1">

        <p><i>Familiarize yourself.</i> Take some time to understand the directory
        structure, build environment, interaction between components, coding and commenting
        style. Nothing out of the ordinary, but still not all projects are identical.</p>
        </section>

        <section title="Let is know" ref-id="rule2">

        <p><i>Before starting to work please advertise.</i> It's pointless to have two people
        working on the same feature. Send an e-mail to the developer mailing list and
        announce what and how. If you don't get a reply within a day, you can assume the
        coast is clear.</p>
        </section>

        <section title="Test, test, test" ref-id="rule3">

        <p><i>Test before you commit.</i> Before committing any changes run a <tt>cvs update</tt>
        to make sure you have the latest code base. Run the test cases to make sure nothing
        is broken.</p>
        </section>

        <section title="Commit all at once" ref-id="rule4">

        <p><i>Commit all at once.</i> If the change involves more than a single file, make sure
        to commit all the changes together. A partially committed CVS tree is not a pretty
        sight. No lunch breaks, meetings or sleep during commits.</p>
        </section>

        <section title="Be ready to receive complaints" ref-id="rule5">

        <p><i>Be ready to receive complaints.</i> Hopefully all works fine, but if changes
        to break existing code, people will complain. Be ready to answer their e-mails
        and apply the proper fixes. No going on vacation five minutes after a commit.</p>
        </section>

        <section title="Give yourself some credit" ref-id="rule6">

        <p><i>Put your name so people know who to credit.</i> (Also who to blame). Initials
        work just fine, your full name and e-mail address are already on the main page.
        If you've added a new file, feel free to put your name and e-mail address as the
        author. If you're fixing a file, put your initials on the comment.</p>
        </section>

        <section title="Observe release time" ref-id="rule7">

        <p><i>Observe release time.</i> We're going to announce a new release five hours prior
        to making it. That gives you four hours to commit any changes, make sure nothing
        breaks. Don't leave the computer before the release is done. If you can't make
        it, there's alway the next release.</p>
        </section>

        <section title="Document what you've done" ref-id="rule8">

        <p><i>Document what you've done.</i> In-code documentation, CVS commit messages,
        and the changelog. Major changes should always be recorded in the changelog.</p>
        </section>

        <section title="Use the document DTD" ref-id="rule9">

        <p><i>Use the document DTD.</i> When adding new documentation use the document DTD.
        Specify the proper document URL, properties, body and section. Everything
        inside the body/header/section is XHTML. That means well formed HTML.
        If it's not, you won't be able to build the docs.</p>

        <p>We don't have a particular style for documentation, and we do appreciate
        a sense of humor, sarcasm and literary expression. Just don't overdue it,
        and please, no cliche.</p>
        </section>
    </section>

    <section title="Licensing Policy">

      <p>We have a simple policy regarding distributable code. Either it's open source
         and compatible in license, or it's an API that is freely distributable.</p>

      <p>BSD-like and MPL-like licenses are compatible and can be mixed in the
         same code base. Liberal licenses and public domain are also fine.</p>

      <p>APIs need not be open source, but they must be freely distributable.
         As a policy we like to stick with standard APIs and never modify them,
         so the license has little affect. We do favor public domains APIs like
         SAX over tightly controlled APIs, and hopefully we can all do something
         about that.</p>

      <p>Pay special attention to pre-release availability and trademark issues.
         Several committees and companies require proper trademark acknowledgement in
         the documentation. Some of them are available for distribution only
         once they have been formally released. This policy applies to all APIs
         coming from Sun.</p>

    </section>

    <section title="Other sources of information">

<p>Here is the CVS website.
<a href="http://www.sourcegear.com/CVS">http://www.sourcegear.com/CVS</a>
</p>
<p>
Win95/NT/2000(NT 5.0) related material
<a href="http://www.sourcegear.com/CVS/Dev/codewindow">http://www.sourcegear.com/CVS/Dev/codewindow</a>
</p>
<p>
More advanced documentation.
<a href="http://www.loria.fr/~molli/cvs-index.html"> http://www.loria.fr/~molli/cvs-index.html</a>
</p>

 </section>

  </body>
</document>

Thread: [OpenE-dev] [cvs] opene/src/doc cvs.xml

opene-development