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/02 06:03:30 UTC
cvs commit: jakarta-site/mission index.html
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 & Status<br>
Getting Involved<br>
- <a href="/mission">Mission & 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 & Status<br>
Getting Involved<br>
- <a href="/mission">Mission & 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 & Status<br>
Getting Involved<br>
- <a href="/mission">Mission & 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 ©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 & Status<br>
Getting Involved<br>
- <a href="/mission">Mission & 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> </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/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
"action" 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 ©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/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
"action" 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> </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/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 "<em>Minimum
Threshold Meritocracy</em>".
</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 "<em>Action
Items</em>". 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 ©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/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 "<em>Minimum
Threshold Meritocracy</em>".
</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 "<em>Action
Items</em>". 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> </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/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 ©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/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> </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/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 ©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/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> </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/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 & 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 "<em>Committer</em>" 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 ©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/guidelines/roles.htsrc
Index: roles.htsrc
===================================================================
<html>
<head>
<!-- $Id -->
<title>Project Guidelines: Roles and Responsibilities</title>
</head>
<body>
<h1>Roles & 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 "<em>Committer</em>" 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> </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/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 "<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 "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 <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 ©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/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 "<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 "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 <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 & Status<br>
Getting Involved<br>
- <a href="/mission/index.html">Mission & 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>