maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curtis Rueden <>
Subject Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Date Fri, 02 Aug 2013 15:08:42 GMT
Hi Stephen,

> If anyone wants to look at the resulting Work In Progress document as
> a whole:
> Thoughts?

Big thumbs up to all your changes. Nice work.

Some brief comments from a technical perspective:

> It is self evident that the opportunity 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.

Technologies like GitHub and Gerrit are making code review extremely easy
these days. I am not sure what tools Apache projects use for code review,
but in the interest of facilitating such review, I definitely believe that
going with the best available *technical* option(s) makes sense, regardless
of whether the tool itself is an Apache project. Use what works.

The old text said: "there is a danger here of falling into a Not Invented
Here mentality" and I couldn't agree more. The new language is much better,
which clearly warns of the consequences of long-running forks while also
stating that they may sometimes be useful and/or appropriate.

> GIT commits can be squashed and history re-written to mask or
> otherwise hide the source of contributions.

True, and it is good to warn about this. However, ultimately I think Git is
a better choice (than SVN) because it often makes code review much easier.
If a new feature is properly developed on a topic branch with commits
squashed, rewritten and organized as needed, the history can be laid out in
a very easy-to-understand manner: new features and bugfixes done in
properly isolated commits, unit tests added immediately thereafter, etc. If
a commit is too large or conflates many different changes, Git provides the
tools to split up that work for rereview.

Again, thanks for writing this. The new words give me more confidence that
Apache has the community's best interest at heart, rather than only "Apache
for Apache's sake."


P.S. For those interested, Stephen's changes are more clear when reading
the side-by-side diff:

On Fri, Aug 2, 2013 at 4:59 AM, Stephen Connolly <> 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:
> Thoughts?
> -Stephen
> ---------- Forwarded message ----------
> From: <>
> Date: 2 August 2013 10:52
> Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/
> To:
> Author: stephenc
> Date: Fri Aug  2 09:52:11 2013
> New Revision: 1509594
> URL:
> 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/
> Modified: maven/site/trunk/content/markdown/
> URL:
> ==============================================================================
> --- maven/site/trunk/content/markdown/ (original)
> +++ maven/site/trunk/content/markdown/ 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](
> @@ -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]:
>    [2]:
>    [3]:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message