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 guidelines.html guidelines.htsrc
Date Wed, 01 Sep 1999 19:07:36 GMT
duncan      99/09/01 12:07:34

  Added:       .        README STATUS contact.html contact.htsrc index.html
                        index.htsrc legal.html legal.htsrc main.template
                        tac.jar
               images   banner.gif banner.psd mailto-webmaster-over.gif
                        mailto-webmaster.gif menuitems.psd
                        sidebar-blank.gif sidebar-contributing-over.gif
                        sidebar-contributing.gif sidebar-credits-over.gif
                        sidebar-credits.gif sidebar-documentation-over.gif
                        sidebar-documentation.gif
                        sidebar-mailinglists-over.gif
                        sidebar-mailinglists.gif sidebar-news-over.gif
                        sidebar-news.gif sidebar-whoweare-over.gif
                        sidebar-whoweare.gif
               mission  guidelines.html guidelines.htsrc
  Log:
  Re-checkin of jakarta site. The previous set of site docs were corrupted
  (no -kb option on the binaries). This checkin also reflects a restructure
  of the site for going live with code. There's still a lot to do.
  
  Revision  Changes    Path
  1.1                  jakarta-site/README
  
  Index: README
  ===================================================================
  README: jakarta-site
  	$Id: README,v 1.1 1999/09/01 19:07:14 duncan Exp $
  
  WHAT IS IT?
  
  	This repository contains the website of The Jakarta Project.
  
  HOW DO I EDIT THE SITE?
  
  	First off, *DON'T* just go and edit the .html files
  	willy-nilly. Time and effort has been placed into making sure
  	that we have a consistent look and feel along with the ability
  	to change it quite quickly.
  
  	To edit the content for any particular page, edit the .htsrc
  	file. For example, to edit the content that you see as
  	index.html on the website, edit the index.htsrc file.
  
  	To edit the overal template for the site, edit the
  	main.template file. Note that you can provide content that
  	isn't templated just by creating a .html file where that
  	content is supposed to be.
  
  	So, in order to generate the content, just run:
  
  	    java -jar tac.jar 
  	
  	Run this command in this directory (the same one that contains
  	this README file) and it will ensure that the site is
  	generated and up to date. Cool, 'eh?
  
  	If you make a change in an .html file when you really should
  	have made it in a .htsrc file, you will be flamed and your
  	change backed out. You have been notified.. :)
  
  
  
  
  
  1.1                  jakarta-site/STATUS
  
  Index: STATUS
  ===================================================================
  STATUS: jakarta-site
  	$Id: STATUS,v 1.1 1999/09/01 19:07:14 duncan Exp $
  
  NEXT RELEASE:
  
  	Planned site overhaul 8/31 
  
  OPEN ISSUES:
  
  	Need approval on Guidelines.
  
  	Need comments on Contact Info.
  
  	Need to set up jakarta@jakarta.apache.org alias to send mail
  	to core@jakarta.apache.org and give an autoresponse back to
  	the sender.
  
  	Need to set up webmaster@jakarta.apache.org alias to send mail
  	to duncan and others interested in seeing it.
  
  
  
  
  1.1                  jakarta-site/contact.html
  
  Index: contact.html
  ===================================================================
  <html>
  <head>
  
  <title>Contact Information</title>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  
  
  <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">Mission &amp; 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>
          <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> 
  <h2>Contact Information</h2>
  <p>If you have questions or comments about this site, please send email to:</p>
  <blockquote>
    <p><a href="mailto:webmaster@jakarta.apache.org">webmaster@jakarta.apache.org</a></p>
  </blockquote>
  <p>The easiest way to contact The Jakarta Project is via email. The address for 
    the Project Management Committee in charge of the Project is:</p>
  <blockquote>
    <p><a href="mailto:jakarta@jakarta.apache.org">jakarta@jakarta.apache.org</a></p>
  </blockquote>
  <p>The Jakarta Project is an effort of the Apache Software Foundation. The address 
    for general ASF correspondence and licensing questions is:</p>
  <blockquote> 
    <p><a href="mailto:apache@apache.org">apache@apache.org</a></p>
  </blockquote>
  <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>
    </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/contact.htsrc
  
  Index: contact.htsrc
  ===================================================================
  <html>
  <head>
  <title>Contact Information</title>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  </head>
  
  <body bgcolor="#FFFFFF">
  <h2>Contact Information</h2>
  <p>If you have questions or comments about this site, please send email to:</p>
  <blockquote>
    <p><a href="mailto:webmaster@jakarta.apache.org">webmaster@jakarta.apache.org</a></p>
  </blockquote>
  <p>The easiest way to contact The Jakarta Project is via email. The address for 
    the Project Management Committee in charge of the Project is:</p>
  <blockquote>
    <p><a href="mailto:jakarta@jakarta.apache.org">jakarta@jakarta.apache.org</a></p>
  </blockquote>
  <p>The Jakarta Project is an effort of the Apache Software Foundation. The address 
    for general ASF correspondence and licensing questions is:</p>
  <blockquote> 
    <p><a href="mailto:apache@apache.org">apache@apache.org</a></p>
  </blockquote>
  <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>
  </body>
  </html>
  
  
  
  1.1                  jakarta-site/index.html
  
  Index: index.html
  ===================================================================
  <html>
  <head>
  <title>The Jakarta Project</title>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  
  
  <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">Mission &amp; 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>
          <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> <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 
    including other web servers and development tools. </p>
  <p>The Jakarta Project is composed by members of the current Apache Jserv Project 
    and engineers from Sun, IBM, and other major corporations. All interested developers 
    are welcomed to join and participate. </p>
  <p>This project is currently in its formative stages. Source code for the JavaServer 
    Web Development Kit (which is Sun's reference implementation for the Servlet 
    and the Java Server Pages Specifications) will be delivered to this project 
    in the near future after the appropriate legal issues have been taken care of. 
    At that time, effort will start on merging the current Apache Jserv Project's 
    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>
    </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/index.htsrc
  
  Index: index.htsrc
  ===================================================================
  <html>
  <head><title>The Jakarta Project</title>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  </head>
  
  <body bgcolor="#FFFFFF"><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 
    including other web servers and development tools. </p>
  <p>The Jakarta Project is composed by members of the current Apache Jserv Project 
    and engineers from Sun, IBM, and other major corporations. All interested developers 
    are welcomed to join and participate. </p>
  <p>This project is currently in its formative stages. Source code for the JavaServer 
    Web Development Kit (which is Sun's reference implementation for the Servlet 
    and the Java Server Pages Specifications) will be delivered to this project 
    in the near future after the appropriate legal issues have been taken care of. 
    At that time, effort will start on merging the current Apache Jserv Project's 
    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>
  </body>
  </html>
  
  
  
  1.1                  jakarta-site/legal.html
  
  Index: legal.html
  ===================================================================
  <html>
  <head>
  
  <title>Legal Stuff They Make Us Say</title>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  
  
  <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">Mission &amp; 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>
          <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> 
  <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 
    Pages are trademarks or registered trademarks of Sun Microsystems, Inc. </p>
  <p>UNIX is a registered trademark in the United States and other countries, exclusively 
    licensed through X/Open Company, Ltd. </p>
  <p>Windows, WindowsNT, and WIn32 are registered trademarks of Microsoft Corp. 
  </p>
  <p>All other product names mentioned herein and throughout the entire web site 
    are trademarks of their respective owners. </p>
  
   </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/legal.htsrc
  
  Index: legal.htsrc
  ===================================================================
  <html>
  <head>
  <title>Legal Stuff They Make Us Say</title>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  </head>
  
  <body bgcolor="#FFFFFF">
  <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 
    Pages are trademarks or registered trademarks of Sun Microsystems, Inc. </p>
  <p>UNIX is a registered trademark in the United States and other countries, exclusively 
    licensed through X/Open Company, Ltd. </p>
  <p>Windows, WindowsNT, and WIn32 are registered trademarks of Microsoft Corp. 
  </p>
  <p>All other product names mentioned herein and throughout the entire web site 
    are trademarks of their respective owners. </p>
  </body>
  </html>
  
  
  
  1.1                  jakarta-site/main.template
  
  Index: main.template
  ===================================================================
  <html>
  <head>
  <!--%HEAD-->
  <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">Mission &amp; 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>
          <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> <!--%BODY--> </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/tac.jar
  
  	<<Binary file>>
  
  
  1.1                  jakarta-site/images/banner.gif
  
  	<<Binary file>>
  
  
  1.1                  jakarta-site/images/banner.psd
  
  	<<Binary file>>
  
  
  1.1                  jakarta-site/images/mailto-webmaster-over.gif
  
  	<<Binary file>>
  
  
  1.1                  jakarta-site/images/mailto-webmaster.gif
  
  	<<Binary file>>
  
  
  1.1                  jakarta-site/images/menuitems.psd
  
  	<<Binary file>>
  
  
  1.1                  jakarta-site/images/sidebar-blank.gif
  
  	<<Binary file>>
  
  
  1.1                  jakarta-site/images/sidebar-contributing-over.gif
  
  	<<Binary file>>
  
  
  1.1                  jakarta-site/images/sidebar-contributing.gif
  
  	<<Binary file>>
  
  
  1.1                  jakarta-site/images/sidebar-credits-over.gif
  
  	<<Binary file>>
  
  
  1.1                  jakarta-site/images/sidebar-credits.gif
  
  	<<Binary file>>
  
  
  1.1                  jakarta-site/images/sidebar-documentation-over.gif
  
  	<<Binary file>>
  
  
  1.1                  jakarta-site/images/sidebar-documentation.gif
  
  	<<Binary file>>
  
  
  1.1                  jakarta-site/images/sidebar-mailinglists-over.gif
  
  	<<Binary file>>
  
  
  1.1                  jakarta-site/images/sidebar-mailinglists.gif
  
  	<<Binary file>>
  
  
  1.1                  jakarta-site/images/sidebar-news-over.gif
  
  	<<Binary file>>
  
  
  1.1                  jakarta-site/images/sidebar-news.gif
  
  	<<Binary file>>
  
  
  1.1                  jakarta-site/images/sidebar-whoweare-over.gif
  
  	<<Binary file>>
  
  
  1.1                  jakarta-site/images/sidebar-whoweare.gif
  
  	<<Binary file>>
  
  
  1.1                  jakarta-site/mission/guidelines.html
  
  Index: guidelines.html
  ===================================================================
  <html>
  <head>
  
  <title>Untitled Document</title>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  
  
  <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">Mission &amp; 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>
          <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> 
  <h1>The Jakarta Project Guidelines</h1>
  <p><i><font color="#FF0000">// guidelines may be too soft a word.</font></i></p>
  <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>
  <h2>Developers</h2>
  <p>All volunteers who contribute time, code, documentation, or resources are considered 
    to be Developers. A developer that makes sustained, welcome contributions to 
    the Project is usually invited to join the group of Committers. The exact timing 
    of such invitation depends on many factors.</p>
  <p>Developers who want to convert their membership to that of a committer need 
    to ask for it on the mailing list and, if approved, need to ask the sysadmin 
    of dev.apache.org for a user account.</p>
  <h3>Developer Mailing Lists</h3>
  <p>general@jakarta.apache.org<br>
    tomcat-dev@jakarta.apache.org<br>
    josper-dev@jakarta.apache.org </p>
  <p>Subscription to these lists is open, but only subscribers can post directly 
    to the list.</p>
  <h2>Committers</h2>
  <p>A Committer is a volunteer who is given write access to the source codebase 
    of the Project.</p>
  <h2>The Project Management Committee</h2>
  <p>The Project Management Committee <font color="#FF0000"><i>(// established by 
    the ASF)</i></font> is a group of volunteers who are responsible for managing 
    the Project. This includes deciding what is distributed as products of the Project, 
    maintaning the Project's shared resources, speaking on behalf of the Project, 
    and establishing these guidelines.</p>
  <p>Membership in the Committee is by invitation only and must be approved by consensus 
    of the active Committee members. </p>
  <p>Membership termination.</p>
  <h3>Private List</h3>
  <p>core@jakarta.apache.org</p>
  <p>The Committee maintains a private mailing list for discussion of issues that 
    are inappropriate for public discussion, such as legal or personal issues. </p>
  <h2>Source Code</h2>
  <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><i><font color="#FF0000">// security implications of write access</font></i></p>
  <h3>Status</h3>
  <p>Each of the Project's active source code repositories contain a file called 
    &quot;STATUS&quot; 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 might be useful 
    to help the group track progress. The active STATUS files are automatically 
    posted to the mailing list three times each week. </p>
  <p>Many issues will be encountered by the project, each resulting in zero or more 
    proposed action items. Issues should be raised on the mailing list as soon as 
    they are identified. Action items must be raised on the mailing list and added 
    to the relevant STATUS file. All action items may be voted on, but not all of 
    them will require a formal vote. </p>
  <h2>Voting</h2>
  <p>All Developers are encouraged to participate in decisions, but the decision 
    itself is made by those that have been long-time contributors to the project. 
    These contributors are known as Committers. In other words, the Project is a 
    minimum-threshold meritocracy.</p>
  <p>Any Developer may vote on any issue or action item. However, the only binding 
    votes are those cast by a Committer. If the 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>As all contributors to the Project are volunteers, members often become inactive 
    for periods of time in order to take care of their &quot;real jobs&quot; or 
    devote more time to other projects. it is therefore unlikely that the entire 
    group membership will vote on every issue. To account for this, all voting decisions 
    are based on a minimum quorum.</p>
  <p>Each vote can be made in one of three flavors:</p>
  <table width="100%" border="0">
    <tr valign="top"> 
      <td width="9%"><b>+1</b></td>
      <td width="91%">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="9%"><b>0</b></td>
      <td width="91%">Abstain, no opinion, or I am happy to let the other group 
        members decide this issue. An abstention may have deterimental effects if 
        too many people abstain. </td>
    </tr>
    <tr valign="top"> 
      <td width="9%"><b>-1</b></td>
      <td width="91%">No. On issues where consensus is required, this vote counts 
        as a <b>veto</b>. All vetos must include an explanation of why the veto 
        is appropriate. A veto with no explanation is 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 probelm 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 item requiring majority approval 
    must receive at least <b>3 binding +1</b> votes and more <b>+1</b> votes than 
    <b>-1</b> votes (i.e. a majority with a minimum quorum of three positive 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>Action Items are....</p>
  <dl> 
    <dt>Long Term Plans</dt>
    <dd>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 alternate plan would 
      be better, are obligated to inform the group of their feelings. In general, 
      it is always better to hear about alternate plans prior to spending time on 
      less adequate solutions.</dd>
    <dt>Short Term Plans</dt>
    <dd>Short term plans are announcements that a developer is working on a particular 
      set of documentation of code files, with the implication that other developers 
      should avoid them or try to coordinate their changes. This is a good way to 
      proactively avoid conflict and possible duplication of work.</dd>
    <dt>Release Plan</dt>
    <dd>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, and other assorted information to keep Develoeprs from 
      tripping over each other during the final moments of shipping code. Lazy majority 
      decides each issue in a release plan.</dd>
    <dt>Release Testing</dt>
    <dd>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.</dd>
    <dt>Showstoppers</dt>
    <dd>Showstoppers are issues that require a fix be in place before the next public 
      release. They are listed 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.</dd>
    <dt>Product Changes</dt>
    <dd>Changes to the products of the Project, including code and documentation, 
      will apear as action items in the STATUS file. All product chagnes to the 
      currently active repository are subject to lazy consensus. </dd>
  </dl>
  <h2>Changes</h2>
  <p>Simple patchs 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 commiting them into the repository. Any change that affects the semantics 
    of an existing API function, the size of the progrem, configuration data formats, 
    or other major areas must receive consensus approval on the appropriate development 
    mailing list before being committed.</p>
  <h3>Proposing a Major Change</h3>
  <p>A Developer is responsible for notifying the appropriate development mailing 
    list and adding an action item to the STATUS file when they have an idea for 
    a new feature or a major change to propose for the product. The distributed 
    nature of the Project requires an advance notice of 48 hours in order to properly 
    review a major change. Consensus approval of either the concept or a specific 
    patch is required before the change can be committed.</p>
  <h3>Commiting Changes</h3>
  <p>Related changes should be committed as a group, or very closely together. Half 
    completed 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 product 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, particularly 
    when completing the change requires access to a special development tool on 
    that other platform. If it is anticipated that a given change will break some 
    other platform, the committer must indicate that in the commit log. </p>
  <p>The committer is responsible for the quality of any third-party code or documentation 
    they commit to the repository. All software committed to the repository 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>
  <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 "bug fix" 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 [PATCH] and a distinctive one-line summary 
    corresponding to the action item for that patch.</p>
  <p>The patch should be created by using the diff -u command from the original 
    software file(s) to the modified software file(s). For example:</p>
  <blockquote>
    <p><font face="Courier New, Courier, mono" size="-1">diff -u Main.java.orig 
      Main.java &gt;&gt; patchfile.txt</font></p>
  </blockquote>
  <p>or</p>
  <blockquote>
    <p><font face="Courier New, Courier, mono" size="-1">diff -u Main.java &gt;&gt; 
      patchfile.txt</font></p>
  </blockquote>
  <p>All patches necessary to address an action item should be concatenated 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>The complete patchfile should produce no errors or prompts when the command:</p>
  <blockquote>
    <p><font face="Courier New, Courier, mono" size="-1">patch -s &lt; patchfile</font></p>
  </blockquote>
  <p>is issued in the target repository.</p>
  <p>&nbsp;</p>
  <dl>
    <dt>&nbsp; </dt>
  </dl>
  <p>&nbsp;</p>
  <p>&nbsp;</p>
  
   </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/mission/guidelines.htsrc
  
  Index: guidelines.htsrc
  ===================================================================
  <html>
  <head>
  <title>Untitled Document</title>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  </head>
  
  <body bgcolor="#FFFFFF">
  <h1>The Jakarta Project Guidelines</h1>
  <p><i><font color="#FF0000">// guidelines may be too soft a word.</font></i></p>
  <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>
  <h2>Developers</h2>
  <p>All volunteers who contribute time, code, documentation, or resources are considered 
    to be Developers. A developer that makes sustained, welcome contributions to 
    the Project is usually invited to join the group of Committers. The exact timing 
    of such invitation depends on many factors.</p>
  <p>Developers who want to convert their membership to that of a committer need 
    to ask for it on the mailing list and, if approved, need to ask the sysadmin 
    of dev.apache.org for a user account.</p>
  <h3>Developer Mailing Lists</h3>
  <p>general@jakarta.apache.org<br>
    tomcat-dev@jakarta.apache.org<br>
    josper-dev@jakarta.apache.org </p>
  <p>Subscription to these lists is open, but only subscribers can post directly 
    to the list.</p>
  <h2>Committers</h2>
  <p>A Committer is a volunteer who is given write access to the source codebase 
    of the Project.</p>
  <h2>The Project Management Committee</h2>
  <p>The Project Management Committee <font color="#FF0000"><i>(// established by 
    the ASF)</i></font> is a group of volunteers who are responsible for managing 
    the Project. This includes deciding what is distributed as products of the Project, 
    maintaning the Project's shared resources, speaking on behalf of the Project, 
    and establishing these guidelines.</p>
  <p>Membership in the Committee is by invitation only and must be approved by consensus 
    of the active Committee members. </p>
  <p>Membership termination.</p>
  <h3>Private List</h3>
  <p>core@jakarta.apache.org</p>
  <p>The Committee maintains a private mailing list for discussion of issues that 
    are inappropriate for public discussion, such as legal or personal issues. </p>
  <h2>Source Code</h2>
  <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><i><font color="#FF0000">// security implications of write access</font></i></p>
  <h3>Status</h3>
  <p>Each of the Project's active source code repositories contain a file called 
    &quot;STATUS&quot; 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 might be useful 
    to help the group track progress. The active STATUS files are automatically 
    posted to the mailing list three times each week. </p>
  <p>Many issues will be encountered by the project, each resulting in zero or more 
    proposed action items. Issues should be raised on the mailing list as soon as 
    they are identified. Action items must be raised on the mailing list and added 
    to the relevant STATUS file. All action items may be voted on, but not all of 
    them will require a formal vote. </p>
  <h2>Voting</h2>
  <p>All Developers are encouraged to participate in decisions, but the decision 
    itself is made by those that have been long-time contributors to the project. 
    These contributors are known as Committers. In other words, the Project is a 
    minimum-threshold meritocracy.</p>
  <p>Any Developer may vote on any issue or action item. However, the only binding 
    votes are those cast by a Committer. If the 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>As all contributors to the Project are volunteers, members often become inactive 
    for periods of time in order to take care of their &quot;real jobs&quot; or 
    devote more time to other projects. it is therefore unlikely that the entire 
    group membership will vote on every issue. To account for this, all voting decisions 
    are based on a minimum quorum.</p>
  <p>Each vote can be made in one of three flavors:</p>
  <table width="100%" border="0">
    <tr valign="top"> 
      <td width="9%"><b>+1</b></td>
      <td width="91%">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="9%"><b>0</b></td>
      <td width="91%">Abstain, no opinion, or I am happy to let the other group 
        members decide this issue. An abstention may have deterimental effects if 
        too many people abstain. </td>
    </tr>
    <tr valign="top"> 
      <td width="9%"><b>-1</b></td>
      <td width="91%">No. On issues where consensus is required, this vote counts 
        as a <b>veto</b>. All vetos must include an explanation of why the veto 
        is appropriate. A veto with no explanation is 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 probelm 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 item requiring majority approval 
    must receive at least <b>3 binding +1</b> votes and more <b>+1</b> votes than 
    <b>-1</b> votes (i.e. a majority with a minimum quorum of three positive 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>Action Items are....</p>
  <dl> 
    <dt>Long Term Plans</dt>
    <dd>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 alternate plan would 
      be better, are obligated to inform the group of their feelings. In general, 
      it is always better to hear about alternate plans prior to spending time on 
      less adequate solutions.</dd>
    <dt>Short Term Plans</dt>
    <dd>Short term plans are announcements that a developer is working on a particular 
      set of documentation of code files, with the implication that other developers 
      should avoid them or try to coordinate their changes. This is a good way to 
      proactively avoid conflict and possible duplication of work.</dd>
    <dt>Release Plan</dt>
    <dd>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, and other assorted information to keep Develoeprs from 
      tripping over each other during the final moments of shipping code. Lazy majority 
      decides each issue in a release plan.</dd>
    <dt>Release Testing</dt>
    <dd>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.</dd>
    <dt>Showstoppers</dt>
    <dd>Showstoppers are issues that require a fix be in place before the next public 
      release. They are listed 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.</dd>
    <dt>Product Changes</dt>
    <dd>Changes to the products of the Project, including code and documentation, 
      will apear as action items in the STATUS file. All product chagnes to the 
      currently active repository are subject to lazy consensus. </dd>
  </dl>
  <h2>Changes</h2>
  <p>Simple patchs 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 commiting them into the repository. Any change that affects the semantics 
    of an existing API function, the size of the progrem, configuration data formats, 
    or other major areas must receive consensus approval on the appropriate development 
    mailing list before being committed.</p>
  <h3>Proposing a Major Change</h3>
  <p>A Developer is responsible for notifying the appropriate development mailing 
    list and adding an action item to the STATUS file when they have an idea for 
    a new feature or a major change to propose for the product. The distributed 
    nature of the Project requires an advance notice of 48 hours in order to properly 
    review a major change. Consensus approval of either the concept or a specific 
    patch is required before the change can be committed.</p>
  <h3>Commiting Changes</h3>
  <p>Related changes should be committed as a group, or very closely together. Half 
    completed 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 product 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, particularly 
    when completing the change requires access to a special development tool on 
    that other platform. If it is anticipated that a given change will break some 
    other platform, the committer must indicate that in the commit log. </p>
  <p>The committer is responsible for the quality of any third-party code or documentation 
    they commit to the repository. All software committed to the repository 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>
  <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 "bug fix" 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 [PATCH] and a distinctive one-line summary 
    corresponding to the action item for that patch.</p>
  <p>The patch should be created by using the diff -u command from the original 
    software file(s) to the modified software file(s). For example:</p>
  <blockquote>
    <p><font face="Courier New, Courier, mono" size="-1">diff -u Main.java.orig 
      Main.java &gt;&gt; patchfile.txt</font></p>
  </blockquote>
  <p>or</p>
  <blockquote>
    <p><font face="Courier New, Courier, mono" size="-1">diff -u Main.java &gt;&gt; 
      patchfile.txt</font></p>
  </blockquote>
  <p>All patches necessary to address an action item should be concatenated 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>The complete patchfile should produce no errors or prompts when the command:</p>
  <blockquote>
    <p><font face="Courier New, Courier, mono" size="-1">patch -s &lt; patchfile</font></p>
  </blockquote>
  <p>is issued in the target repository.</p>
  <p>&nbsp;</p>
  <dl>
    <dt>&nbsp; </dt>
  </dl>
  <p>&nbsp;</p>
  <p>&nbsp;</p>
  </body>
  </html>
  
  
  

Mime
View raw message