db-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jvan...@apache.org
Subject cvs commit: db-site/xdocs management.xml roles.xml source.xml
Date Tue, 04 Feb 2003 06:59:40 GMT
jvanzyl     2003/02/03 22:59:40

  Modified:    .        maven.xml project.xml
               templates mail.xml
               xdocs    management.xml roles.xml source.xml
  Log:
  o Tidying things up and trying to make things consistent across the site.
  
  Revision  Changes    Path
  1.3       +5 -3      db-site/maven.xml
  
  Index: maven.xml
  ===================================================================
  RCS file: /home/cvs/db-site/maven.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- maven.xml	4 Feb 2003 04:43:06 -0000	1.2
  +++ maven.xml	4 Feb 2003 06:59:40 -0000	1.3
  @@ -1,5 +1,5 @@
   <project
  -  default="db-site"
  +  default="site"
     xmlns:maven="jelly:maven"
     xmlns:velocity="jelly:org.apache.commons.jelly.tags.velocity.VelocityTagLibrary">
   
  @@ -9,6 +9,10 @@
      |
      -->
     
  +  <preGoal name="site">
  +    <attainGoal name="db-site"/>
  +  </preGoal>
  +  
     <goal name="db-site">
     
       <maven:reactor
  @@ -44,8 +48,6 @@
         basedir="${basedir}/templates"
         template="whoweare.xml"/>
   
  -    <attainGoal name="xdoc"/>
  -    
     </goal>
   
   </project>
  
  
  
  1.4       +2 -0      db-site/project.xml
  
  Index: project.xml
  ===================================================================
  RCS file: /home/cvs/db-site/project.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- project.xml	4 Feb 2003 06:32:07 -0000	1.3
  +++ project.xml	4 Feb 2003 06:59:40 -0000	1.4
  @@ -40,5 +40,7 @@
       </dependency>
     </dependencies>
   
  +  <reports/>
  +
   </project>
   
  
  
  
  1.3       +4 -6      db-site/templates/mail.xml
  
  Index: mail.xml
  ===================================================================
  RCS file: /home/cvs/db-site/templates/mail.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- mail.xml	4 Feb 2003 04:43:06 -0000	1.2
  +++ mail.xml	4 Feb 2003 06:59:40 -0000	1.3
  @@ -12,9 +12,8 @@
         <p>
           <b>The DB Announcement List</b>
           <br/>
  -        <b>Low Traffic</b>
  -        <a href="mailto:announcements-subscribe@db.apache.org">Subscribe</a>
  -        <a href="mailto:announcements-unsubscribe@db.apache.org">Unsubscribe</a>
  +        <a href="mailto:announcements-subscribe@db.apache.org">Subscribe</a>
|
  +        <a href="mailto:announcements-unsubscribe@db.apache.org">Unsubscribe</a>
|
           <a href="http://www.mail-archive.com/announcements@db.apache.org/">Archive</a>
         </p>
         <p>
  @@ -26,9 +25,8 @@
         <p>
           <b>The DB General Project List</b>
           <br/>
  -        <b>Medium Traffic</b>
  -        <a href="mailto:general-subscribe@db.apache.org">Subscribe</a>
  -        <a href="mailto:general-unsubscribe@db.apache.org">Unsubscribe</a>
  +        <a href="mailto:general-subscribe@db.apache.org">Subscribe</a> |
  +        <a href="mailto:general-unsubscribe@db.apache.org">Unsubscribe</a>
