On 02/08/2013 11:32 AM, Paul Benedict wrote:
Furthermore, I'd like to see explicit procedural rules on Maven Core and
forking. For example, if there's a critical component needing development
for Core, and a PMC expresses that such development will be done outside of
Apache and then used as a dependency, shouldn't there be a vote on that?
For what purpose?
You can't stop the person anyway and in the discussion, it is fair to
assume that you would have raised your objections.
The vote will come when a PMC member wants to change the dependency when
the code comes back.
At that point you have the code and you have a chance to see the new
functionality or performance to see if the changes live up to the
advanced billing.
Ron
On Fri, Aug 2, 2013 at 10:24 AM, Stephen Connolly <
[email protected]> wrote:
On 2 August 2013 16:07, Brian Fox <[email protected]> wrote:
I think the bulk of this is pretty good. On the fork section,
specifically:
"
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.
The PMC should encourage by example the early committing of changes from
a
fork back to Apache Maven source control.
"
This seems to want to compel code to be brought back as a
responsibility, I don't think we need to spell that out.
This is why I say "as soon as ... are identified"
The wording could be clearer... if somebody can figure out a better way to
say it.
Basically, as soon as you say something like... "Oh commit 1a2b3d4e, we
really need to get that into Maven itself, it's too good to be in our
fork"... you should be trying to hasten getting that commit into Maven
itself.... and if you are on the PMC and one of your commits is one that
you say this of... you should just commit it back.
Until you realise that a commit is one that you want to push to Maven, hey
it's your work... whatever... but as soon as you identify the change as
being one that should be at Maven, as a PMC member you are expected to try
and get it into Maven quickly so that others working on the fork see that
this is the example by which the PMC leads.
If you can think of a clearer way to express that than my wording (which
since you are not getting my intended meaning must therefore be lacking)
please update.
The section
about the downsides to not doing so and attempting to do it later is
really the core of the concerns... the extra diligence required to
consume large bodies of work is bigger. That doesn't mean that code
contributions are inherently bad just because they were developed
elsewhere, it's just harder to pull in.
Correct.
On Fri, Aug 2, 2013 at 5:59 AM, Stephen Connolly
<[email protected]> wrote:
I have updated the project-roles with my thoughts resulting from the
healthy debate on the list and some debates elsewhere.
If anyone wants to look at the resulting Work In Progress document as a
whole:
http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594&view=markup
Thoughts?
-Stephen
---------- Forwarded message ----------
From: <[email protected]>
Date: 2 August 2013 10:52
Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/
project-roles.md
To: [email protected]
Author: stephenc
Date: Fri Aug 2 09:52:11 2013
New Revision: 1509594
URL: http://svn.apache.org/r1509594
Log:
After a lengthy discussion on the users@maven list and some
side discussions on members@apache, I think the following changes
are more in line with what we should be seeking as responsibilities
of the PMC.
* Forks are not bad... letting changes stack up in the fork is bad
but more from a 'it will be hard to review' point of view...
similarly using a fork to get external contributions complicates
the tracablity
* We are not obligated to promote other ASF projects... but there
should be a symmetry in how that lack of obligation plays out
* I identified some more responsibilities of the PMC (if I have missed
any, please add)
* There is a special case where the PMC Chair can wear the dictators
hat... but that is only in the case of unresolvable consensus
and the lack of consensus is causing damage to the project
and the board is well aware of the issue and expects the chair
to put on the dictators hat (with the board watching on)
As always, this is a Commit Then Review community... so these
changes are being committed for review.
Modified:
maven/site/trunk/content/markdown/project-roles.md
Modified: maven/site/trunk/content/markdown/project-roles.md
URL:
http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1509594&r1=1509593&r2=1509594&view=diff
==============================================================================
--- maven/site/trunk/content/markdown/project-roles.md (original)
+++ maven/site/trunk/content/markdown/project-roles.md Fri Aug 2
09:52:11
2013
@@ -174,11 +174,31 @@ are kept confidential.
The Project Management Committee has the following responsibilities:
-* Proposing active contributors for committership,
-* Binding votes in project decisions,
-* Voting on release artifacts,
-* Ensure [Developers Conventions][5] are followed, or updated/improved
if
necessary,
-* <!-- TODO: get the rest of these -->
+* Active management of those projects identified by the resolution of
the
Board
+ of Directors of the Apache Foundation;
+* 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's Attic)
+* 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;
+* Defend the trademarks belonging to the project;
+* Proposing active contributors for committership;
+* 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;
+* Binding votes in project decisions;
+* 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)
+* Ensure that third part dependencies shipped as part of the project's
releases
+ are covered by a compatible license.
+* Voting on release artifacts;
+* Ensure [Developers Conventions][5] are followed, or updated/improved
if
necessary;
#### Standards for Community Commitment
@@ -186,22 +206,77 @@ In the spirit of supporting the health o
Management Committee members refrain from actions that subvert the
functioning of the committee itself.
-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.
-
-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.
+#### Promotion of other projects
+
+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.
+
+When considering integration of technologies within Maven, there is
+thus no requirement that other Apache projects be picked over
non-Apache
projects.
+
+The primary requirements for picking technologies to integrate with
Maven
+are thus:
+
+* A compatible license, i.e. Category A or Category B
+* A good technical fit
+* A strong preference on behalf of the portion of the community that
+ will be doing the integration.
+
+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.
+
+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.
+
+#### Forks of the project codebase
+
+All code that gets released by the community should have sufficient
opertunity
+for review both:
+
+* By the PMC, to check the legal responsibilities delegated by
+ the Board; and
+* By the committers (which includes the PMC), to check that the
technical
+ direction and quality is in line with the consensus roadmap.
+
+It is self evident that the opertunity for review is much greater if
the
code
+is committed to the project's source control as early as possible.
Similarly
+small commits are easier to review than large commits.
+
+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.
+
+The PMC should encourage by example the early committing of changes
from a
+fork back to Apache Maven source control.
+
+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.
+
+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.
### [Project Management Chair](
http://www.apache.org/foundation/how-it-works.html#pmc-chair)
@@ -217,6 +292,14 @@ the project management committee. They d
additional gravitas in the project, it is the Project Management
Committee as a whole that is responsible for the direction of the
project.
+If things break down and there is no consensus and there is no clear
+ability to reach any conclusion *and* 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.
+
[1]: http://stackoverflow.com/questions/tagged/maven
[2]: mailto:[email protected]
[3]: mailto:[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
