maven-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r872417 - in /websites/staging/maven/trunk/content: ./ maven-site-1.0-site.jar project-roles.html
Date Fri, 02 Aug 2013 09:53:57 GMT
Author: buildbot
Date: Fri Aug  2 09:53:57 2013
New Revision: 872417

Staging update by buildbot for maven

    websites/staging/maven/trunk/content/   (props changed)

Propchange: websites/staging/maven/trunk/content/
--- cms:source-revision (original)
+++ cms:source-revision Fri Aug  2 09:53:57 2013
@@ -1 +1 @@

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 09:53:57 2013
@@ -306,27 +306,68 @@ under the License. --><h1>Apache Maven P
-<li>Proposing active contributors for committership,</li>
+<li>Active management of those projects identified by the resolution of the Board 
of Directors of the Apache Foundation;</li>
-<li>Binding votes in project decisions,</li>
+<li>Ensure the project remains a healthy top-level project of the Apache Foundation
 (if a PMC member wants the project to be hosted elsewhere they should resign  from the PMC
stating their reason - if the PMC shrinks beyond the minimal viable  size then as a result
of a desire by the bulk of the PMC to move the project  elsewhere, the Board of the Apache
Foundation will take that into account  when moving the project into the Foundation&#x2019;s
-<li>Voting on release artifacts,</li>
+<li>Prepare reports as required by the Board of the Apache Foundation and  ensure those
reports are ready for presentation by the PMC Chair in a timely  manner;</li>
-<li>Ensure <a href="/developers/index.html#Developers_Conventions">Developers
Conventions</a> are followed, or updated/improved if necessary,</li>
+<li>Defend the trademarks belonging to the project;</li>
-  <!-- TODO: get the rest of these --></li>
+<li>Proposing active contributors for committership;</li>
+<li>Ensure that votes in the community are used as a tool to establish consensus  and
not a weapon to disenfranchise or alienate a minority of the community;</li>
+<li>Binding votes in project decisions;</li>
+<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>Voting on release artifacts;</li>
+<li>Ensure <a href="/developers/index.html#Developers_Conventions">Developers
Conventions</a> are followed, or updated/improved if necessary;</li>
 <div class="section">
 <h4>Standards for Community Commitment<a name="Standards_for_Community_Commitment"></a></h4>
-<p>In the spirit of supporting the health of our community, Project Management Committee
members refrain from actions that subvert the functioning of the committee itself.</p>
-<p>First, Project Management Committee members should not maintain long-running forks
of Maven code outside of the project itself. Making significant changes to Maven code outside
of the project displays a lack of investment in the community. Additionally, attempting to
re-integrate a large number of code changes in bulk overwhelms the ability of volunteers in
the community to review (and potentially veto) the changes. This effectively thwarts the policing
function of the PMC.</p>
-<p>Second, Project Management Committee members should not divert work on redesigning,
reimplementing, or improving Maven code to alternative projects outside of this community
for the purposes of reintroducing them as replacement for existing Maven code. While there
is a danger here of falling into a Not Invented Here mentality, new projects created by Maven
PMC members strictly to replace Maven code should not be allowed.</p></div></div>
+<p>In the spirit of supporting the health of our community, Project Management Committee
members refrain from actions that subvert the functioning of the committee itself.</p></div>
+<div class="section">
+<h4>Promotion of other projects<a name="Promotion_of_other_projects"></a></h4>
+<p>The Apache Foundation currently does not have a policy requiring projects to cross-promote.
For example Subversion is an Apache project, yet projects are free to choose from Subversion
and GIT (a non-Apache project) for source control.</p>
+<p>When considering integration of technologies within Maven, there is thus no requirement
that other Apache projects be picked over non-Apache projects.</p>
+<p>The primary requirements for picking technologies to integrate with Maven are thus:</p>
+<li>A compatible license, i.e. Category A or Category B</li>
+<li>A good technical fit</li>
+<li>A strong preference on behalf of the portion of the community that  will be doing
the integration.</li>
+<p>Where a PMC member is advocating a specific technology, they should declare any
interest / involvement that they have in that technology or a competing technology - irrespective
of whether the project is an Apache project or a project hosted elsewhere.</p>
+<p>PMC members with a stated interest / involvement should try to abstain from making
binding votes in either direction with respect to the relevant technology choices.</p></div>
+<div class="section">
+<h4>Forks of the project codebase<a name="Forks_of_the_project_codebase"></a></h4>
+<p>All code that gets released by the community should have sufficient opertunity for
review both:</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>
+<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>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>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="">Project
Management Chair</a><a name="Project_Management_Chair"></a></h3>
 <p>For various legal reasons, there are certain things that the Apache Software Foundation
can only delegate to an officer of the foundation.</p>
 <p>The Project Management Committee is responsible for nominating the lucky victim
who gets made an officer of the foundation (subject to the approval of the board).</p>
-<p>This person then becomes the interface between the board and the project management
committee. They do not have any other additional gravitas in the project, it is the Project
Management Committee as a whole that is responsible for the direction of the project.</p></div></div>
+<p>This person then becomes the interface between the board and the project management
committee. They do not have any other additional gravitas in the project, it is the Project
Management Committee as a whole that is responsible for the direction of the project.</p>
+<p>If things break down and there is no consensus and there is no clear ability to
reach any conclusion <i>and</i> it is in the interest of the foundation because
damage is done and the board expects the chair to act as an officier of the foundation and
clean things up, then the chair can act as an ultimate decision maker, however, by this point
the board of the foundation must already be well aware of the situation and should be actively
monitoring the chair.</p></div></div>
     <div class="clear">

View raw message