Author: buildbot
Date: Wed Jan 22 10:45:19 2014
New Revision: 895083
Log:
Staging update by buildbot for struts
Modified:
websites/staging/struts/trunk/content/ (props changed)
websites/staging/struts/trunk/content/builds.html
websites/staging/struts/trunk/content/bylaws.html
websites/staging/struts/trunk/content/dev-mail.html
websites/staging/struts/trunk/content/git-for-struts.html
websites/staging/struts/trunk/content/releases.html
websites/staging/struts/trunk/content/volunteers.html
Propchange: websites/staging/struts/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Wed Jan 22 10:45:19 2014
@@ -1 +1 @@
-1560305
+1560308
Modified: websites/staging/struts/trunk/content/builds.html
==============================================================================
--- websites/staging/struts/trunk/content/builds.html (original)
+++ websites/staging/struts/trunk/content/builds.html Wed Jan 22 10:45:19 2014
@@ -9,7 +9,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta name="Date-Revision-yyyymmdd" content="20140122" />
<meta http-equiv="Content-Language" content="en" />
- <title></title>
+ <title>Source Code</title>
<link rel="stylesheet" href="./css/apache-maven-fluido-1.3.0.min.css" />
<link rel="stylesheet" href="./css/site.css" />
<link rel="stylesheet" href="./css/print.css" media="print" />
@@ -175,15 +175,15 @@
<div id="bodyColumn" >
- <h1>Source Code</h1><div class="section"><h2>Source Code<a
name="Source_Code"></a></h2><p>As a convenience to developers who are helping
to create and maintain the Apache Struts framework, public access to the live
source code repository is available. This is our one-and-only development
repository. Accordingly, the source may not always compile or be in a
release-ready state.</p><p><i>Access at your own risk!</i></p><p>NOTE: The full
source code is provided with each <a href="downloads.html">release.</a> If you
simply want to build your own copy of the product, use the source code provided
with an approved release, rather than the development head.</p><p>Read-only
access to the Apache Struts source repository is available through both <a
class="externalLink"
href="https://git-wip-us.apache.org/repos/asf/struts/repo?p=struts.git;a=summary";>web
browser</a> and <a class="externalLink" href="http://git-scm.com/";>Git
client</a> interfaces.</p><p>With the <a class="externalLi
nk" href="http://git-scm.com/";>Git client</a> installed, obtaining a working
copy of the Struts codebase is as simple as</p>
+ <p></p><h1>Source Code</h1><p>As a convenience to developers who
are helping to create and maintain the Apache Struts framework, public access
to the live source code repository is available. This is our one-and-only
development repository. Accordingly, the source may not always compile or be in
a release-ready state.</p><p><i>Access at your own risk!</i></p><p>NOTE: The
full source code is provided with each <a href="downloads.html">release.</a> If
you simply want to build your own copy of the product, use the source code
provided with an approved release, rather than the development
head.</p><p>Read-only access to the Apache Struts source repository is
available through both <a class="externalLink"
href="https://git-wip-us.apache.org/repos/asf/struts/repo?p=struts.git;a=summary";>web
browser</a> and <a class="externalLink" href="http://git-scm.com/";>Git
client</a> interfaces.</p><p>With the <a class="externalLink"
href="http://git-scm.com/";>Git client</a> installed, obt
aining a working copy of the Struts codebase is as simple as</p>
<div class="source"><pre class="prettyprint">> git clone
http://git.apache.org/repos/asf/struts.git
</pre></div><p>(Committers with write access should use the <b>https</b>
protocol instead)</p>
<div class="source"><pre class="prettyprint">> git clone
https://git-wip-us.apache.org/repos/asf/struts.git
-</pre></div><p>For more about using version control systems at Apache, see the
ASFs <a class="externalLink"
href="http://www.apache.org/dev/#version-control";>Source Code Repositories</a>
page.</p></div><div class="section"><h2>Building Apache Struts<a
name="Building_Apache_Struts"></a></h2><p>If you are building Apache Struts
from source, we recommend that you install and use <a class="externalLink"
href="http://maven.apache.org";>Apache Maven 3.</a> During the build process,
Maven will automatically acquire whatever external JARs your system may need.
(Of course, you can still use your build system of choice to build your own
applications!)</p><p>With Maven installed, building a Struts codebase is as
simple as</p>
+</pre></div><p>For more about using version control systems at Apache, see the
ASFs <a class="externalLink"
href="http://www.apache.org/dev/#version-control";>Source Code Repositories</a>
page.</p><h1>Building Apache Struts</h1><p>If you are building Apache Struts
from source, we recommend that you install and use <a class="externalLink"
href="http://maven.apache.org";>Apache Maven 3.</a> During the build process,
Maven will automatically acquire whatever external JARs your system may need.
(Of course, you can still use your build system of choice to build your own
applications!)</p><p>With Maven installed, building a Struts codebase is as
simple as</p>
<div class="source"><pre class="prettyprint">> mvn install
</pre></div><p>or</p>
<div class="source"><pre class="prettyprint">> mvn -DskipAssembly=true
install
-</pre></div><p>Maven will automatically download any dependencies as
needed.</p><p>For more about using Maven to build Struts 2, see <a
href="/2.x/docs/building-the-framework-from-source.html">Building the framework
from source</a> in the <a href="/2.x/docs/contributors-guide.html">Struts 2
Contributors Guide.</a></p><p>For more about using Maven to build Struts 1, see
our <a class="externalLink"
href="http://wiki.apache.org/struts/StrutsMaintenanceMaven";>Maven wiki
page.</a></p></div><div class="section"><h2>NightlyBuilds<a
name="NightlyBuilds"></a></h2><p>As part of our continuous integration
practice, we also make available each morning the <a class="externalLink"
href="https://builds.apache.org/view/S-Z/view/Struts/job/Struts2-JDK6/lastStableBuild/org.apache.struts$struts2-assembly/";>latest
stable development build.</a></p><p><i>Again: Use at your own
risk!</i></p><p>If you do <b>not</b> plan to contribute to the development of
the framework, then you probably want to download a
<a href="downloads.html">release</a></p><p>NOTE: The Struts 2 nightly build
is not fully operational. We suggest that contributors checkout the <a
href="#SourceCode">source code</a> instead.</p></div><div
class="section"><h2>Test Builds<a name="Test_Builds"></a></h2><p>As we prepare
for a new release, the project group may create interim <i>test builds</i>.
When test builds are available, we post them <a class="externalLink"
href="http://people.apache.org/builds/struts/";>here</a> in binary, source and
library distributions. Library distributions include any external dependencies
needed to use a product with your application.</p><p>A test build is made
available so that it can be reviewed for quality by the Apache Struts
development group. When a build is judged ready for prime time, it is promoted
to General Availability status and may be made the Best Available release. If
the group feels that a build requires more testing, then it may be marked as
Beta release. When a test build
is upgraded to Beta or GA by a vote of the project members, we make the
distribution available as a formal <a
href="downloads.html">release.</a></p></div><div class="section"><h2>Maven
Snapshots<a name="Maven_Snapshots"></a></h2><p>When a distribution is first
made available, it is rated as a development build or snapshot. Later, the
quality of the distribution may be upgraded to Beta or General Availability,
based on feedback from the community, and then made available through ibiblio
and other public Maven repositories. To obtain an early distribution via Maven,
specify the ASF Snapshot repository in the projects POM.</p>
+</pre></div><p>Maven will automatically download any dependencies as
needed.</p><p>For more about using Maven to build Struts 2, see <a
href="/2.x/docs/building-the-framework-from-source.html">Building the framework
from source</a> in the <a href="/2.x/docs/contributors-guide.html">Struts 2
Contributors Guide.</a></p><p>For more about using Maven to build Struts 1, see
our <a class="externalLink"
href="http://wiki.apache.org/struts/StrutsMaintenanceMaven";>Maven wiki
page.</a></p><h1>NightlyBuilds</h1><p>As part of our continuous integration
practice, we also make available each morning the <a class="externalLink"
href="https://builds.apache.org/view/S-Z/view/Struts/job/Struts2-JDK6/lastStableBuild/org.apache.struts$struts2-assembly/";>latest
stable development build.</a></p><p><i>Again: Use at your own
risk!</i></p><p>If you do <b>not</b> plan to contribute to the development of
the framework, then you probably want to download a <a
href="downloads.html">release</a></p><p>NOTE: The S
truts 2 nightly build is not fully operational. We suggest that contributors
checkout the <a href="#SourceCode">source code</a> instead.</p><h1>Test
Builds</h1><p>As we prepare for a new release, the project group may create
interim <i>test builds</i>. When test builds are available, we post them <a
class="externalLink" href="http://people.apache.org/builds/struts/";>here</a> in
binary, source and library distributions. Library distributions include any
external dependencies needed to use a product with your application.</p><p>A
test build is made available so that it can be reviewed for quality by the
Apache Struts development group. When a build is judged ready for prime time,
it is promoted to General Availability status and may be made the Best
Available release. If the group feels that a build requires more testing, then
it may be marked as Beta release. When a test build is upgraded to Beta or GA
by a vote of the project members, we make the distribution available as a
formal <
a href="downloads.html">release.</a></p><h1>Maven Snapshots</h1><p>When a
distribution is first made available, it is rated as a development build or
snapshot. Later, the quality of the distribution may be upgraded to Beta or
General Availability, based on feedback from the community, and then made
available through ibiblio and other public Maven repositories. To obtain an
early distribution via Maven, specify the ASF Snapshot repository in the
projects POM.</p>
<div class="source"><pre class="prettyprint"><repositories>
<repository>
<id>apache.snapshots</id>
@@ -191,7 +191,7 @@
<url>https://repository.apache.org/content/groups/snapshots/</url>
</repository>
</repositories>
-</pre></div></div><div class="section"><h2>Licensing of Apache Struts Builds<a
name="Licensing_of_Apache_Struts_Builds"></a></h2><p>Apache Struts 2 source
code and documentation is licensed to the Apache Software Foundation (ASF)
under one or more contributor license agreements. See the NOTICE file included
in any distribution for additional information regarding copyright ownership.
The ASF licenses the source code and documentation files in our Apache Struts
distribution to you under the Apache License, Version 2.0 (the License); you
may not use the Apache Struts product except in compliance with the
License.</p><p>You may obtain a copy of the License at
[http://www.apache.org/licenses/LICENSE-2.0]</p><p>Unless required by
applicable law or agreed to in writing, software distributed under the License
is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
either express or implied. See the License for the specific language governing
permissions and limitati
ons under the License.</p><p>Next: <a href="releases.html">Release
Guidelines</a></p></div>
+</pre></div><h1>Licensing of Apache Struts Builds</h1><p>Apache Struts 2
source code and documentation is licensed to the Apache Software Foundation
(ASF) under one or more contributor license agreements. See the NOTICE file
included in any distribution for additional information regarding copyright
ownership. The ASF licenses the source code and documentation files in our
Apache Struts distribution to you under the Apache License, Version 2.0 (the
License); you may not use the Apache Struts product except in compliance with
the License.</p><p>You may obtain a copy of the License at
[http://www.apache.org/licenses/LICENSE-2.0]</p><p>Unless required by
applicable law or agreed to in writing, software distributed under the License
is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
either express or implied. See the License for the specific language governing
permissions and limitations under the License.</p><p>Next: <a
href="releases.html">Release Guidelin
es</a></p>
</div>
</div>
Modified: websites/staging/struts/trunk/content/bylaws.html
==============================================================================
--- websites/staging/struts/trunk/content/bylaws.html (original)
+++ websites/staging/struts/trunk/content/bylaws.html Wed Jan 22 10:45:19 2014
@@ -9,7 +9,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta name="Date-Revision-yyyymmdd" content="20140122" />
<meta http-equiv="Content-Language" content="en" />
- <title></title>
+ <title>Project Management Committee Charter</title>
<link rel="stylesheet" href="./css/apache-maven-fluido-1.3.0.min.css" />
<link rel="stylesheet" href="./css/site.css" />
<link rel="stylesheet" href="./css/print.css" media="print" />
@@ -175,7 +175,7 @@
<div id="bodyColumn" >
- <h1>Project Management Committee Charter</h1><div
class="section"><h2>Apache Struts PMC Charter<a
name="Apache_Struts_PMC_Charter"></a></h2><p>Struts is a Project of the <a
class="externalLink" href="http://apache.org/foundation";>Apache Software
Foundation</a> (ASF), formed by a resolution of the <a class="externalLink"
href="http://apache.org/foundation/board/";>ASF Board of Directors</a>. As an
ASF Project, Struts is subject to the <a class="externalLink"
href="http://apache.org/foundation/bylaws.html";>ASF Bylaws</a> and the
direction of the ASF Board.</p><p>The Project Charter incorporates by reference
the current version of [How the ASF works](<a class="externalLink"
href="http://apache.org/foundation/how-it-works.html";>http://apache.org/foundation/how-it-works.html</a>,
with the additional guidelines and clarifications found herein.</p></div><div
class="section"><h2>Roles and Responsibilities<a
name="Roles_and_Responsibilities"></a></h2><p>The roles and responsibilit
ies 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 can earn the right to commit directly to the source
repository and to cast binding votes during the decision-making
process.</p><div class="section"><h3>Users.<a name="Users."></a></h3><p>Users
are the people who use the products of the Project. People in this role arent
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. When a user
starts to contribute code or documentation patches, they become a
Contributor.</p></div><div class="section"><h3>Contributors.<a
name="Contributors."></a></h3><p>Contributors are the people who write code or
documentation patches or contribute positively to the project in other ways.
When a volunteers patch is applied, the
contribution is recognized in the version control log.</p></div><div
class="section"><h3>Committers.<a name="Committers."></a></h3><p>Contributors
who give frequent and valuable contributions to a subproject of the Project can
have their status promoted to that of a <i>Committer</i> for that subproject. A
Committer has write access to the source code repository. Committer status is
granted by the Project Management Committee by majority vote.</p></div><div
class="section"><h3>Project Management Committee (PMC).<a
name="Project_Management_Committee_PMC."></a></h3><p>Committers and other
volunteers who frequently participate with valuable contributions may have
their status promoted to that of a <i>Project Management Committee Member</i>.
The PMC is responsible for the day-to-day management of the
Project.</p></div></div><div class="section"><h2>Management<a
name="Management"></a></h2><p>The Vice President is appointed by the ASF Board.
The Vice President is assisted by the Project M
anagement Committee (PMC) and also serves as the PMC chair. The PMC may
nominate new members. Nominees may then be approved with a 3/4 majority vote of
the PMC. Membership can be revoked by a unanimous vote of all the active PMC
members other than the member in question. The list of active PMC members can
be found on our <a href="volunteers.html">Volunteers page</a>.</p></div><div
class="section"><h2>PMC Duties<a name="PMC_Duties"></a></h2><p>The PMC is
responsible for the day-to-day management of the Struts Project. The PMC
oversees all changes made to the codebase. The PMC must ensure that all code
under a Apache Struts repository is the lawful property of the Foundation and
may be distributed under the <a class="externalLink"
href="http://apache.org/licenses/";>Apache Software License</a>. All releases of
a Struts subproject must be sanctioned by the Project Management
Committee.</p></div><div class="section"><h2>Subprojects<a
name="Subprojects"></a></h2><p>Subprojects are the Pro
jects unit of release. Each subproject should represent an implementation of a
Struts framework or a related component. Each subproject should focus on
creating, maintaining, and releasing a single software product or
deliverable.</p><p>All PMC Members have voting rights in all subprojects.
Members not familiar with a subproject codebase may abstain from any given
vote. All Committers have write access to all subprojects. Subprojects are
units of release, not units of work.</p><p>PMC members may propose the creation
of new subprojects. Proposals are to contain the scope of the project, identify
the initial source from which the project is to be populated, identify any
mailing lists or repositories, if any, which are to be created. Creation of a
new subproject requires approval by a 3/4 majority vote of the
PMC.</p></div><div class="section"><h2>Decision Making<a
name="Decision_Making"></a></h2><p>All <a class="externalLink"
href="http://apache.org/foundation/how-it-works.html#roles";
>Volunteers</a> (Users, Developers, Committers, PMC Members) are encouraged to
>participate in the decision-making process, but binding decisions are made
>only by the Project Management Committee.</p></div><div
>class="section"><h2>Voting<a name="Voting"></a></h2><p>Any subscriber to the
>list may <a class="externalLink"
>href="http://apache.org/foundation/voting.html";>vote</a> on any issue or
>action item. Votes from Developers and Committers are especially welcome.
>However, the only binding votes are those cast by a PMC Member.</p><p>The act
>of voting carries certain obligations. Voters 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>
+ <p></p><h1>Apache Struts PMC Charter</h1><p>Struts is a Project of
the <a class="externalLink" href="http://apache.org/foundation";>Apache Software
Foundation</a> (ASF), formed by a resolution of the <a class="externalLink"
href="http://apache.org/foundation/board/";>ASF Board of Directors</a>. As an
ASF Project, Struts is subject to the <a class="externalLink"
href="http://apache.org/foundation/bylaws.html";>ASF Bylaws</a> and the
direction of the ASF Board.</p><p>The Project Charter incorporates by reference
the current version of [How the ASF works](<a class="externalLink"
href="http://apache.org/foundation/how-it-works.html";>http://apache.org/foundation/how-it-works.html</a>,
with the additional guidelines and clarifications found herein.</p><h1>Roles
and Responsibilities</h1><p>The roles and responsibilities 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 t
he project can earn the right to commit directly to the source repository and
to cast binding votes during the decision-making
process.</p><h1>Users.</h1><p>Users are the people who use the products of the
Project. People in this role arent 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. When a user starts to contribute code or documentation patches, they
become a Contributor.</p><h1>Contributors.</h1><p>Contributors are the people
who write code or documentation patches or contribute positively to the project
in other ways. When a volunteers patch is applied, the contribution is
recognized in the version control log.</p><h1>Committers.</h1><p>Contributors
who give frequent and valuable contributions to a subproject of the Project can
have their status promoted to that of a <i>Committer</i> for that subproject. A
Committer
has write access to the source code repository. Committer status is granted
by the Project Management Committee by majority vote.</p><h1>Project Management
Committee (PMC).</h1><p>Committers and other volunteers who frequently
participate with valuable contributions may have their status promoted to that
of a <i>Project Management Committee Member</i>. The PMC is responsible for the
day-to-day management of the Project.</p><h1>Management</h1><p>The Vice
President is appointed by the ASF Board. The Vice President is assisted by the
Project Management Committee (PMC) and also serves as the PMC chair. The PMC
may nominate new members. Nominees may then be approved with a 3/4 majority
vote of the PMC. Membership can be revoked by a unanimous vote of all the
active PMC members other than the member in question. The list of active PMC
members can be found on our <a href="volunteers.html">Volunteers
page</a>.</p><h1>PMC Duties</h1><p>The PMC is responsible for the day-to-day
management of
the Struts Project. The PMC oversees all changes made to the codebase. The
PMC must ensure that all code under a Apache Struts repository is the lawful
property of the Foundation and may be distributed under the <a
class="externalLink" href="http://apache.org/licenses/";>Apache Software
License</a>. All releases of a Struts subproject must be sanctioned by the
Project Management Committee.</p><h1>Subprojects</h1><p>Subprojects are the
Projects unit of release. Each subproject should represent an implementation of
a Struts framework or a related component. Each subproject should focus on
creating, maintaining, and releasing a single software product or
deliverable.</p><p>All PMC Members have voting rights in all subprojects.
Members not familiar with a subproject codebase may abstain from any given
vote. All Committers have write access to all subprojects. Subprojects are
units of release, not units of work.</p><p>PMC members may propose the creation
of new subprojects. Proposals are
to contain the scope of the project, identify the initial source from which
the project is to be populated, identify any mailing lists or repositories, if
any, which are to be created. Creation of a new subproject requires approval by
a 3/4 majority vote of the PMC.</p><h1>Decision Making</h1><p>All <a
class="externalLink"
href="http://apache.org/foundation/how-it-works.html#roles";>Volunteers</a>
(Users, Developers, Committers, PMC Members) are encouraged to participate in
the decision-making process, but binding decisions are made only by the Project
Management Committee.</p><h1>Voting</h1><p>Any subscriber to the list may <a
class="externalLink" href="http://apache.org/foundation/voting.html";>vote</a>
on any issue or action item. Votes from Developers and Committers are
especially welcome. However, the only binding votes are those cast by a PMC
Member.</p><p>The act of voting carries certain obligations. Voters 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" class="table table-striped">
<tr class="a">
<td>
@@ -212,7 +212,7 @@
group to revoke that Committer's write privileges.
</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><p>Voting represent consensus and votes are never final. Circumstances
change, and so may votes. A veto may be converted to a +1 after discussion, and
likewise a +1 may be converted to a -1. By convention, Committers should allow
a vote to circulate for 72 hours before taking action.</p></div><div
class="section"><h2>Action Items<a name="Action_Items"></a></h2><p>All
decisions revolve around <i>Action Items</i>. Action Items consist of the
following: - Long Term Plans - Short Term Plans - Product Changes -
Showstoppers (or blo
ckers) - Release Plan - Release Grade</p><div class="section"><h3>Long Term
Plans<a name="Long_Term_Plans"></a></h3><p>Long term plans are simply
announcements that group members are working on particular issues related to
the Project. These items are not voted on, but Committers and PMC Members 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></div><div
class="section"><h3>Short Term Plan<a name="Short_Term_Plan"></a></h3><p>Short
term plans are announcements that a volunteer is working on a particular set of
documentation or code files with the implication that other volunteers should
avoid them or try to coordinate their changes.</p></div><div
class="section"><h3>Product Changes<a name="Product_Changes"></a></h3><p>All
product changes to the repository are subject to lazy consensus.</p></div><div
class="section"><h3>Showstoppers<a name="Showstoppers"></a></h3><p>Showstoppers
are iss
ues that require a fix be in place before the next public release. They are
designated as blockers in the issue tracker in order to focus special attention
on these problems. An issue becomes a showstopper when it is designated as such
in the issue tracker by a PMC member and remains so by lazy
consensus.</p></div><div class="section"><h3>Release Plan<a
name="Release_Plan"></a></h3><p>A release plan must be used to keep all
volunteers aware of when a release is desired, whether it will be a major,
minor, or milestone release, who will be the release manager, when the
repository will be tagged to create the distribution, and other assorted
information to keep volunteers from tripping over each other. A release plan
must be incorporated into the product documentation, or otherwise announced to
the DEV list. Lazy majority decides each issue in a release plan.</p></div><div
class="section"><h3>Release Grade<a name="Release_Grade"></a></h3><p>After a
proposed release is built, it must be
tested and classified before being released to the general public. The
proposed release may be assigned Alpha, Beta or General Availability
classifications by majority vote. Once a release is classified by the PMC
Members, it may be distributed to the general public on behalf of the
Foundation. Distributions may be reclassified or withdrawn by majority vote,
but the release number may not be reused by another
distribution.</p></div></div><div class="section"><h2>Sandbox<a
name="Sandbox"></a></h2><p>Pursuant to the <a class="externalLink"
href="http://incubator.apache.org/learn/rules-for-revolutionaries.html";>Rules
for Revolutionaries</a>, any committer may submit experimental material to the
Sandbox area of the repository at his or her own discretion.</p><p>Material
must be moved from the sandbox to the main repository before it can be
released.</p><p>If a sandbox whiteboard becomes dormant for six or more months,
it may be moved to the archive section of the repository.</p><p>Expe
rimental material that is outside the scope of the Struts project may also be
submitted to the <a class="externalLink" href="http://labs.apache.org/";>Apache
Labs</a></p><p>Next: <a href="volunteers.html">Volunteers</a></p></div>
+</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><p>Voting represent consensus and votes are never final. Circumstances
change, and so may votes. A veto may be converted to a +1 after discussion, and
likewise a +1 may be converted to a -1. By convention, Committers should allow
a vote to circulate for 72 hours before taking action.</p><h1>Action
Items</h1><p>All decisions revolve around <i>Action Items</i>. Action Items
consist of the following: - Long Term Plans - Short Term Plans - Product
Changes - Showstoppers (or blockers) - Release Plan - Release Grade</p><div
class="s
ection"><h2>Long Term Plans<a name="Long_Term_Plans"></a></h2><p>Long term
plans are simply announcements that group members are working on particular
issues related to the Project. These items are not voted on, but Committers and
PMC Members 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></div><div class="section"><h2>Short Term Plan<a
name="Short_Term_Plan"></a></h2><p>Short term plans are announcements that a
volunteer is working on a particular set of documentation or code files with
the implication that other volunteers should avoid them or try to coordinate
their changes.</p></div><div class="section"><h2>Product Changes<a
name="Product_Changes"></a></h2><p>All product changes to the repository are
subject to lazy consensus.</p></div><div class="section"><h2>Showstoppers<a
name="Showstoppers"></a></h2><p>Showstoppers are issues that require a fix be
in place before the next pub
lic release. They are designated as blockers in the issue tracker in order to
focus special attention on these problems. An issue becomes a showstopper when
it is designated as such in the issue tracker by a PMC member and remains so by
lazy consensus.</p></div><div class="section"><h2>Release Plan<a
name="Release_Plan"></a></h2><p>A release plan must be used to keep all
volunteers aware of when a release is desired, whether it will be a major,
minor, or milestone release, who will be the release manager, when the
repository will be tagged to create the distribution, and other assorted
information to keep volunteers from tripping over each other. A release plan
must be incorporated into the product documentation, or otherwise announced to
the DEV list. Lazy majority decides each issue in a release plan.</p></div><div
class="section"><h2>Release Grade<a name="Release_Grade"></a></h2><p>After a
proposed release is built, it must be tested and classified before being
released to the ge
neral public. The proposed release may be assigned Alpha, Beta or General
Availability classifications by majority vote. Once a release is classified by
the PMC Members, it may be distributed to the general public on behalf of the
Foundation. Distributions may be reclassified or withdrawn by majority vote,
but the release number may not be reused by another
distribution.</p><h1>Sandbox</h1><p>Pursuant to the <a class="externalLink"
href="http://incubator.apache.org/learn/rules-for-revolutionaries.html";>Rules
for Revolutionaries</a>, any committer may submit experimental material to the
Sandbox area of the repository at his or her own discretion.</p><p>Material
must be moved from the sandbox to the main repository before it can be
released.</p><p>If a sandbox whiteboard becomes dormant for six or more months,
it may be moved to the archive section of the repository.</p><p>Experimental
material that is outside the scope of the Struts project may also be submitted
to the <a class="exte
rnalLink" href="http://labs.apache.org/";>Apache Labs</a></p><p>Next: <a
href="volunteers.html">Volunteers</a></p></div>
</div>
</div>
Modified: websites/staging/struts/trunk/content/dev-mail.html
==============================================================================
--- websites/staging/struts/trunk/content/dev-mail.html (original)
+++ websites/staging/struts/trunk/content/dev-mail.html Wed Jan 22 10:45:19 2014
@@ -9,7 +9,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta name="Date-Revision-yyyymmdd" content="20140122" />
<meta http-equiv="Content-Language" content="en" />
- <title></title>
+ <title>Dev Mailing List</title>
<link rel="stylesheet" href="./css/apache-maven-fluido-1.3.0.min.css" />
<link rel="stylesheet" href="./css/site.css" />
<link rel="stylesheet" href="./css/print.css" media="print" />
@@ -175,7 +175,7 @@
<div id="bodyColumn" >
- <h1>Dev Mailing List</h1><div class="section"><h2>Development
Lists<a name="Development_Lists"></a></h2><p>The following mailing lists are
meant for people who want to contribute to Struts itself. Patches,
Documentation improvements and discussion on future Struts are welcome. **For
questions on using Struts, please subscribe to the <a href="mail.html">user
list</a>**.</p><p>Please make sure you have read the guidelines on <a
href="mail.html">this page</a></p>
+ <p></p><h1>Development Lists</h1><p>The following mailing lists
are meant for people who want to contribute to Struts itself. Patches,
Documentation improvements and discussion on future Struts are welcome. **For
questions on using Struts, please subscribe to the <a href="mail.html">user
list</a>**.</p><p>Please make sure you have read the guidelines on <a
href="mail.html">this page</a></p>
<table border="0" class="table table-striped">
<tr class="a">
<th>Name</th>
@@ -201,7 +201,7 @@
<td><a class="externalLink"
href="mailto:[email protected]?subject=unsubscribe&body=unsubscribe";>[email protected]</a></td>
<td>Receive notifications from the Struts issue tracker.</td>
</tr>
-</table></div><div class="section"><h2>Archives<a
name="Archives"></a></h2><p>You can read the <a class="externalLink"
href="http://mail-archives.apache.org/mod_mbox/struts-dev/";>ASF Mail</a> or the
<a class="externalLink"
href="http://markmail.org/list/org.apache.struts.dev/";>Mark Mail</a> archives
if you are looking for older discussions. There are many other archives out
there as well.</p></div>
+</table><h1>Archives</h1><p>You can read the <a class="externalLink"
href="http://mail-archives.apache.org/mod_mbox/struts-dev/";>ASF Mail</a> or the
<a class="externalLink"
href="http://markmail.org/list/org.apache.struts.dev/";>Mark Mail</a> archives
if you are looking for older discussions. There are many other archives out
there as well.</p>
</div>
</div>
Modified: websites/staging/struts/trunk/content/git-for-struts.html
==============================================================================
--- websites/staging/struts/trunk/content/git-for-struts.html (original)
+++ websites/staging/struts/trunk/content/git-for-struts.html Wed Jan 22
10:45:19 2014
@@ -9,7 +9,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta name="Date-Revision-yyyymmdd" content="20140122" />
<meta http-equiv="Content-Language" content="en" />
- <title></title>
+ <title>Git for Struts</title>
<link rel="stylesheet" href="./css/apache-maven-fluido-1.3.0.min.css" />
<link rel="stylesheet" href="./css/site.css" />
<link rel="stylesheet" href="./css/print.css" media="print" />
@@ -175,7 +175,7 @@
<div id="bodyColumn" >
- <h1>Using Git with Struts</h1><p>So far, Struts 2 is using SVN.
There are plans to move on to GIT but the plannings have not been completed
yet. In addition well only move with new versions of Struts to Git. Struts 1
will stay in SVN.</p><p>Luckily there is a way to work with Git backed by SVN.
This document explains, how a developer:</p>
+ <p></p><h1>Using Git with Struts</h1><p>So far, Struts 2 is using
SVN. There are plans to move on to GIT but the plannings have not been
completed yet. In addition well only move with new versions of Struts to Git.
Struts 1 will stay in SVN.</p><p>Luckily there is a way to work with Git backed
by SVN. This document explains, how a developer:</p>
<ul>
<li>can work on outdated code like Struts 1 with Git</li>
<li>can synchronize Git from Github with the Struts 2 repository</li>
Modified: websites/staging/struts/trunk/content/releases.html
==============================================================================
--- websites/staging/struts/trunk/content/releases.html (original)
+++ websites/staging/struts/trunk/content/releases.html Wed Jan 22 10:45:19 2014
@@ -9,7 +9,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta name="Date-Revision-yyyymmdd" content="20140122" />
<meta http-equiv="Content-Language" content="en" />
- <title></title>
+ <title>Release Guidelines</title>
<link rel="stylesheet" href="./css/apache-maven-fluido-1.3.0.min.css" />
<link rel="stylesheet" href="./css/site.css" />
<link rel="stylesheet" href="./css/print.css" media="print" />
@@ -175,7 +175,7 @@
<div id="bodyColumn" >
- <h1>Release Guidelines</h1><div class="section"><h2>Release
Guidelines<a name="Release_Guidelines"></a></h2><p>This document describes the
Apache Struts release process and our <a href="#Coding">coding conventions</a>,
which are applicable to all subprojects. Both stable and development releases
are <a href="downloads.html">available for download.</a></p></div><div
class="section"><h2>Release Process<a name="Release_Process"></a></h2><p>A <a
class="externalLink"
href="http://commons.apache.org/releases/versioning.html";>point release</a>
should be made before and after any product change that is not a
fully-compatible change (see link). This includes moving a dependency from an
internal package to an external product, including products distributed through
the Apache Commons. We should place any fully-compatible changes in the hands
of the community before starting on a change that is only interface or
external-interface compatible.</p><p>Additional remarks:</p>
+ <p></p><h1>Release Guidelines</h1><p>This document describes the
Apache Struts release process and our <a href="#Coding">coding conventions</a>,
which are applicable to all subprojects. Both stable and development releases
are <a href="downloads.html">available for download.</a></p><h1>Release
Process</h1><p>A <a class="externalLink"
href="http://commons.apache.org/releases/versioning.html";>point release</a>
should be made before and after any product change that is not a
fully-compatible change (see link). This includes moving a dependency from an
internal package to an external product, including products distributed through
the Apache Commons. We should place any fully-compatible changes in the hands
of the community before starting on a change that is only interface or
external-interface compatible.</p><p>Additional remarks:</p>
<ul>
<li>Every committer is encouraged to participate in the release process,
either as the release manager or a helper. Committers may also share the
release manager role.</li>
<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:</li>
@@ -195,7 +195,7 @@
<li>Any formal release may be submitted for mirroring. All GA releases
<b>must</b> be mirrored.</li>
<li>After announcing a release, remember to update the Downloads and
Announcements pages. If the release is to be mirrored, wait at least 24 hours
after submittal before making public announcements (as stated in the <a
class="externalLink" href="http://apache.org/dev/mirrors.html";>Apache Mirroring
guidelines</a>.</li>
<li>If a serious flaw if found in a test build or release, it may be
withdrawn by a majority vote of the PMC and removed from ASF distribution
channels.</li>
-</ul></div><div class="section"><h2>Coding Conventions and Guidelines<a
name="Coding_Conventions_and_Guidelines"></a></h2><p>Source code and
documentation contributed to the Struts repositories should observe the: - The
<a class="externalLink"
href="http://www.oracle.com/technetwork/java/codeconvtoc-136057.html";>Code
Conventions for the Java Programming Language</a>, as published by
Oracle.</p><div class="section"><h3>Clarifications<a
name="Clarifications"></a></h3>
+</ul><h1>Coding Conventions and Guidelines</h1><p>Source code and
documentation contributed to the Struts repositories should observe the: - The
<a class="externalLink"
href="http://www.oracle.com/technetwork/java/codeconvtoc-136057.html";>Code
Conventions for the Java Programming Language</a>, as published by
Oracle.</p><h1>Clarifications</h1>
<ul>
<li>First, Observe the style of the original. Resist the temptation to make
stylistic changes for their own sake. But, if you must reformat code, commit
style changes separately from code changes. Either change the style, commit,
and then change the code, or vice-versa.</li>
<li>Set editors to replace tabs with spaces and do not trim trailing spaces.
Tabs confound the version control alerts. Trimming trailing spaces creates
unnecessary changes.</li>
@@ -213,7 +213,7 @@
<li>Our favorite books about programming are <a class="externalLink"
href="http://www.amazon.com/exec/obidos/ISBN=0201633612/apachesoftwar-20/";>Design
Patterns</a>, [Refactoring](<a class="externalLink"
href="http://www.amazon.com/exec/obidos/ISBN=0201485672/apachesoftwar-20/";>http://www.amazon.com/exec/obidos/ISBN=0201485672/apachesoftwar-20/</a>,
and <a class="externalLink"
href="http://www.amazon.com/exec/obidos/ISBN=0735619670/apachesoftwar-20/";>Code
Complete</a></li>
<li>Our favorite book about open source development is the <a
class="externalLink"
href="http://www.amazon.com/exec/obidos/ISBN=1565927249/apachesoftwar-20/";>The
Cathedral and the Bazaar</a></li>
<li>Our favorite science fiction author is <a class="externalLink"
href="http://www.nitrosyncretic.com/rah/";>Robert Heinlein</a>, <a
class="externalLink"
href="http://jargon.net/jargonfile/t/TANSTAAFL.html";>TANSTAAFL</a>, (Except on
Friday, when we favor <a class="externalLink"
href="http://news.bbc.co.uk/1/hi/uk/1326657.stm";>Douglas Adams</a>).</li>
-</ul><p>Next: <a href="bylaws.html">PMC Charter</a></p></div></div>
+</ul><p>Next: <a href="bylaws.html">PMC Charter</a></p>
</div>
</div>
Modified: websites/staging/struts/trunk/content/volunteers.html
==============================================================================
--- websites/staging/struts/trunk/content/volunteers.html (original)
+++ websites/staging/struts/trunk/content/volunteers.html Wed Jan 22 10:45:19
2014
@@ -9,7 +9,7 @@
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta name="Date-Revision-yyyymmdd" content="20140122" />
<meta http-equiv="Content-Language" content="en" />
- <title> Volunteers</title>
+ <title>Volunteers</title>
<link rel="stylesheet" href="./css/apache-maven-fluido-1.3.0.min.css" />
<link rel="stylesheet" href="./css/site.css" />
<link rel="stylesheet" href="./css/print.css" media="print" />
