You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@struts.apache.org by bu...@apache.org on 2014/01/22 11:45:19 UTC
svn commit: r895083 - in /websites/staging/struts/trunk/content: ./
builds.html bylaws.html dev-mail.html git-for-struts.html releases.html
volunteers.html
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:issues-unsubscribe@struts.apache.org?subject=unsubscribe&body=unsubscribe">issues-unsubscribe@struts.apache.org</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" />