|
           <a href="http://www.mail-archive.com/general@db.apache.org/">Archive</a>
         </p>
         <p>
  
  
  
  1.3       +51 -47    db-site/xdocs/management.xml
  
  Index: management.xml
  ===================================================================
  RCS file: /home/cvs/db-site/xdocs/management.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- management.xml	4 Feb 2003 02:38:47 -0000	1.2
  +++ management.xml	4 Feb 2003 06:59:40 -0000	1.3
  @@ -22,58 +22,62 @@
           <a href="./whoweare.html"> Project Credits</a>.
         </p>
   
  -      <p>
  -        <b>Roles</b>
  -        <br/> The PMC is responsible for the strategic direction
  -        and success of the DB Project. This governing body is expected to
  -        ensure the project's welfare and guide its overall direction. The PMC
  -        may not necessarily participate in the day-to-day coding but is
  -        involved in the overall development plans, the alleviation of any
  -        bottlenecks, the resolution of conflicts, and the overall technical
  -        success of the project.
  -      </p>
  +      <subsection name="Roles">
  +        <p>
  +          The PMC is responsible for the strategic direction
  +          and success of the DB Project. This governing body is expected to
  +          ensure the project's welfare and guide its overall direction. The PMC
  +          may not necessarily participate in the day-to-day coding but is
  +          involved in the overall development plans, the alleviation of any
  +          bottlenecks, the resolution of conflicts, and the overall technical
  +          success of the project.
  +        </p>
   
  -      <p>
  -        The PMC is answerable to the Apache Board with its Chairman serving as
  -        primary liaison.
  -      </p>
  +        <p>
  +          The PMC is answerable to the Apache Board with its Chairman serving as
  +          primary liaison.
  +        </p>
  +      </subsection>
   
  -      <p>
  -        <b>Meetings</b>
  -        <br/> The PMC
  -        <a href="pmc/index.html">meets monthly</a>
  -        with a majority of its members to discuss issues, determine strategic
  -        direction, and forward progress. These meetings may take place online,
  -        via teleconference, or via other means deemed effective by the PMC.
  -      </p>
  +      <subsection name="Meetings">
  +        <p>
  +          The PMC
  +          <a href="pmc/index.html">meets monthly</a>
  +          with a majority of its members to discuss issues, determine strategic
  +          direction, and forward progress. These meetings may take place online,
  +          via teleconference, or via other means deemed effective by the PMC.
  +        </p>
  +      </subsection>
   
  -      <p>
  -        <b>Membership</b>
  -        <br/> PMC members may resign at any time. The Chairman
  -        may resign as Chairman at any time without resigning membership to the
  -        PMC. The Chairman or any member may be removed from the PMC by a 3/4
  -        vote of the PMC.
  -      </p>
  +      <subsection name="Membership">
  +        <p>
  +          PMC members may resign at any time. The Chairman
  +          may resign as Chairman at any time without resigning membership to the
  +          PMC. The Chairman or any member may be removed from the PMC by a 3/4
  +          vote of the PMC.
  +        </p>
   
  -      <p>
  -        In the event that the number of members drops below 7, the remaining PMC
  -        members may choose to elect a new member to serve out the remainder of
  -        the annual term.  In order to be elected, a
  -        person must have served as a
  -        <a href="roles.html">Committer</a> and be
  -        nominated by a PMC Member. Once nominated, all of the PMC will vote
  -        and those receiving a 3/4 positive vote will become a member.
  -      </p>
  +        <p>
  +          In the event that the number of members drops below 7, the remaining PMC
  +          members may choose to elect a new member to serve out the remainder of
  +          the annual term.  In order to be elected, a
  +          person must have served as a
  +          <a href="roles.html">Committer</a> and be
  +          nominated by a PMC Member. Once nominated, all of the PMC will vote
  +          and those receiving a 3/4 positive vote will become a member.
  +        </p>
  +      </subsection>
   
  -      <p>
  -        <b>Creation of subprojects</b>
  -        <br/> PMC members may propose the creation
  -        of new subprojects.  Proposals are to contain the scope of the project,
  -        identify the initial source from which the project is to be populated,
  -        identify the mailing list(s) if any which are to be created, and
  -        identify the initial set of committers.  Creation of a new subproject
  -        requires approval by 3/4 vote of the PMC.
  -      </p>
  +      <subsection name="Creation of Subprojects">
  +        <p>
  +          PMC members may propose the creation
  +          of new subprojects.  Proposals are to contain the scope of the project,
  +          identify the initial source from which the project is to be populated,
  +          identify the mailing list(s) if any which are to be created, and
  +          identify the initial set of committers.  Creation of a new subproject
  +          requires approval by 3/4 vote of the PMC.
  +        </p>
  +      </subsection>
       </section>
   
     </body>
  
  
  
  1.2       +213 -209  db-site/xdocs/roles.xml
  
  Index: roles.xml
  ===================================================================
  RCS file: /home/cvs/db-site/xdocs/roles.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- roles.xml	4 Feb 2003 01:23:27 -0000	1.1
  +++ roles.xml	4 Feb 2003 06:59:40 -0000	1.2
  @@ -9,7 +9,7 @@
   
     <body>
   
  -    <section name="Roles &amp; Responsibilities">
  +    <section name="Roles and Responsibilities">
         <p>
           The roles and responsibilities that people can assume in the project
           are based on merit. Everybody can help no matter what their role.
  @@ -17,215 +17,219 @@
           obtain the right to vote and commit directly to the source repository.
         </p>
   
  -      <h2>Users</h2>
  +      <subsection name="Users">
   
  -      <p>
  -        Users are the people who use the products of the Project. People in
  -        this role aren't contributing code, but they are using the products,
  -        reporting bugs, making feature requests, and such. This is by far
  -        the most important category of people as, without users, there is no
  -        reason for the Project.
  -      </p>
  -
  -      <p>
  -        When a user starts to contribute code or documentation patches, they
  -        become a Contributor.
  -      </p>
  -
  -      <h2>Contributors</h2>
  -
  -      <p>
  -        Contributors are the people who write code or documentation patches or
  -        contribute positively to the project in other ways. A volunteer's
  -        contribution is always recognized. In source code, all volunteers
  -        who contribute to a source file may add their name to the list of
  -        authors for that file.
  -      </p>
  -
  -      <h2>Committers</h2>
  -
  -      <p>
  -        Contributors who give frequent and valuable contributions to a
  -        subproject of the Project can have their status promoted to that of
  -        a &quot;
  -        <em>Committer</em>&quot; for that subproject. A Committer
  -        has write access to the source code repository and gains voting
  -        rights allowing them to affect the future of the subproject.
  -      </p>
  -
  -      <p>
  -        In order for a Contributor to become a Committer, another Committer
  -        can nominate that Contributor or the Contributor can ask for it.
  -      </p>
  -
  -      <p>
  -        Once a Contributor is nominated, all of the Committers for a subproject
  -        will vote. If there are at least 3 positive votes and no negative
  -        votes, the Contributor is converted into a Committer and given write
  -        access to the source code repository for that subproject. This is an
  -        example offer letter that should be sent to the volunteer after
  -        3 positive votes have been received:
  -      </p>
  -
  -      <source><![CDATA[
  -      Dear Contributor,
  -
  -      The DB project would like to offer you commit privileges.
  -      We have been impressed with your contributions up till now, and
  -      believe that your involvement will improve the quality of the
  -      libraries we produce.
  -
  -      It is important that you realize that these commit privileges give
  -      you access to the specific DB project repository for which you
  -      are involved with. They do not provide commit access to any other
  -      Apache based project. Those projects will have to grant you commit
  -      privileges themselves.
  -
  -      If you are interested in having commit privileges, please just let us
  -      know, and we will setup an account on apache.org. It would expedite
  -      the process if you could provide your preferred account name and
  -      possibly a public SSH key. This process could take a few days once
  -      we get this information.
  -
  -      We all hope that you accept this invitation.
  -
  -      The DB Project Management Committee.
  -      ]]></source>
  -
  -      <p>
  -        Once there are 3 positive votes and the response to the above letter
  -        has been received, someone from the project community who already has
  -        commit access should send email to:
  -        <strong>root at apache.org</strong>
  -        that the account should be created. The following information
  -        must be included in the email:
  -      </p>
  -
  -      <ul>
  -        <li>
  -          The name and email address of the new user.
  -          (ie: John Smith &lt;john.smith@foo.com&gt;)
  -        </li>
  -        <li>
  -          Suggested account userid. This is optional.
  -          (ie: jmsith)
  -        </li>
  -        <li>
  -          The project that the user should be given access to.
  -          (ie: DB Foo)
  -        </li>
  -        <li>
  -          The results of the votes. In other words, the names and email
  -          addresses of the committers who approved the addition.
  -        </li>
  -      </ul>
  -
  -      <p>
  -        The new committer should also send an email to
  -        <strong>asf at jaguNET.com</strong>
  -        with the following information (please cut and paste to return format):
  -      </p>
  -
  -      <blockquote>
  -        Name: {your name}
  -        <br/>
  -        Email: {your email address on the ASF lists}
  -        <br/>
  -        Projects: {comma separated list of ASF projects to which you have commit access}
  -        <br/>
  -        Key: {a blank line followed by your key}
  -      </blockquote>
  -
  -      <p>For example:</p>
  -
  -      <blockquote>
  -        Name: Joe Foobar
  -        <br/>
  -        Email: joe@byteme.com
  -        <br/>
  -        Projects: Tomcat, httpd
  -        <br/>
  -        Key:
  -        <br/>
  -        adklajdAL()@ N*@U)U@()@@ @)U@
  -      </blockquote>
  -
  -      <p>
  -        Finally, a new committer should also submit a signed copy of the Contributor
  -        License Agreement to the ASF. See the
  -        <a href="agreement.html">
  -          <strong>Contributor
  -            License Agreement page</strong>
  -        </a> for details.
  -      </p>
  -
  -      <p>
  -        Note 0: If a committer already has an account on the apache.org server
  -        and the committer needs commit access to additional projects, then all
  -        that needs to be done is to have the user notify
  -        pmc@db.apache.org with the results of the voting (as documented
  -        above) and the user will be given access. In other words, the root
  -        email address should only be used on the basis of new account
  -        creation.
  -      </p>
  -
  -      <p>
  -        Note 1: All committers will be given access to the db-site module
  -        on request. In other words, committers should be able to update the
  -        main DB website.
  -      </p>
  -      
  -      <!--
  -      
  -      This may be required shortly. But not currently. jvz.
  -      
  -      <p>
  -        Note 2: If the module that the committer needs access to is a sub
  -        module within a project (ie: jakarta-turbine-tdk or
  -        jakarta-avalon-logkit), it is up to the individual project to
  -        determine how to deal with giving out access. In other words, access
  -        may be granted by default to all sub modules or it can be granted by
  -        vote.
  -      </p>
  -      
  -      -->
  -      
  -      <p>
  -        At times, Committers may go inactive for a variety of reasons. A
  -        Committer that has been inactive for 6 months or more may lose their
  -        status as a Committer. Getting access back is as simple as
  -        re-requesting it on the project's Developer mailing list.
  -      </p>
  -
  -      <p>
  -        A list of some of our current Committers can be found in our
  -        <a
  -          href="./whoweare.html">Project Credits</a>.
  -      </p>
  -
  -      <p>
  -        <h2>Project Management Committee (PMC)</h2>
  -        Committers who frequently participate with valuable contributions may
  -        have their status promoted to that of a &quot;
  -        <em>Project Management
  -          Committee Member</em>&quot;. This committee is the official managing
  -        body of the DB Project and is responsible for setting overall
  -        project direction. In order to become a Member, someone on
  -        the PMC must nominate the Committer. The individual may then be
  -        approved with a 3/4 majority of the PMC.
  -      </p>
  -
  -      <p>
  -        To view the Project Management Committee bylaws,
  -        <a href="management.html">
  -          click here</a>.
  -      </p>
  -
  -      <p>
  -        A list of our current PMC Members can be found in our
  -        <a
  -          href="./whoweare.html">Project Credits</a>.
  -      </p>
  +        <p>
  +          Users are the people who use the products of the Project. People in
  +          this role aren't contributing code, but they are using the products,
  +          reporting bugs, making feature requests, and such. This is by far
  +          the most important category of people as, without users, there is no
  +          reason for the Project.
  +        </p>
  +
  +        <p>
  +          When a user starts to contribute code or documentation patches, they
  +          become a Contributor.
  +        </p>
  +      </subsection>
  +
  +      <subsection name="Contributors">
  +
  +        <p>
  +          Contributors are the people who write code or documentation patches or
  +          contribute positively to the project in other ways. A volunteer's
  +          contribution is always recognized. In source code, all volunteers
  +          who contribute to a source file may add their name to the list of
  +          authors for that file.
  +        </p>
  +      </subsection>
  +
  +      <subsection name="Committers">
  +
  +        <p>
  +          Contributors who give frequent and valuable contributions to a
  +          subproject of the Project can have their status promoted to that of
  +          a &quot;
  +          <em>Committer</em>&quot; for that subproject. A Committer
  +          has write access to the source code repository and gains voting
  +          rights allowing them to affect the future of the subproject.
  +        </p>
  +
  +        <p>
  +          In order for a Contributor to become a Committer, another Committer
  +          can nominate that Contributor or the Contributor can ask for it.
  +        </p>
  +
  +        <p>
  +          Once a Contributor is nominated, all of the Committers for a subproject
  +          will vote. If there are at least 3 positive votes and no negative
  +          votes, the Contributor is converted into a Committer and given write
  +          access to the source code repository for that subproject. This is an
  +          example offer letter that should be sent to the volunteer after
  +          3 positive votes have been received:
  +        </p>
  +
  +        <source><![CDATA[
  +        Dear Contributor,
  +
  +        The DB project would like to offer you commit privileges.
  +        We have been impressed with your contributions up till now, and
  +        believe that your involvement will improve the quality of the
  +        libraries we produce.
  +
  +        It is important that you realize that these commit privileges give
  +        you access to the specific DB project repository for which you
  +        are involved with. They do not provide commit access to any other
  +        Apache based project. Those projects will have to grant you commit
  +        privileges themselves.
  +
  +        If you are interested in having commit privileges, please just let us
  +        know, and we will setup an account on apache.org. It would expedite
  +        the process if you could provide your preferred account name and
  +        possibly a public SSH key. This process could take a few days once
  +        we get this information.
  +
  +        We all hope that you accept this invitation.
  +
  +        The DB Project Management Committee.
  +        ]]></source>
  +
  +        <p>
  +          Once there are 3 positive votes and the response to the above letter
  +          has been received, someone from the project community who already has
  +          commit access should send email to:
  +          <strong>root at apache.org</strong>
  +          that the account should be created. The following information
  +          must be included in the email:
  +        </p>
  +
  +        <ul>
  +          <li>
  +            The name and email address of the new user.
  +            (ie: John Smith &lt;john.smith@foo.com&gt;)
  +          </li>
  +          <li>
  +            Suggested account userid. This is optional.
  +            (ie: jmsith)
  +          </li>
  +          <li>
  +            The project that the user should be given access to.
  +            (ie: DB Foo)
  +          </li>
  +          <li>
  +            The results of the votes. In other words, the names and email
  +            addresses of the committers who approved the addition.
  +          </li>
  +        </ul>
  +
  +        <p>
  +          The new committer should also send an email to
  +          <strong>asf at jaguNET.com</strong>
  +          with the following information (please cut and paste to return format):
  +        </p>
  +
  +        <blockquote>
  +          Name: {your name}
  +          <br/>
  +          Email: {your email address on the ASF lists}
  +          <br/>
  +          Projects: {comma separated list of ASF projects to which you have commit access}
  +          <br/>
  +          Key: {a blank line followed by your key}
  +        </blockquote>
  +
  +        <p>For example:</p>
  +
  +        <blockquote>
  +          Name: Joe Foobar
  +          <br/>
  +          Email: joe@byteme.com
  +          <br/>
  +          Projects: Tomcat, httpd
  +          <br/>
  +          Key:
  +          <br/>
  +          adklajdAL()@ N*@U)U@()@@ @)U@
  +        </blockquote>
  +
  +        <p>
  +          Finally, a new committer should also submit a signed copy of the Contributor
  +          License Agreement to the ASF. See the
  +          <a href="agreement.html">
  +            <strong>Contributor
  +              License Agreement page</strong>
  +          </a> for details.
  +        </p>
  +
  +        <p>
  +          Note 0: If a committer already has an account on the apache.org server
  +          and the committer needs commit access to additional projects, then all
  +          that needs to be done is to have the user notify
  +          pmc@db.apache.org with the results of the voting (as documented
  +          above) and the user will be given access. In other words, the root
  +          email address should only be used on the basis of new account
  +          creation.
  +        </p>
  +
  +        <p>
  +          Note 1: All committers will be given access to the db-site module
  +          on request. In other words, committers should be able to update the
  +          main DB website.
  +        </p>
  +
  +        <!--
  +
  +        This may be required shortly. But not currently. jvz.
  +
  +        <p>
  +          Note 2: If the module that the committer needs access to is a sub
  +          module within a project (ie: jakarta-turbine-tdk or
  +          jakarta-avalon-logkit), it is up to the individual project to
  +          determine how to deal with giving out access. In other words, access
  +          may be granted by default to all sub modules or it can be granted by
  +          vote.
  +        </p>
  +
  +        -->
  +
  +        <p>
  +          At times, Committers may go inactive for a variety of reasons. A
  +          Committer that has been inactive for 6 months or more may lose their
  +          status as a Committer. Getting access back is as simple as
  +          re-requesting it on the project's Developer mailing list.
  +        </p>
  +
  +        <p>
  +          A list of some of our current Committers can be found in our
  +          <a
  +            href="./whoweare.html">Project Credits</a>.
  +        </p>
  +      </subsection>
  +
  +      <subsection name="Management Committee (PMC)">
  +        <p>
  +          Committers who frequently participate with valuable contributions may
  +          have their status promoted to that of a &quot;
  +          <em>Project Management
  +            Committee Member</em>&quot;. This committee is the official managing
  +          body of the DB Project and is responsible for setting overall
  +          project direction. In order to become a Member, someone on
  +          the PMC must nominate the Committer. The individual may then be
  +          approved with a 3/4 majority of the PMC.
  +        </p>
  +
  +        <p>
  +          To view the Project Management Committee bylaws,
  +          <a href="management.html">
  +            click here</a>.
  +        </p>
  +
  +        <p>
  +          A list of our current PMC Members can be found in our
  +          <a
  +            href="./whoweare.html">Project Credits</a>.
  +        </p>
  +      </subsection>
       </section>
   
     </body>
  
  
  
  1.2       +182 -179  db-site/xdocs/source.xml
  
  Index: source.xml
  ===================================================================
  RCS file: /home/cvs/db-site/xdocs/source.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- source.xml	4 Feb 2003 01:23:27 -0000	1.1
  +++ source.xml	4 Feb 2003 06:59:40 -0000	1.2
  @@ -28,185 +28,188 @@
           for links to subproject conventions.
         </p>
   
  -      <h2>License</h2>
  -
  -      <p>
  -        All source code committed to the Project's repositories must be
  -        covered by the
  -        <a href="http://www.apache.org/foundation/licence-FAQ.html">Apache License</a>
  -        or contain a copyright and license that allows redistribution under the same
  -        conditions as the Apache License.
  -      </p>
  -
  -      <p>
  -        Committers should update the copyright notice on the Apache License to
  -        include the current year when they revise a source file. If it is 2002,
  -        and you revise a source file from 1999, change the copyright notice in
  -        the license to cite "1999, 2002". If the file was from 2001, we would
  -        change it to 2001-2002. And so forth. This will happen most often in the
  -        early part of a year, but maintenance of the copyright date should occur
  -        year-round, as needed.
  -      </p>
  -
  -      <p>
  -        Any code, document, or binary that is committed to the Project's
  -        repositories, but not being donated to the ASF, must be clearly marked as
  -        such. All contributors should have a
  -        <a href="agreement.html">Contributor
  -          License Agreement</a> on  file.
  -      </p>
  -
  -      <p>
  -        Any
  -        <a href="jars.html">JAR</a> committed to the Project's repositories
  -        <strong>must</strong> be licensed for redistribution. BSD and MPL style
  -        licenses are generally fine, but many
  -        <a href="jars.html">Sun JARs</a>
  -        do not permit redistribution.
  -      </p>
  -
  -      <h2>Status Files</h2>
  -
  -      <p>
  -        Each of the Project's active source code repositories contain a file
  -        named
  -        <span class="code">STATUS</span> which is used to keep track
  -        of the agenda and plans for work within that repository. The status
  -        file includes information about release plans, a summary of code
  -        changes committed since the last release, a list of proposed changes
  -        that are under discussion, brief notes about items that individual
  -        developers are working on or want discussion about, and anything
  -        else that may be useful to help the group track progress.
  -      </p>
  -
  -      <p>
  -        It is recommended that the active status files are automatically
  -        posted to the developer mailing lists three times per week.
  -      </p>
  -
  -      <h2>Branches</h2>
  -
  -      <p>
  -        Groups are allowed to create a branch for release cycles, etc. They
  -        are expected to merge completely back with the main branch as soon as
  -        their release cycle is complete. All branches currently in use should
  -        be documented by the respective projects. For example,
  -        <a
  -          href="/turbine/branches.html">Turbine</a> has page on the site that
  -        details the branches currently in use.
  -      </p>
  -
  -      <h2>Changes</h2>
  -
  -      <p>
  -        Simple patches to fix bugs can be committed then reviewed. With a
  -        commit-then-review process, the Committer is trusted to have a high
  -        degree of confidence in the change.
  -      </p>
  -
  -      <p>
  -        Doubtful changes, new features, and large scale overhauls need to be
  -        discussed before committing them into the repository. Any change
  -        that affects the semantics of an existing API function, the size of
  -        the program, configuration data formats, or other major areas must
  -        receive consensus approval before being committed.
  -      </p>
  -
  -      <p>
  -        Related changes should be committed as a group, or very closely
  -        together. Half complete projects should never be committed to the
  -        main branch of a development repository. All code changes must be
  -        successfully compiled on the developer's platform before being
  -        committed. Also, any unit tests should also pass.
  -      </p>
  -
  -      <p>
  -        The current source code tree for a subproject should be capable of
  -        complete compilation at all times. However, it is sometimes
  -        impossible for a developer on one platform to avoid breaking some
  -        other platform when a change is committed. If it is anticipated that
  -        a given change will break the build on some other platform, the
  -        committer must indicate that in the commit message.
  -      </p>
  -
  -      <p>
  -        A committed change must be reversed if it is vetoed by one of the
  -        voting members and the veto conditions cannot be immediately
  -        satisfied by the equivalent of a &quot;bug fix&quot; commit. The
  -        veto must be rescinded before the change can be included in any
  -        public release.
  -      </p>
  -
  -      <h2>Patches</h2>
  -
  -      <p>
  -        When a specific change to a product is proposed for discussion or
  -        voting on the appropriate development mailing list, it should be
  -        presented in the form of input to the patch command. When sent to the
  -        mailing list, the message should contain a Subject beginning with
  -        <span class="code">[PATCH]</span> and a distinctive one-line summary
  -        in the subject corresponding to the action item for that patch.
  -      </p>
  -
  -      <p>
  -        The patch should be created by using the
  -        <span class="code">diff
  -          -u</span> command from the original software file(s) to the modified
  -        software file(s). It is recommended that you submit patches against
  -        the latest CVS versions of the software in order to avoid conflicts.
  -        This will also ensure that you are not submitting a patch for a problem
  -        that has already been resolved.
  -      </p>
  -
  -      <p>
  -        For example:
  -      </p>
  -
  -      <source>
  -        diff -u Main.java.orig Main.java >> patchfile.txt
  -      </source>
  -
  -      <p>or (preferred)</p>
  -
  -      <source>
  -        cvs diff -u Main.java >> patchfile.txt
  -      </source>
  -
  -      <p>or (Win32)</p>
  -
  -      <p>
  -        You can use
  -        <a href="http://www.wincvs.org/">WinCVS</a> for a nice GUI or
  -        you can install
  -        <a href="http://sources.redhat.com/cygwin/">Cygwin</a> which
  -        will enable you to use the bash shell and also installs a lot of other
  -        utilities (such as diff and patch) that will turn your PC into a virtual
  -        Unix machine.
  -      </p>
  -
  -      <p>
  -        All patches necessary to address an action item should be
  -        concatencated within a single patch message. If later modification
  -        to the patch proves necessary, the entire new patch should be posted
  -        and not just the difference between the two patches.
  -      </p>
  -
  -      <p>
  -        If your email client line wraps the patch, consider placing the patch
  -        file up on a website and sending a message to the development list
  -        with the URL so that the developers with commit access can download
  -        the commit the patch file more easily. You can also add the patch as
  -        part of a bug report.
  -      </p>
  -
  -      <p>
  -        When a patch has been checked into CVS, the person who checked in the
  -        patch should send a message to the person who sent the patch in as
  -        well as the mailing list specifying that the patch has been checked
  -        in. The reason is that not everyone watches commit messages and it is
  -        helpful for others to know what has been checked in and when in order
  -        to help prevent people from applying the patch at the same time.
  -      </p>
  +      <subsection name="License">
  +        <p>
  +          All source code committed to the Project's repositories must be
  +          covered by the
  +          <a href="http://www.apache.org/foundation/licence-FAQ.html">Apache License</a>
  +          or contain a copyright and license that allows redistribution under the same
  +          conditions as the Apache License.
  +        </p>
  +
  +        <p>
  +          Committers should update the copyright notice on the Apache License to
  +          include the current year when they revise a source file. If it is 2002,
  +          and you revise a source file from 1999, change the copyright notice in
  +          the license to cite "1999, 2002". If the file was from 2001, we would
  +          change it to 2001-2002. And so forth. This will happen most often in the
  +          early part of a year, but maintenance of the copyright date should occur
  +          year-round, as needed.
  +        </p>
  +
  +        <p>
  +          Any code, document, or binary that is committed to the Project's
  +          repositories, but not being donated to the ASF, must be clearly marked as
  +          such. All contributors should have a
  +          <a href="agreement.html">Contributor
  +            License Agreement</a> on  file.
  +        </p>
  +
  +        <p>
  +          Any
  +          <a href="jars.html">JAR</a> committed to the Project's repositories
  +          <strong>must</strong> be licensed for redistribution. BSD and MPL
