husted 2004/07/07 03:03:25
Modified: doc releases.xml volunteers.xml
Log:
Routine updates.
Revision Changes Path
1.8 +11 -12 jakarta-struts/doc/releases.xml
Index: releases.xml
===================================================================
RCS file: /home/cvs/jakarta-struts/doc/releases.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- releases.xml 20 Feb 2004 17:03:19 -0000 1.7
+++ releases.xml 7 Jul 2004 10:03:24 -0000 1.8
@@ -37,23 +37,22 @@
</ul>
<p>Additional remarks:</p>
<ul>
- <li>The release process can seem daunting when you review it for the first
time. But, essentially, it breaks down into three phases of just a few steps each:
+ <li>The release process can seem daunting when you review it for the first
time. But, essentially, it breaks down into four phases of just a few steps each:
<ul>
- <li>Building - Bugzilla, dependencies, release notes, JAR manifest,
licenses, copyrights, and build (using the release target).</li>
- <li>Testing - JUnit, Cactus, web apps (for all "supported"
containers).</li>
- <li>Distributing - Checksum, sign, mirror, release, update Struts site,
update Jakarta site, announce.</li>
+ <li><strong>Rolling</strong> - Bugzilla, dependencies, release notes, JAR
manifest, licenses, copyrights, and build (using the release target).</li>
+ <li><strong>Testing</strong> - JUnit, Cactus, web apps (for all
"supported" containers).</li>
+ <li><strong>Voting</strong> - Upload to home directory, post majority
vote on DEV list as to release grade: Alpha, Beta, General Availability.</li>
+ <li><strong>Distributing</strong> - Checksum, sign, mirror, update
download page, announce.</li>
</ul></li>
<li>Our dependencies on external JARs (including Commons JARs) should be in
line with our own release status. Our nightly build can be dependant on another
nightly build. Our beta can be dependant on another beta, but should avoid a
dependance on a nightly build. Our release candidate can have a dependance on another
RC, but should not have a dependance on a beta (and certainly
- <strong>not</strong>a nightly build). Our final release can only have
dependencies on other final releases.</li>
+ <strong>not</strong>a nightly build). Our General Availability release can
only have dependencies on other GA, final, or stable releases.</li>
<li>Use your own discretion as to detail needed by the Release Notes. A
high-level description of the changes is more important than providing uninterpreted
detail. At a minimum, new features and deprecations should be summarized, since these
are commonly asked questions. Ideally, the release notes should be maintained
continuously for the nightly build so that we do not need to quickly assembled them on
the eve of a Release.</li>
<li>Test building the distribution under prior version of J2SE, if
possible, to ensure that we are still backwardly-compatible. But, our Release
distribution should be built using the
<strong>latest release of J2SE</strong>, to take advantage of all available
compiler enhancements.</li>
<li>Before building the release, run the JUnit and Cactus tests using the
same configuration used that will be used to build the Release distribution.</li>
<li>There is a "release" target in the buildfile that will zip and tar the
releases. Before uploading the release, extract the sample web applications and deploy
the WARs under each of the "supported" containers. Play test each application under
each container to be sure they operate nominally.</li>
- <li>Be sure to copy the [EMAIL PROTECTED] list on any release
announcement.</li>
- <li>Remember to update the
- <a href="status.html">Status section of the Roadmap page</a> once a release
is available.</li>
- <li>By the way, the nightly builds are being created on a machine of Craig
McClanahan's. If there are problems with a nightly build that seem infrastructure
related, Craig is the one to contact.</li>
+ <li>The Alpha release can be posted to your Apache home directory
(www.apache.org/~$USERNAME) for initial testing. Once it is voted to Beta or GA
status, the release can be submitted to the distribution channels.</li>
+ <li>After announcing a release, remember to update the Announcements
page.</li>
</ul>
</section>
<section href="Coding" name="Coding Conventions and Guidelines">
@@ -78,8 +77,8 @@
<code>.*</code>).</li>
<li>Write all if/else statements as full blocks with each clause within
braces, unless the entire statement fits on the same line.</li>
<li>Use
- <code>:FIXME:</code>and
- <code>:TODO:</code>tokens to mark follow up notes in code. You may also
include your Apache username and the date.</li>
+ <code>FIXME:</code>and
+ <code>TODO:</code>tokens to mark follow up notes in code. You may also
include your Apache username and the date.</li>
<li>Omit
<code>@author</code>tags.</li>
<li>Use
@@ -111,7 +110,7 @@
</section>
<section>
<p class="right">Next:
- <a href="http://cvs.apache.org/viewcvs/jakarta-struts/";>CVS Repository</a></p>
+ <a href="http://struts.apache.org/roadmap.html";>Roadmap</a></p>
</section>
</body>
</document>
1.44 +14 -34 jakarta-struts/doc/volunteers.xml
Index: volunteers.xml
===================================================================
RCS file: /home/cvs/jakarta-struts/doc/volunteers.xml,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -r1.43 -r1.44
--- volunteers.xml 4 Jul 2004 18:01:08 -0000 1.43
+++ volunteers.xml 7 Jul 2004 10:03:24 -0000 1.44
@@ -2,7 +2,6 @@
<document url="./volunteers.xml">
<properties>
<title>Who We Are - The Apache Struts Web Application Framework</title>
-
<author>Ted Husted</author>
</properties>
@@ -13,87 +12,76 @@
<p>According to recently released
<a
href="http://www.apache.org/~vgritsenko/stats/projects/struts";>statistics</a>, Struts
downloads range around 15,000 a month.</p>
-
</section>
- <section name="Active Committers" href="committers">
+ <section name="Project Management Committee Members" href="pmc">
<ul>
<li>
- <strong>Craig R. McClanahan</strong>
-
+ <strong>Craig R. McClanahan</strong>, Vice President and Chair
(craigmcc at apache.org)</li>
<li>
<strong>Ted Husted</strong>
-
(husted at apache.org)</li>
<li>
<strong>Rob Leland</strong>
-
(rleland at apache.org)</li>
<li>
<strong>Cedric Dumoulin</strong>
-
(cedric.dumoulin at lifl.fr)</li>
<li>
<strong>Martin Cooper</strong>
-
(martinc at apache.org)</li>
<li>
<strong>Arron Bates</strong>
-
(arron at apache.org)</li>
<li>
<strong>James Holmes</strong>
-
(jholmes at apache.org)</li>
<li>
<strong>David M. Karr</strong>
-
(dmkarr at apache.org)</li>
<li>
<strong>David Graham</strong>
-
(dgraham at apache.org)</li>
<li>
<strong>James Mitchell</strong>
-
(jmitchell at apache.org)</li>
<li>
<strong>James Turner</strong>
-
(turner at blackbear.com)</li>
<li>
<strong>Steve Raeburn</strong>
-
(sraeburn at apache.org)</li>
<li>
<strong>Don Brown</strong>
-
(mrdon at apache.org)</li>
<li>
<strong>Joe Germuska</strong>
-
(germuska at apache.org)</li>
- <li>
- <strong>Niall Pemberton</strong>
-
- (niallp at apache.org)</li>
</ul>
</section>
+ <section name="Active Committers" href="committers">
+ <ul>
+ <li>
+ <strong>Niall Pemberton</strong>
+ (niallp at apache.org)</li>
+ </ul>
+ </section>
+
<section name="Emeritus Committers" href="comitters.emeritus">
<ul>
<li>David Geary</li>
@@ -104,21 +92,13 @@
<li>Michael Schachter</li>
- <li>
- <strong>Vincent Massol</strong>
- </li>
+ <li>Vincent Massol</li>
- <li>
- <strong>David Winterfeldt</strong>
- </li>
+ <li>David Winterfeldt</li>
- <li>
- <strong>Oleg Alexeev</strong>
- </li>
+ <li>Oleg Alexeev</li>
- <li>
- <strong>Eddie Bush</strong>
- </li>
+ <li>Eddie Bush</li>
</ul>
</section>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
