You are viewing a plain text version of this content. The canonical link for it is here.
Posted to site-cvs@jakarta.apache.org by du...@hyperreal.org on 1999/09/01 21:07:36 UTC
cvs commit: jakarta-site/mission guidelines.html guidelines.htsrc
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> </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 & Status<br>
Getting Involved<br>
<a href="/mission">Mission & 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 ©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> </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> </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 & Status<br>
Getting Involved<br>
<a href="/mission">Mission & 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 ©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> </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> </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 & Status<br>
Getting Involved<br>
<a href="/mission">Mission & 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 ©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 ©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> </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 ©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> </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 & Status<br>
Getting Involved<br>
<a href="/mission">Mission & 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 ©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> </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> </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 & Status<br>
Getting Involved<br>
<a href="/mission">Mission & 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
"STATUS" 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 "real jobs" 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 >> patchfile.txt</font></p>
</blockquote>
<p>or</p>
<blockquote>
<p><font face="Courier New, Courier, mono" size="-1">diff -u Main.java >>
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 < patchfile</font></p>
</blockquote>
<p>is issued in the target repository.</p>
<p> </p>
<dl>
<dt> </dt>
</dl>
<p> </p>
<p> </p>
</td>
</tr>
</table>
<br>
<table width="100%" border="0">
<tr>
<td><font size="-2">Copyright ©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> </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
"STATUS" 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 "real jobs" 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 >> patchfile.txt</font></p>
</blockquote>
<p>or</p>
<blockquote>
<p><font face="Courier New, Courier, mono" size="-1">diff -u Main.java >>
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 < patchfile</font></p>
</blockquote>
<p>is issued in the target repository.</p>
<p> </p>
<dl>
<dt> </dt>
</dl>
<p> </p>
<p> </p>
</body>
</html>