style
  +          licenses are generally fine, but many
  +          <a href="jars.html">Sun JARs</a>
  +          do not permit redistribution.
  +        </p>
  +      </subsection>
  +
  +      <subsection name="Status Files">
  +        <p>
  +          Each of the Project's active source code repositories contain a file
  +          named
  +          <span class="code">STATUS</span> which is used to keep track
  +          of the agenda and plans for work within that repository. The status
  +          file includes information about release plans, a summary of code
  +          changes committed since the last release, a list of proposed changes
  +          that are under discussion, brief notes about items that individual
  +          developers are working on or want discussion about, and anything
  +          else that may be useful to help the group track progress.
  +        </p>
  +
  +        <p>
  +          It is recommended that the active status files are automatically
  +          posted to the developer mailing lists three times per week.
  +        </p>
  +      </subsection>
  +
  +      <subsection name="Branches">
  +
  +        <p>
  +          Groups are allowed to create a branch for release cycles, etc. They
  +          are expected to merge completely back with the main branch as soon as
  +          their release cycle is complete. All branches currently in use should
  +          be documented by the respective projects. For example,
  +          <a
  +            href="/turbine/branches.html">Turbine</a> has page on the site that
  +          details the branches currently in use.
  +        </p>
  +      </subsection>
  +
  +      <subsection name="Changes">
  +
  +        <p>
  +          Simple patches to fix bugs can be committed then reviewed. With a
  +          commit-then-review process, the Committer is trusted to have a high
  +          degree of confidence in the change.
  +        </p>
  +
  +        <p>
  +          Doubtful changes, new features, and large scale overhauls need to be
  +          discussed before committing them into the repository. Any change
  +          that affects the semantics of an existing API function, the size of
  +          the program, configuration data formats, or other major areas must
  +          receive consensus approval before being committed.
  +        </p>
  +
  +        <p>
  +          Related changes should be committed as a group, or very closely
  +          together. Half complete projects should never be committed to the
  +          main branch of a development repository. All code changes must be
  +          successfully compiled on the developer's platform before being
  +          committed. Also, any unit tests should also pass.
  +        </p>
  +
  +        <p>
  +          The current source code tree for a subproject should be capable of
  +          complete compilation at all times. However, it is sometimes
  +          impossible for a developer on one platform to avoid breaking some
  +          other platform when a change is committed. If it is anticipated that
  +          a given change will break the build on some other platform, the
  +          committer must indicate that in the commit message.
  +        </p>
  +
  +        <p>
  +          A committed change must be reversed if it is vetoed by one of the
  +          voting members and the veto conditions cannot be immediately
  +          satisfied by the equivalent of a &quot;bug fix&quot; commit. The
  +          veto must be rescinded before the change can be included in any
  +          public release.
  +        </p>
  +      </subsection>
  +
  +      <subsection name="Patches">
  +
  +        <p>
  +          When a specific change to a product is proposed for discussion or
  +          voting on the appropriate development mailing list, it should be
  +          presented in the form of input to the patch command. When sent to the
  +          mailing list, the message should contain a Subject beginning with
  +          <span class="code">[PATCH]</span> and a distinctive one-line summary
  +          in the subject corresponding to the action item for that patch.
  +        </p>
  +
  +        <p>
  +          The patch should be created by using the
  +          <span class="code">diff
  +            -u</span> command from the original software file(s) to the modified
  +          software file(s). It is recommended that you submit patches against
  +          the latest CVS versions of the software in order to avoid conflicts.
  +          This will also ensure that you are not submitting a patch for a problem
  +          that has already been resolved.
  +        </p>
  +
  +        <p>
  +          For example:
  +        </p>
  +
  +        <source>
  +          diff -u Main.java.orig Main.java >> patchfile.txt
  +        </source>
  +
  +        <p>or (preferred)</p>
  +
  +        <source>
  +          cvs diff -u Main.java >> patchfile.txt
  +        </source>
  +
  +        <p>or (Win32)</p>
  +
  +        <p>
  +          You can use
  +          <a href="http://www.wincvs.org/">WinCVS</a> for a nice GUI or
  +          you can install
  +          <a href="http://sources.redhat.com/cygwin/">Cygwin</a> which
  +          will enable you to use the bash shell and also installs a lot of other
  +          utilities (such as diff and patch) that will turn your PC into a virtual
  +          Unix machine.
  +        </p>
  +
  +        <p>
  +          All patches necessary to address an action item should be
  +          concatencated within a single patch message. If later modification
  +          to the patch proves necessary, the entire new patch should be posted
  +          and not just the difference between the two patches.
  +        </p>
  +
  +        <p>
  +          If your email client line wraps the patch, consider placing the patch
  +          file up on a website and sending a message to the development list
  +          with the URL so that the developers with commit access can download
  +          the commit the patch file more easily. You can also add the patch as
  +          part of a bug report.
  +        </p>
  +
  +        <p>
  +          When a patch has been checked into CVS, the person who checked in the
  +          patch should send a message to the person who sent the patch in as
  +          well as the mailing list specifying that the patch has been checked
  +          in. The reason is that not everyone watches commit messages and it is
  +          helpful for others to know what has been checked in and when in order
  +          to help prevent people from applying the patch at the same time.
  +        </p>
  +      </subsection>
   
       </section>
   
  
  
  

Mime
View raw message