svn commit: r872433 - in /websites/staging/maven/trunk/content: ./ maven-site-1.0-site.jar project-roles.html

[bu...@apache.org]

Author: buildbot
Date: Fri Aug  2 12:18:58 2013
New Revision: 872433

Log:
Staging update by buildbot for maven

Modified:
    websites/staging/maven/trunk/content/   (props changed)
    websites/staging/maven/trunk/content/maven-site-1.0-site.jar
    websites/staging/maven/trunk/content/project-roles.html

Propchange: websites/staging/maven/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Fri Aug  2 12:18:58 2013
@@ -1 +1 @@
-1509594
+1509650

Modified: websites/staging/maven/trunk/content/maven-site-1.0-site.jar
==============================================================================
Binary files - no diff available.

Modified: websites/staging/maven/trunk/content/project-roles.html
==============================================================================
--- websites/staging/maven/trunk/content/project-roles.html (original)
+++ websites/staging/maven/trunk/content/project-roles.html Fri Aug  2 12:18:58 2013
@@ -322,7 +322,7 @@ under the License. --><h1>Apache Maven P
   
 <li>Ensure that code committed to the project is either committed under a valid CLA  or is code that was contributed with a clear indication that the Apache License  applied (i.e. small patches submitted to the issue tracker or to the mailing list  are assumed to be submitted with the intent of being covered by the Apache  License unless the submitter clearly marks those patches as not being covered)</li>
   
-<li>Ensure that third part dependencies shipped as part of the project&#x2019;s releases  are covered by a compatible license.</li>
+<li>Ensure that third party dependencies shipped as part of the project&#x2019;s releases  are covered by a compatible license.</li>
   
 <li>Voting on release artifacts;</li>
   
@@ -339,7 +339,7 @@ under the License. --><h1>Apache Maven P
 
 <ul>
   
-<li>A compatible license, i.e. Category A or Category B</li>
+<li>A <a class="externalLink" href="http://www.apache.org/legal/3party.html">compatible license</a>, i.e. <a class="externalLink" href="http://www.apache.org/legal/3party.html#category-a">Category A</a> or <a class="externalLink" href="http://www.apache.org/legal/3party.html#category-b">Category B</a></li>
   
 <li>A good technical fit</li>
   
@@ -355,12 +355,12 @@ under the License. --><h1>Apache Maven P
   
 <li>By the PMC, to check the legal responsibilities delegated by  the Board; and</li>
   
-<li>By the committers (which includes the PMC), to check that the technical  direction and quality is in line with the consensus roadmap.</li>
+<li>By the committers (which includes the PMC), to check that the technical  direction and quality is in line with the consensus roadmap (where such a  roadmap has been agreed).</li>
 </ul>
-<p>It is self evident that the opertunity for review is much greater if the code is committed to the project&#x2019;s source control as early as possible. Similarly small commits are easier to review than large commits.</p>
+<p>It is self evident that the opportunity for review is much greater if the code is committed to the project&#x2019;s source control as early as possible. Similarly small commits are easier to review than large commits.</p>
 <p>There is nothing inherently wrong with maintaining a fork of the Maven codebase outside of the Apache Foundation. Individual developers can have their own style of working and may prefer to work in a fork so that they can throw away failed experiments with less visibility (though it could be argued that the visibility of such failed experiments can be valuable documentation for others). As soon as changes in that fork are identified which should be brought back to the project those changes should be introduced into at least a branch hosted on the Apache Maven source control in order to facilitate the easier review by the community.</p>
 <p>The PMC should encourage by example the early committing of changes from a fork back to Apache Maven source control. </p>
-<p>Similarly, if a fork is being hosted elsewhere in order to get contributions from other talented individuals, the PMC members should endevour to bring those individuals and their tallent to the project as committers.</p>
+<p>Similarly, if a fork is being hosted elsewhere in order to get contributions from other talented individuals, the PMC members should endevour to bring those individuals and their talent to the project as committers.</p>
 <p>Finally, where a fork is hosted outside of Apache hardware, there is less traceability of the code provenance, for example GIT commits can be squashed and history re-written to mask or otherwise hide the source of contributions. This does not mean that code coming from an external fork inherently has such issues, instead it means that the requirements for review and verification of provenance grow exponentially when dealing with large sets of changes originating from a long running fork hosted outside of Apache foundation source control. Anybody maintaining a long running fork should be aware of the risk that review obligations may grow above the time capabilities of the PMC and committers such that when they eventually decide to try and bring the changes in their fork back to the Apache Maven project their contribution may end up being rejected on the basis of the review of a large set of changes being too difficult/timeconsuming.</p></div></div>
 <div class="section">
 <h3><a class="externalLink" href="http://www.apache.org/foundation/how-it-works.html#pmc-chair">Project Management Chair</a><a name="Project_Management_Chair"></a></h3>