jakarta-site-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dun...@hyperreal.org
Subject cvs commit: jakarta-site/mission index.html
Date Thu, 02 Sep 1999 04:03:30 GMT
duncan      99/09/01 21:03:30

  Modified:    .        STATUS contact.html index.html legal.html
                        main.template style.css
               mission  index.html
  Added:       guidelines communication.html communication.htsrc
                        decisions.html decisions.htsrc index.html
                        index.htsrc management.html management.htsrc
                        roles.html roles.htsrc source.html source.htsrc
  Log:
  Broke project guidelines up into a set of smaller chunks. The original
  one file long guidelines was *way* too long. Also minor tweaks to the
  template. More coming....
  
  Revision  Changes    Path
  1.2       +3 -1      jakarta-site/STATUS
  
  Index: STATUS
  ===================================================================
  RCS file: /home/cvs/jakarta-site/STATUS,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- STATUS	1999/09/01 19:07:14	1.1
  +++ STATUS	1999/09/02 04:03:22	1.2
  @@ -1,5 +1,5 @@
   STATUS: jakarta-site
  -	$Id: STATUS,v 1.1 1999/09/01 19:07:14 duncan Exp $
  +	$Id: STATUS,v 1.2 1999/09/02 04:03:22 duncan Exp $
   
   NEXT RELEASE:
   
  @@ -10,6 +10,8 @@
   	Need approval on Guidelines.
   
   	Need comments on Contact Info.
  +
  +        Need to set up core@jakarta.apache.org
   
   	Need to set up jakarta@jakarta.apache.org alias to send mail
   	to core@jakarta.apache.org and give an autoresponse back to
  
  
  
  1.2       +17 -4     jakarta-site/contact.html
  
  Index: contact.html
  ===================================================================
  RCS file: /home/cvs/jakarta-site/contact.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- contact.html	1999/09/01 19:07:14	1.1
  +++ contact.html	1999/09/02 04:03:22	1.2
  @@ -1,10 +1,16 @@
   <html>
   <head>
  +<!-- $Id: contact.html,v 1.2 1999/09/02 04:03:22 duncan Exp $ -->
  +<!-- Content head element begins -->
   
  +
   <title>Contact Information</title>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   
   
  +
  +<!-- Content head element ends -->
  +
   <link rel="stylesheet" href="/style.css"></head>
   
   <body bgcolor="#FFFFFF">
  @@ -23,12 +29,13 @@
         <p><span class="navheading">General:</span><br>
           <span class="navitem">News &amp; Status<br>
           Getting Involved<br>
  -        <a href="/mission">Mission &amp; Guidelines</a><br>
  +        <a href="/mission/index.html">Mission</a><br>
  +        <a href="/guidelines/index.html">Project Guidelines</a><br>
           Reference Library<br>
           Mailing Lists<br>
           FAQ-O-Matic<br>
           Quality</span></p>
  -      <p class="navheading"><span class="navheading">DevGroups:</span><br>
  +      <p class="navheading"><span class="navheading">SubProjects:</span><br>
           <span class="navitem">Tomcat<br>
           Josper<br>
           Documentation</span></p>
  @@ -38,7 +45,10 @@
         <span class="navheading">Credit:</span><br>
         <span class="navitem">Who We Are<br>
         Acknowledgements </span></td>
  -    <td> 
  +    <td>
  +
  +    <!-- Content body starts -->
  +    
   <h2>Contact Information</h2>
   <p>If you have questions or comments about this site, please send email to:</p>
   <blockquote>
  @@ -57,8 +67,11 @@
   <p>You can find more contact information for the Apache Software Foundation on 
     the <a href="http://www.apache.org/foundation/contact.html">contact page of 
     the main Apache site</a>.</p>
  +
  +
   
  - </td>
  +    <!-- Content body ends -->
  +    </td>
     </tr>
   </table>
   <br>
  
  
  
  1.2       +17 -4     jakarta-site/index.html
  
  Index: index.html
  ===================================================================
  RCS file: /home/cvs/jakarta-site/index.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- index.html	1999/09/01 19:07:15	1.1
  +++ index.html	1999/09/02 04:03:23	1.2
  @@ -1,9 +1,15 @@
   <html>
   <head>
  +<!-- $Id: index.html,v 1.2 1999/09/02 04:03:23 duncan Exp $ -->
  +<!-- Content head element begins -->
  +
   <title>The Jakarta Project</title>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   
   
  +
  +<!-- Content head element ends -->
  +
   <link rel="stylesheet" href="/style.css"></head>
   
   <body bgcolor="#FFFFFF">
  @@ -22,12 +28,13 @@
         <p><span class="navheading">General:</span><br>
           <span class="navitem">News &amp; Status<br>
           Getting Involved<br>
  -        <a href="/mission">Mission &amp; Guidelines</a><br>
  +        <a href="/mission/index.html">Mission</a><br>
  +        <a href="/guidelines/index.html">Project Guidelines</a><br>
           Reference Library<br>
           Mailing Lists<br>
           FAQ-O-Matic<br>
           Quality</span></p>
  -      <p class="navheading"><span class="navheading">DevGroups:</span><br>
  +      <p class="navheading"><span class="navheading">SubProjects:</span><br>
           <span class="navitem">Tomcat<br>
           Josper<br>
           Documentation</span></p>
  @@ -37,7 +44,10 @@
         <span class="navheading">Credit:</span><br>
         <span class="navitem">Who We Are<br>
         Acknowledgements </span></td>
  -    <td> <p>The Jakarta Project is an Apache working group dedicated to providing a high 
  +    <td>
  +
  +    <!-- Content body starts -->
  +    <p>The Jakarta Project is an Apache working group dedicated to providing a high 
     quality, world class 100% Pure Java Servlet and JavaServer Pages implementation. 
     This implementation will be used in the Apache Web Server (the most popular 
     web server on the Internet since April of 1996) as well as in other products 
  @@ -53,8 +63,11 @@
     source code with the Sun code. </p>
   <p>You are invited to participate in the formation of The Jakarta Project. Currently 
     the best way to get involved is to join the mailing lists. </p>
  +
  +
   
  - </td>
  +    <!-- Content body ends -->
  +    </td>
     </tr>
   </table>
   <br>
  
  
  
  1.2       +17 -4     jakarta-site/legal.html
  
  Index: legal.html
  ===================================================================
  RCS file: /home/cvs/jakarta-site/legal.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- legal.html	1999/09/01 19:07:15	1.1
  +++ legal.html	1999/09/02 04:03:23	1.2
  @@ -1,10 +1,16 @@
   <html>
   <head>
  +<!-- $Id: legal.html,v 1.2 1999/09/02 04:03:23 duncan Exp $ -->
  +<!-- Content head element begins -->
   
  +
   <title>Legal Stuff They Make Us Say</title>
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
   
   
  +
  +<!-- Content head element ends -->
  +
   <link rel="stylesheet" href="/style.css"></head>
   
   <body bgcolor="#FFFFFF">
  @@ -23,12 +29,13 @@
         <p><span class="navheading">General:</span><br>
           <span class="navitem">News &amp; Status<br>
           Getting Involved<br>
  -        <a href="/mission">Mission &amp; Guidelines</a><br>
  +        <a href="/mission/index.html">Mission</a><br>
  +        <a href="/guidelines/index.html">Project Guidelines</a><br>
           Reference Library<br>
           Mailing Lists<br>
           FAQ-O-Matic<br>
           Quality</span></p>
  -      <p class="navheading"><span class="navheading">DevGroups:</span><br>
  +      <p class="navheading"><span class="navheading">SubProjects:</span><br>
           <span class="navitem">Tomcat<br>
           Josper<br>
           Documentation</span></p>
  @@ -38,7 +45,10 @@
         <span class="navheading">Credit:</span><br>
         <span class="navitem">Who We Are<br>
         Acknowledgements </span></td>
  -    <td> 
  +    <td>
  +
  +    <!-- Content body starts -->
  +    
   <p>All material on this website is Copyright &copy;1999 The Apache Software Foundation, 
     All Rights Reserved. </p>
   <p>Sun, Sun Microsystems, Solaris, Java, JavaServer Web Development Kit, and JavaServer 
  @@ -49,8 +59,11 @@
   </p>
   <p>All other product names mentioned herein and throughout the entire web site 
     are trademarks of their respective owners. </p>
  +
  +
   
  - </td>
  +    <!-- Content body ends -->
  +    </td>
     </tr>
   </table>
   <br>
  
  
  
  1.2       +16 -3     jakarta-site/main.template
  
  Index: main.template
  ===================================================================
  RCS file: /home/cvs/jakarta-site/main.template,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- main.template	1999/09/01 19:07:17	1.1
  +++ main.template	1999/09/02 04:03:24	1.2
  @@ -1,6 +1,12 @@
   <html>
   <head>
  +<!-- $Id: main.template,v 1.2 1999/09/02 04:03:24 duncan Exp $ -->
  +<!-- Content head element begins -->
  +
   <!--%HEAD-->
  +
  +<!-- Content head element ends -->
  +
   <link rel="stylesheet" href="/style.css"></head>
   
   <body bgcolor="#FFFFFF">
  @@ -19,12 +25,13 @@
         <p><span class="navheading">General:</span><br>
           <span class="navitem">News &amp; Status<br>
           Getting Involved<br>
  -        <a href="/mission">Mission &amp; Guidelines</a><br>
  +        <a href="/mission/index.html">Mission</a><br>
  +        <a href="/guidelines/index.html">Project Guidelines</a><br>
           Reference Library<br>
           Mailing Lists<br>
           FAQ-O-Matic<br>
           Quality</span></p>
  -      <p class="navheading"><span class="navheading">DevGroups:</span><br>
  +      <p class="navheading"><span class="navheading">SubProjects:</span><br>
           <span class="navitem">Tomcat<br>
           Josper<br>
           Documentation</span></p>
  @@ -34,7 +41,13 @@
         <span class="navheading">Credit:</span><br>
         <span class="navitem">Who We Are<br>
         Acknowledgements </span></td>
  -    <td> <!--%BODY--> </td>
  +    <td>
  +
  +    <!-- Content body starts -->
  +    <!--%BODY-->
  +
  +    <!-- Content body ends -->
  +    </td>
     </tr>
   </table>
   <br>
  
  
  
  1.2       +73 -2     jakarta-site/style.css
  
  Index: style.css
  ===================================================================
  RCS file: /home/cvs/jakarta-site/style.css,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- style.css	1999/09/01 19:08:12	1.1
  +++ style.css	1999/09/02 04:03:24	1.2
  @@ -1,2 +1,73 @@
  -.navheading {  font-family: Arial, Helvetica, sans-serif; font-size: 12pt; font-style: normal; font-weight: bold; color: #0033CC}
  -.navitem {  font-family: "Times New Roman", Times, serif; font-size: 10pt; font-weight: normal; color: #000000}
  +h1 {
  +    font-family: Arial, Helvetica, sans-serif;
  +    font-size: 20pt;
  +    font-style: normal;
  +    font-weight: bold;
  +    color: #0033CC
  +}
  +
  +h2 {
  +    font-family: Arial, Helvetica, sans-serif;
  +    font-size: 16pt;
  +    font-style: normal;
  +    font-weight: bold;
  +    color: #0033CC
  +}
  +
  +h3 {
  +    font-family: Arial, Helvetica, sans-serif;
  +    font-size: 14pt;
  +    font-style: normal;
  +    font-weight: normal;
  +    color: #0033CC
  +}
  +
  +p {
  +    font-family: "Times New Roman", Times, serif;
  +    font-size: 12pt;
  +    font-weight: normal;
  +    color: #000000   
  +}
  +
  +b {
  +    font-weight: bold;
  +}
  +
  +li {
  +    font-family: "Times New Roman", Times, serif;
  +    font-size: 12pt;
  +    font-weight: normal;
  +    color: #000000  
  +}
  +
  +.code {
  +    font-family: Courier, mono;
  +    font-size: 11pt;
  +}
  +
  +.codeblock {
  +    font-family: Courier, mono;
  +    font-size: 11pt;
  +}
  +
  +.navheading {
  +    font-family: Arial, Helvetica, sans-serif;
  +    font-size: 12pt;
  +    font-style: normal;
  +    font-weight: bold;
  +    color: #0033CC
  +}
  +
  +.navitem {
  +    font-family: "Times New Roman", Times, serif;
  +    font-size: 10pt;
  +    font-weight: normal;
  +    color: #000000
  +}
  +
  +.itemdef {
  +    font-family: "Times New Roman", Times, serif;
  +    font-size: 10pt;
  +    font-weight: normal;
  +    color: #000000
  +}
  \ No newline at end of file
  
  
  
  1.1                  jakarta-site/guidelines/communication.html
  
  Index: communication.html
  ===================================================================
  <html>
  <head>
  <!-- $Id: communication.html,v 1.1 1999/09/02 04:03:26 duncan Exp $ -->
  <!-- Content head element begins -->
  
  
  <!-- $Id -->
  <title>Project Guidelines: Communication</title>
  
  
  
  <!-- Content head element ends -->
  
  <link rel="stylesheet" href="/style.css"></head>
  
  <body bgcolor="#FFFFFF">
  <table width="100%" border="0">
    <tr> 
      <td> 
        <p><a href="/index.html"><img src="/images/banner.gif" width="350" height="100" alt="The Jakarta Project" border="0"></a> 
        </p>
        <p>&nbsp; </p>
        </td>
    </tr>
  </table>
  <table width="100%" border="0" cellpadding="10" cellspacing="0">
    <tr valign="top"> 
      <td width="120" bgcolor="#CCCCCC"> 
        <p><span class="navheading">General:</span><br>
          <span class="navitem">News &amp; Status<br>
          Getting Involved<br>
          <a href="/mission/index.html">Mission</a><br>
          <a href="/guidelines/index.html">Project Guidelines</a><br>
          Reference Library<br>
          Mailing Lists<br>
          FAQ-O-Matic<br>
          Quality</span></p>
        <p class="navheading"><span class="navheading">SubProjects:</span><br>
          <span class="navitem">Tomcat<br>
          Josper<br>
          Documentation</span></p>
        <p><span class="navheading">Products:</span><br>
          <span class="navitem">Source Code<br>
          Binaries</span></p>
        <span class="navheading">Credit:</span><br>
        <span class="navitem">Who We Are<br>
        Acknowledgements </span></td>
      <td>
  
      <!-- Content body starts -->
      
  
    <h1>Communication</h1>
  
    <p>
    The Project obtains its strength from the communication of its
    members. In order for members to easily communicate with each other,
    the Project has a variety of mailing lists. These lists, with the
    exception of the announcement lists, are not moderated and anybody
    is more than welcome to join them. However, you must be subscribed
    to post to a list.
    </p>
  
    <p>
    To reduce the bandwidth demands on everyone, mail should not contain
    attachements. It is recommended that you place interesting material
    (such as patches) either inline to the body of the message or
    provide a URL for retrieval.
    </p>
  
    <p>
    The Project's list fall into the following catagories:
    </p>
  
    <h2>Announcement Lists</h2>
  
    <p>
    Announcement lists are very low traffic designed to communicate
    important information, such as releases of a version of a
    subproject's code, to a wide audience.
    </p>
  
    <h2>User Lists</h2>
  
    <p>
    User lists are for users of a product to converse about such things
    as configuration and operating of the products of the Project. 
    </p>
  
    <h2>Developer Lists</h2>
  
    <p>
    Developer lists are for the developers of the project. On these
    lists suggestions and comments for code changes are discussed and
    action items are raised and voted on. For the developer community,
    these lists are the very center of the project where all the
    &quot;action&quot; is.
    </p>
  
    <h2>Commit Lists</h2>
  
    <p>
    The commit lists are where all cvs code commit messages are
    sent. All committers are required to subscribe to this list so that
    they can stay aware of changes to the repository.
    </p>
    
  
  
  
      <!-- Content body ends -->
      </td>
    </tr>
  </table>
  <br>
  <table width="100%" border="0">
    <tr>
      <td><font size="-2">Copyright &copy;1999 The Apache Software Foundation<br>
        <a href="/legal.html">Legal Stuff They Make Us Say</a><br>
        <a href="/contact.html">Contact Information</a></font></td>
    </tr>
  </table>
  <p>&nbsp;</p>
  </body>
  </html>
  
  
  
  1.1                  jakarta-site/guidelines/communication.htsrc
  
  Index: communication.htsrc
  ===================================================================
  <html>
  <head>
  <!-- $Id -->
  <title>Project Guidelines: Communication</title>
  </head>
  <body>
  
    <h1>Communication</h1>
  
    <p>
    The Project obtains its strength from the communication of its
    members. In order for members to easily communicate with each other,
    the Project has a variety of mailing lists. These lists, with the
    exception of the announcement lists, are not moderated and anybody
    is more than welcome to join them. However, you must be subscribed
    to post to a list.
    </p>
  
    <p>
    To reduce the bandwidth demands on everyone, mail should not contain
    attachements. It is recommended that you place interesting material
    (such as patches) either inline to the body of the message or
    provide a URL for retrieval.
    </p>
  
    <p>
    The Project's list fall into the following catagories:
    </p>
  
    <h2>Announcement Lists</h2>
  
    <p>
    Announcement lists are very low traffic designed to communicate
    important information, such as releases of a version of a
    subproject's code, to a wide audience.
    </p>
  
    <h2>User Lists</h2>
  
    <p>
    User lists are for users of a product to converse about such things
    as configuration and operating of the products of the Project. 
    </p>
  
    <h2>Developer Lists</h2>
  
    <p>
    Developer lists are for the developers of the project. On these
    lists suggestions and comments for code changes are discussed and
    action items are raised and voted on. For the developer community,
    these lists are the very center of the project where all the
    &quot;action&quot; is.
    </p>
  
    <h2>Commit Lists</h2>
  
    <p>
    The commit lists are where all cvs code commit messages are
    sent. All committers are required to subscribe to this list so that
    they can stay aware of changes to the repository.
    </p>
    
  </body>
  </html>
  
  
  1.1                  jakarta-site/guidelines/decisions.html
  
  Index: decisions.html
  ===================================================================
  <html>
  <head>
  <!-- $Id: decisions.html,v 1.1 1999/09/02 04:03:26 duncan Exp $ -->
  <!-- Content head element begins -->
  
  
  <!-- $Id -->
  <title>Project Guidelines: Decision Making</title>
  
  
  
  <!-- Content head element ends -->
  
  <link rel="stylesheet" href="/style.css"></head>
  
  <body bgcolor="#FFFFFF">
  <table width="100%" border="0">
    <tr> 
      <td> 
        <p><a href="/index.html"><img src="/images/banner.gif" width="350" height="100" alt="The Jakarta Project" border="0"></a> 
        </p>
        <p>&nbsp; </p>
        </td>
    </tr>
  </table>
  <table width="100%" border="0" cellpadding="10" cellspacing="0">
    <tr valign="top"> 
      <td width="120" bgcolor="#CCCCCC"> 
        <p><span class="navheading">General:</span><br>
          <span class="navitem">News &amp; Status<br>
          Getting Involved<br>
          <a href="/mission/index.html">Mission</a><br>
          <a href="/guidelines/index.html">Project Guidelines</a><br>
          Reference Library<br>
          Mailing Lists<br>
          FAQ-O-Matic<br>
          Quality</span></p>
        <p class="navheading"><span class="navheading">SubProjects:</span><br>
          <span class="navitem">Tomcat<br>
          Josper<br>
          Documentation</span></p>
        <p><span class="navheading">Products:</span><br>
          <span class="navitem">Source Code<br>
          Binaries</span></p>
        <span class="navheading">Credit:</span><br>
        <span class="navitem">Who We Are<br>
        Acknowledgements </span></td>
      <td>
  
      <!-- Content body starts -->
      
  
    <h1>Decision Making</h1>
  
    <p>
    All Developers are encouraged to participate in decisions, but the
    decision itself is made by those that have Committer status in the
    Project. In other words, the Project is a &quot;<em>Minimum
    Threshold Meritocracy</em>&quot;.
    </p>
  
    <p>
    Any Developer may vote on any issue or action item. However, the
    only binding votes are those cast by a Committer. I fhte vote is
    about a change to the source code or documentation, the primary
    author of what is being changed may also cast a binding vote on that
    issue.
    </p>
  
    <p>
    The act of voting carries certain obligations. Voting members are
    not only stating their opinion, they are also agreeing to help do
    the work.
    </p>
  
    <p>Each vote can be made in one of three flavors:</p>
  
    <table border="0">
    
    <tr valign="top">
    <td width="50"><p><b>+1</b></p></td> <td>Yes, Agree, or the
    action should be performed. On some issues this is only binding if
    the voter has tested the action on their own system(s).</td>
    </tr>
  
    <tr valign="top">
    <td width="50"><p><b>+/-0</b></p></td> <td>Abstain, no
    opionion. An abstention may have detrimental effects if too many
    people abstain.</td>
    </tr>
  
    <tr valign="top">
    <td width="50"><p><b>-1</b></p></td> <td>No. On issues where
    consensus is required, this vote counts as a
    <b>veto</b>. All vetos must contain an explanation of why
    the veto is appropriate. Vetos with no explanation are void. No veto
    can be overruled. If you disagree with the veto, you should lobby
    the person who cast the veto. Voters intending to veto an action
    item should make their opinions known to the group immediately so
    that the problem can be remedied as early as possible.</td>
    </tr>
  
    </table>
    
    <p>
    An action requiring consensus approval must receive at least
    <b>3 binding +1</b> votes and <b>no binding
    vetos</b>. An action requiring majority approval must receive
    at least <b>3 binding +1</b> votes and more
    <b>+1</b> votes than <b>-1</b> votes. All other
    action items are considered to have lazy approval until somebody
    votes <b>-1</b>, after which point they are decided by
    either consensus or majority vote, depending on the type of action
    item.
    </p>
    
    <h2>Action Items</h2>
  
    <p>
    All decisions revolve around &quot;<em>Action
    Items</em>&quot;. Action Items consist of the following:
    </p>
  
    <ul>
    <li>Long Term Plans
    <li>Short Term Plans
    <li>Release Plan
    <li>Release Testing
    <li>Showstoppers
    <li>Product Changes
    </ul>
  
    <h3>Long Term Plans</h3>
  
    <p>
    Long term plans are simply announcements that group members are
    working on particular issues related to the Project. These are not
    voted on, but Developers who do not agree with a particular plan, or
    think that an alternative plan would be better, are obligated to
    inform the group of their feelings.
    </p>
  
    <h3>Short Term Plan</h3>
  
    <p>
    Short term plans are announcements that a developer is working on a
    particular set of documentation or code files with the implication
    that other developers should avoid them or try to coordinate their
    changes.
    </p>
  
    <p><b>What voteable issues are there here????</b></p>
  
    <h3>Release Plan</h3>
  
    <p>
    A release plan is used to keep all Developers aware of when a
    release is desired, who will be the release manager, when the
    repository will be frozen to create a release, an other assorted
    information to keep Developers from tripping over each other. Lazy
    majority decides each issue in a release plan.
    </p>
  
    <h3>Release Testing</h3>
  
    <p>
    After a new release is built, it must be tested before being
    released to the public. Majority approval is required before the
    release can be made.
    </p>
  
    <h3>Showstoppers</h3>
  
    <p>
    Showstoppers are issues that require a fix be in place before the
    next public release. They are listing in the status file in order to
    focus special attention on the problem. An issue becomes a
    showstopper when it is listed as such in the status file and remains
    so by lazy consensus.
    </p>
  
    <h3>Product Changes</h3>
  
    <p>
    Changes to the products of the Project, including code and
    documentation, will appar as action items in the status file. All
    product changes to the currently active repository are subject to
    lazy consensus.
    
  
  
  
      <!-- Content body ends -->
      </td>
    </tr>
  </table>
  <br>
  <table width="100%" border="0">
    <tr>
      <td><font size="-2">Copyright &copy;1999 The Apache Software Foundation<br>
        <a href="/legal.html">Legal Stuff They Make Us Say</a><br>
        <a href="/contact.html">Contact Information</a></font></td>
    </tr>
  </table>
  <p>&nbsp;</p>
  </body>
  </html>
  
  
  
  1.1                  jakarta-site/guidelines/decisions.htsrc
  
  Index: decisions.htsrc
  ===================================================================
  <html>
  <head>
  <!-- $Id -->
  <title>Project Guidelines: Decision Making</title>
  </head>
  <body>
  
    <h1>Decision Making</h1>
  
    <p>
    All Developers are encouraged to participate in decisions, but the
    decision itself is made by those that have Committer status in the
    Project. In other words, the Project is a &quot;<em>Minimum
    Threshold Meritocracy</em>&quot;.
    </p>
  
    <p>
    Any Developer may vote on any issue or action item. However, the
    only binding votes are those cast by a Committer. I fhte vote is
    about a change to the source code or documentation, the primary
    author of what is being changed may also cast a binding vote on that
    issue.
    </p>
  
    <p>
    The act of voting carries certain obligations. Voting members are
    not only stating their opinion, they are also agreeing to help do
    the work.
    </p>
  
    <p>Each vote can be made in one of three flavors:</p>
  
    <table border="0">
    
    <tr valign="top">
    <td width="50"><p><b>+1</b></p></td> <td>Yes, Agree, or the
    action should be performed. On some issues this is only binding if
    the voter has tested the action on their own system(s).</td>
    </tr>
  
    <tr valign="top">
    <td width="50"><p><b>+/-0</b></p></td> <td>Abstain, no
    opionion. An abstention may have detrimental effects if too many
    people abstain.</td>
    </tr>
  
    <tr valign="top">
    <td width="50"><p><b>-1</b></p></td> <td>No. On issues where
    consensus is required, this vote counts as a
    <b>veto</b>. All vetos must contain an explanation of why
    the veto is appropriate. Vetos with no explanation are void. No veto
    can be overruled. If you disagree with the veto, you should lobby
    the person who cast the veto. Voters intending to veto an action
    item should make their opinions known to the group immediately so
    that the problem can be remedied as early as possible.</td>
    </tr>
  
    </table>
    
    <p>
    An action requiring consensus approval must receive at least
    <b>3 binding +1</b> votes and <b>no binding
    vetos</b>. An action requiring majority approval must receive
    at least <b>3 binding +1</b> votes and more
    <b>+1</b> votes than <b>-1</b> votes. All other
    action items are considered to have lazy approval until somebody
    votes <b>-1</b>, after which point they are decided by
    either consensus or majority vote, depending on the type of action
    item.
    </p>
    
    <h2>Action Items</h2>
  
    <p>
    All decisions revolve around &quot;<em>Action
    Items</em>&quot;. Action Items consist of the following:
    </p>
  
    <ul>
    <li>Long Term Plans
    <li>Short Term Plans
    <li>Release Plan
    <li>Release Testing
    <li>Showstoppers
    <li>Product Changes
    </ul>
  
    <h3>Long Term Plans</h3>
  
    <p>
    Long term plans are simply announcements that group members are
    working on particular issues related to the Project. These are not
    voted on, but Developers who do not agree with a particular plan, or
    think that an alternative plan would be better, are obligated to
    inform the group of their feelings.
    </p>
  
    <h3>Short Term Plan</h3>
  
    <p>
    Short term plans are announcements that a developer is working on a
    particular set of documentation or code files with the implication
    that other developers should avoid them or try to coordinate their
    changes.
    </p>
  
    <p><b>What voteable issues are there here????</b></p>
  
    <h3>Release Plan</h3>
  
    <p>
    A release plan is used to keep all Developers aware of when a
    release is desired, who will be the release manager, when the
    repository will be frozen to create a release, an other assorted
    information to keep Developers from tripping over each other. Lazy
    majority decides each issue in a release plan.
    </p>
  
    <h3>Release Testing</h3>
  
    <p>
    After a new release is built, it must be tested before being
    released to the public. Majority approval is required before the
    release can be made.
    </p>
  
    <h3>Showstoppers</h3>
  
    <p>
    Showstoppers are issues that require a fix be in place before the
    next public release. They are listing in the status file in order to
    focus special attention on the problem. An issue becomes a
    showstopper when it is listed as such in the status file and remains
    so by lazy consensus.
    </p>
  
    <h3>Product Changes</h3>
  
    <p>
    Changes to the products of the Project, including code and
    documentation, will appar as action items in the status file. All
    product changes to the currently active repository are subject to
    lazy consensus.
    
  </body>
  </html>
  
  
  1.1                  jakarta-site/guidelines/index.html
  
  Index: index.html
  ===================================================================
  <html>
  <head>
  <!-- $Id: index.html,v 1.1 1999/09/02 04:03:27 duncan Exp $ -->
  <!-- Content head element begins -->
  
  
  <!-- $Id -->
  <title>Project Guidelines</title>
  
  
  
  <!-- Content head element ends -->
  
  <link rel="stylesheet" href="/style.css"></head>
  
  <body bgcolor="#FFFFFF">
  <table width="100%" border="0">
    <tr> 
      <td> 
        <p><a href="/index.html"><img src="/images/banner.gif" width="350" height="100" alt="The Jakarta Project" border="0"></a> 
        </p>
        <p>&nbsp; </p>
        </td>
    </tr>
  </table>
  <table width="100%" border="0" cellpadding="10" cellspacing="0">
    <tr valign="top"> 
      <td width="120" bgcolor="#CCCCCC"> 
        <p><span class="navheading">General:</span><br>
          <span class="navitem">News &amp; Status<br>
          Getting Involved<br>
          <a href="/mission/index.html">Mission</a><br>
          <a href="/guidelines/index.html">Project Guidelines</a><br>
          Reference Library<br>
          Mailing Lists<br>
          FAQ-O-Matic<br>
          Quality</span></p>
        <p class="navheading"><span class="navheading">SubProjects:</span><br>
          <span class="navitem">Tomcat<br>
          Josper<br>
          Documentation</span></p>
        <p><span class="navheading">Products:</span><br>
          <span class="navitem">Source Code<br>
          Binaries</span></p>
        <span class="navheading">Credit:</span><br>
        <span class="navitem">Who We Are<br>
        Acknowledgements </span></td>
      <td>
  
      <!-- Content body starts -->
      
  
    <h1>The Jakarta Project Guidelines</h1>
  
    <p>
    This document defines the guidelines of The Jakarta Project. It
    includes definitions of the various catagories of membership, who is
    able to vote, how conflict is resolved by voting, and the procedures
    to follow for proposing and making changes to the codebase of the
    Project.
    </p>
  
    <ul>
  
    <li><a href="roles.html">Roles and Responsibilities</a><br> <span
    class="itemdef">Defines the recognized roles in the project.</span>
    
    <li><a href="communication.html">Communication</a><br> <span
    class="itemdef">Defines how users and developers communicate.</span>
  
    <li><a href="decisions.html">Decision Making</a><br> <span
    class="itemdef">Defines how action items are proposed and voted
    on.</span>
  
    <li><a href="source.html">Source Repositories</a><br> <span
    class="itemdef">Defines how the Project's source code is organized
    and developed.</span>
  
    <li><a href="management.html">Project Management</a><br> <span
    class="itemdef">Defines the roles and responsibilities of the
    Project Management Committee.</span>
  
    </ul>
      
    <p>
    This is a living document. Changes can be made by the Project
    Management Committee. To propose a change to these guidelines, send
    mail to <a
    href="mailto:core@jakarta.apache.org">core@jakarta.apache.org</a>.
    </p>
  
  
  
  
  
      <!-- Content body ends -->
      </td>
    </tr>
  </table>
  <br>
  <table width="100%" border="0">
    <tr>
      <td><font size="-2">Copyright &copy;1999 The Apache Software Foundation<br>
        <a href="/legal.html">Legal Stuff They Make Us Say</a><br>
        <a href="/contact.html">Contact Information</a></font></td>
    </tr>
  </table>
  <p>&nbsp;</p>
  </body>
  </html>
  
  
  
  1.1                  jakarta-site/guidelines/index.htsrc
  
  Index: index.htsrc
  ===================================================================
  <html>
  <head>
  <!-- $Id -->
  <title>Project Guidelines</title>
  </head>
  <body>
  
    <h1>The Jakarta Project Guidelines</h1>
  
    <p>
    This document defines the guidelines of The Jakarta Project. It
    includes definitions of the various catagories of membership, who is
    able to vote, how conflict is resolved by voting, and the procedures
    to follow for proposing and making changes to the codebase of the
    Project.
    </p>
  
    <ul>
  
    <li><a href="roles.html">Roles and Responsibilities</a><br> <span
    class="itemdef">Defines the recognized roles in the project.</span>
    
    <li><a href="communication.html">Communication</a><br> <span
    class="itemdef">Defines how users and developers communicate.</span>
  
    <li><a href="decisions.html">Decision Making</a><br> <span
    class="itemdef">Defines how action items are proposed and voted
    on.</span>
  
    <li><a href="source.html">Source Repositories</a><br> <span
    class="itemdef">Defines how the Project's source code is organized
    and developed.</span>
  
    <li><a href="management.html">Project Management</a><br> <span
    class="itemdef">Defines the roles and responsibilities of the
    Project Management Committee.</span>
  
    </ul>
      
    <p>
    This is a living document. Changes can be made by the Project
    Management Committee. To propose a change to these guidelines, send
    mail to <a
    href="mailto:core@jakarta.apache.org">core@jakarta.apache.org</a>.
    </p>
  
  
  </body>
  </html>
  
  
  
  1.1                  jakarta-site/guidelines/management.html
  
  Index: management.html
  ===================================================================
  <html>
  <head>
  <!-- $Id: management.html,v 1.1 1999/09/02 04:03:27 duncan Exp $ -->
  <!-- Content head element begins -->
  
  
  <!-- $Id -->
  <title>Project Guidelines: Project Management Committee</title>
  
  
  
  <!-- Content head element ends -->
  
  <link rel="stylesheet" href="/style.css"></head>
  
  <body bgcolor="#FFFFFF">
  <table width="100%" border="0">
    <tr> 
      <td> 
        <p><a href="/index.html"><img src="/images/banner.gif" width="350" height="100" alt="The Jakarta Project" border="0"></a> 
        </p>
        <p>&nbsp; </p>
        </td>
    </tr>
  </table>
  <table width="100%" border="0" cellpadding="10" cellspacing="0">
    <tr valign="top"> 
      <td width="120" bgcolor="#CCCCCC"> 
        <p><span class="navheading">General:</span><br>
          <span class="navitem">News &amp; Status<br>
          Getting Involved<br>
          <a href="/mission/index.html">Mission</a><br>
          <a href="/guidelines/index.html">Project Guidelines</a><br>
          Reference Library<br>
          Mailing Lists<br>
          FAQ-O-Matic<br>
          Quality</span></p>
        <p class="navheading"><span class="navheading">SubProjects:</span><br>
          <span class="navitem">Tomcat<br>
          Josper<br>
          Documentation</span></p>
        <p><span class="navheading">Products:</span><br>
          <span class="navitem">Source Code<br>
          Binaries</span></p>
        <span class="navheading">Credit:</span><br>
        <span class="navitem">Who We Are<br>
        Acknowledgements </span></td>
      <td>
  
      <!-- Content body starts -->
      
  
    <h1>Project Mangement Committee</h1>
  
    <p>
    Coming soon....
    </p>
  
  
  
  
      <!-- Content body ends -->
      </td>
    </tr>
  </table>
  <br>
  <table width="100%" border="0">
    <tr>
      <td><font size="-2">Copyright &copy;1999 The Apache Software Foundation<br>
        <a href="/legal.html">Legal Stuff They Make Us Say</a><br>
        <a href="/contact.html">Contact Information</a></font></td>
    </tr>
  </table>
  <p>&nbsp;</p>
  </body>
  </html>
  
  
  
  1.1                  jakarta-site/guidelines/management.htsrc
  
  Index: management.htsrc
  ===================================================================
  <html>
  <head>
  <!-- $Id -->
  <title>Project Guidelines: Project Management Committee</title>
  </head>
  <body>
  
    <h1>Project Mangement Committee</h1>
  
    <p>
    Coming soon....
    </p>
  
  </body>
  </html>
  
  
  1.1                  jakarta-site/guidelines/roles.html
  
  Index: roles.html
  ===================================================================
  <html>
  <head>
  <!-- $Id: roles.html,v 1.1 1999/09/02 04:03:27 duncan Exp $ -->
  <!-- Content head element begins -->
  
  
  <!-- $Id -->
  <title>Project Guidelines: Roles and Responsibilities</title>
  
  
  
  <!-- Content head element ends -->
  
  <link rel="stylesheet" href="/style.css"></head>
  
  <body bgcolor="#FFFFFF">
  <table width="100%" border="0">
    <tr> 
      <td> 
        <p><a href="/index.html"><img src="/images/banner.gif" width="350" height="100" alt="The Jakarta Project" border="0"></a> 
        </p>
        <p>&nbsp; </p>
        </td>
    </tr>
  </table>
  <table width="100%" border="0" cellpadding="10" cellspacing="0">
    <tr valign="top"> 
      <td width="120" bgcolor="#CCCCCC"> 
        <p><span class="navheading">General:</span><br>
          <span class="navitem">News &amp; Status<br>
          Getting Involved<br>
          <a href="/mission/index.html">Mission</a><br>
          <a href="/guidelines/index.html">Project Guidelines</a><br>
          Reference Library<br>
          Mailing Lists<br>
          FAQ-O-Matic<br>
          Quality</span></p>
        <p class="navheading"><span class="navheading">SubProjects:</span><br>
          <span class="navitem">Tomcat<br>
          Josper<br>
          Documentation</span></p>
        <p><span class="navheading">Products:</span><br>
          <span class="navitem">Source Code<br>
          Binaries</span></p>
        <span class="navheading">Credit:</span><br>
        <span class="navitem">Who We Are<br>
        Acknowledgements </span></td>
      <td>
  
      <!-- Content body starts -->
      
  
    <h1>Roles &amp; Responsibilities</h1>
  
    <p>
    The roles, and the responsibilities associated with each role, that
    people can assume in the project are based on merit. Everybody can
    help no matter what their role. Those who have been long term or
    valuable contributors to the project obtain the right to vote and
    commit directly to the source repository.
    </p>
  
    <p>
    The following sections define the various roles and the
    responsibilities of each role.
    </p>
  
    <h2>Users</h2>
  
    <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 developer.
    </p>
    
    <h2>Developers</h2>
  
    <p>
    Developers are the people who write code or documentation patches or
    contribute positively to the project in other ways. A developer's
    contribution is always recognized. In source code, all developers
    who contribute to a source file may add their name to the list of
    authors for that file.
    </p>
  
    <h2>Committer</h2>
  
    <p>
    Developers 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 gain voting
    rights allowing them to affect the future of the subproject.
    </p>
  
    <p>
    In order for a Developer to become a Committer, another Committer
    can nominate that Developer or the Developer can ask for it. Once a
    Developer is nominated, all of the Committers for a subproject will
    vote. If there are no negative votes, the Developer is converted
    into a Committer and given write access to the source code
    repository for that subproject.
    </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 his
    or her status as a committer.
    </p>
      
  
  
  
      <!-- Content body ends -->
      </td>
    </tr>
  </table>
  <br>
  <table width="100%" border="0">
    <tr>
      <td><font size="-2">Copyright &copy;1999 The Apache Software Foundation<br>
        <a href="/legal.html">Legal Stuff They Make Us Say</a><br>
        <a href="/contact.html">Contact Information</a></font></td>
    </tr>
  </table>
  <p>&nbsp;</p>
  </body>
  </html>
  
  
  
  1.1                  jakarta-site/guidelines/roles.htsrc
  
  Index: roles.htsrc
  ===================================================================
  <html>
  <head>
  <!-- $Id -->
  <title>Project Guidelines: Roles and Responsibilities</title>
  </head>
  <body>
  
    <h1>Roles &amp; Responsibilities</h1>
  
    <p>
    The roles, and the responsibilities associated with each role, that
    people can assume in the project are based on merit. Everybody can
    help no matter what their role. Those who have been long term or
    valuable contributors to the project obtain the right to vote and
    commit directly to the source repository.
    </p>
  
    <p>
    The following sections define the various roles and the
    responsibilities of each role.
    </p>
  
    <h2>Users</h2>
  
    <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 developer.
    </p>
    
    <h2>Developers</h2>
  
    <p>
    Developers are the people who write code or documentation patches or
    contribute positively to the project in other ways. A developer's
    contribution is always recognized. In source code, all developers
    who contribute to a source file may add their name to the list of
    authors for that file.
    </p>
  
    <h2>Committer</h2>
  
    <p>
    Developers 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 gain voting
    rights allowing them to affect the future of the subproject.
    </p>
  
    <p>
    In order for a Developer to become a Committer, another Committer
    can nominate that Developer or the Developer can ask for it. Once a
    Developer is nominated, all of the Committers for a subproject will
    vote. If there are no negative votes, the Developer is converted
    into a Committer and given write access to the source code
    repository for that subproject.
    </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 his
    or her status as a committer.
    </p>
      
  </body>
  </html>
  
  
  1.1                  jakarta-site/guidelines/source.html
  
  Index: source.html
  ===================================================================
  <html>
  <head>
  <!-- $Id: source.html,v 1.1 1999/09/02 04:03:28 duncan Exp $ -->
  <!-- Content head element begins -->
  
  
  <!-- $Id -->
  <title>Project Guidelines: Source Code</title>
  
  
  
  <!-- Content head element ends -->
  
  <link rel="stylesheet" href="/style.css"></head>
  
  <body bgcolor="#FFFFFF">
  <table width="100%" border="0">
    <tr> 
      <td> 
        <p><a href="/index.html"><img src="/images/banner.gif" width="350" height="100" alt="The Jakarta Project" border="0"></a> 
        </p>
        <p>&nbsp; </p>
        </td>
    </tr>
  </table>
  <table width="100%" border="0" cellpadding="10" cellspacing="0">
    <tr valign="top"> 
      <td width="120" bgcolor="#CCCCCC"> 
        <p><span class="navheading">General:</span><br>
          <span class="navitem">News &amp; Status<br>
          Getting Involved<br>
          <a href="/mission/index.html">Mission</a><br>
          <a href="/guidelines/index.html">Project Guidelines</a><br>
          Reference Library<br>
          Mailing Lists<br>
          FAQ-O-Matic<br>
          Quality</span></p>
        <p class="navheading"><span class="navheading">SubProjects:</span><br>
          <span class="navitem">Tomcat<br>
          Josper<br>
          Documentation</span></p>
        <p><span class="navheading">Products:</span><br>
          <span class="navitem">Source Code<br>
          Binaries</span></p>
        <span class="navheading">Credit:</span><br>
        <span class="navitem">Who We Are<br>
        Acknowledgements </span></td>
      <td>
  
      <!-- Content body starts -->
      
  
    <h1>Source Repositories</h1>
  
    <p>
    The Project's codebase is maintained in shared information
    repositories using CVS on the dev.apache.org machine. Only
    Committers have write access to these repositories. Everyone has
    read access via anonymous CVS.
    </p>
  
    <p>
    All Java Language source code in the repository must be written in
    conformance to the &quot;<a
    href="http://java.sun.com/docs/codeconv/">Code Conventions for the
    Java Programming Language</a> as published by Sun at
    http://java.sun.com/.
    </p>
  
    <h2>License</h2>
  
    <p>
    All source code committed to the Project's repositories must be
    covered by the Apache License or contain a copyright and license
    that allows redistribution under the same conditions as the Apache
    License.
    </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 hte 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>
    The active status files are automatically posted to the developer
    mailing lists three times per week.
    </p>
  
    <h2>Branches</h2>
  
    <p>
    Two branches, CURRENT and STABLE???
    </p>
  
    <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.
    </p>
  
    <h2>Changes</h2>
  
    <p>
    Simple patches to fix bugs can be committed then reviewed. With a
    commit-then-review process, the Developer 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.
    </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 aviod 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 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). For example:
    </p>
  
    <p class="codeblock">
    diff -u Main.java.orig Main.java >> patchfile.txt
    </p>
  
    <p>or</p>
  
    <p class="codeblock">
    cvs diff -u Main.java >> patchfile.txt
    </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 shoudl be posted
    and not just the difference between the two patches.
    </p>
    
  
  
  
      <!-- Content body ends -->
      </td>
    </tr>
  </table>
  <br>
  <table width="100%" border="0">
    <tr>
      <td><font size="-2">Copyright &copy;1999 The Apache Software Foundation<br>
        <a href="/legal.html">Legal Stuff They Make Us Say</a><br>
        <a href="/contact.html">Contact Information</a></font></td>
    </tr>
  </table>
  <p>&nbsp;</p>
  </body>
  </html>
  
  
  
  1.1                  jakarta-site/guidelines/source.htsrc
  
  Index: source.htsrc
  ===================================================================
  <html>
  <head>
  <!-- $Id -->
  <title>Project Guidelines: Source Code</title>
  </head>
  <body>
  
    <h1>Source Repositories</h1>
  
    <p>
    The Project's codebase is maintained in shared information
    repositories using CVS on the dev.apache.org machine. Only
    Committers have write access to these repositories. Everyone has
    read access via anonymous CVS.
    </p>
  
    <p>
    All Java Language source code in the repository must be written in
    conformance to the &quot;<a
    href="http://java.sun.com/docs/codeconv/">Code Conventions for the
    Java Programming Language</a> as published by Sun at
    http://java.sun.com/.
    </p>
  
    <h2>License</h2>
  
    <p>
    All source code committed to the Project's repositories must be
    covered by the Apache License or contain a copyright and license
    that allows redistribution under the same conditions as the Apache
    License.
    </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 hte 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>
    The active status files are automatically posted to the developer
    mailing lists three times per week.
    </p>
  
    <h2>Branches</h2>
  
    <p>
    Two branches, CURRENT and STABLE???
    </p>
  
    <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.
    </p>
  
    <h2>Changes</h2>
  
    <p>
    Simple patches to fix bugs can be committed then reviewed. With a
    commit-then-review process, the Developer 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.
    </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 aviod 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 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). For example:
    </p>
  
    <p class="codeblock">
    diff -u Main.java.orig Main.java >> patchfile.txt
    </p>
  
    <p>or</p>
  
    <p class="codeblock">
    cvs diff -u Main.java >> patchfile.txt
    </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 shoudl be posted
    and not just the difference between the two patches.
    </p>
    
  </body>
  </html>
  
  
  1.2       +22 -13    jakarta-site/mission/index.html
  
  Index: index.html
  ===================================================================
  RCS file: /home/cvs/jakarta-site/mission/index.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- index.html	1999/09/02 00:14:30	1.1
  +++ index.html	1999/09/02 04:03:29	1.2
  @@ -1,9 +1,15 @@
   <html>
   <head>
  +<!-- $Id: index.html,v 1.2 1999/09/02 04:03:29 duncan Exp $ -->
  +<!-- Content head element begins -->
   
  +
   <title>The Jakarta Project Mission & Guidelines</title>
   
   
  +
  +<!-- Content head element ends -->
  +
   <link rel="stylesheet" href="/style.css"></head>
   
   <body bgcolor="#FFFFFF">
  @@ -22,12 +28,13 @@
         <p><span class="navheading">General:</span><br>
           <span class="navitem">News &amp; Status<br>
           Getting Involved<br>
  -        <a href="/mission/index.html">Mission &amp; Guidelines</a><br>
  +        <a href="/mission/index.html">Mission</a><br>
  +        <a href="/guidelines/index.html">Project Guidelines</a><br>
           Reference Library<br>
           Mailing Lists<br>
           FAQ-O-Matic<br>
           Quality</span></p>
  -      <p class="navheading"><span class="navheading">DevGroups:</span><br>
  +      <p class="navheading"><span class="navheading">SubProjects:</span><br>
           <span class="navitem">Tomcat<br>
           Josper<br>
           Documentation</span></p>
  @@ -37,16 +44,21 @@
         <span class="navheading">Credit:</span><br>
         <span class="navitem">Who We Are<br>
         Acknowledgements </span></td>
  -    <td> 
  +    <td>
  +
  +    <!-- Content body starts -->
  +    
   
   <h1>The Jakarta Project Mission</h1>
   
   <p>
  -The mission of the Project is simple: Provide commercial quality based
  -implementations of the Java Servlet and JavaServer Pages
  -specifications. These implementations will be delivered standalone and
  -integrated with the Apache Web Server.
  -</p>
  +The mission of the Project is simple: Provide commercial quality Java
  +Platform based server solutions that are developed in an open and
  +cooperative fashion. The flagship product of the Project is an
  +implementation of the Java Server and JavaServer Pages specifications
  +which can be run standalone as well as integrated with the Apache Web
  +Server.
  +<p>
   
   <p>
   All final releases of the Servlet and JSP implementations will conform
  @@ -56,14 +68,11 @@
   Process.
   </p>
   
  -<h1>Project Guidelines</h1>
   
  -<p>
  -
  -</p>
   
   
  - </td>
  +    <!-- Content body ends -->
  +    </td>
     </tr>
   </table>
   <br>
  
  
  

Mime
View raw message