Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (athena.apache.org: domain of paulus.benedictus@gmail.com
 designates 209.85.219.65 as permitted sender)
MIME-Version: 1.0
Sender: paulus.benedictus@gmail.com
In-Reply-To: 
 <CA+nPnMzxSRAn=UpUy2MnNrTY1BtcKBVT+WxFXEdB43BkYK7KXA@mail.gmail.com>
References: 
 <CA+nPnMyvQ6jryMhPSGb-BMkFCF9CwRu_1AiTE92ZLXwp8dPsKQ@mail.gmail.com>
	<CAMk_BeiuT6kg90vPTyWpJyxxSpxqGAC4Ev4Acprijx+PP5n6cA@mail.gmail.com>
	<CA+nPnMzxSRAn=UpUy2MnNrTY1BtcKBVT+WxFXEdB43BkYK7KXA@mail.gmail.com>
Date: Fri, 2 Aug 2013 10:32:10 -0500
Message-ID: 
 <CABLGb9ykPtBM-C7VaMDT-V24-_Y923gUwJ9o=dG+T+yy_Rp3Sw@mail.gmail.com>
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...)
From: Paul Benedict <pbenedict@apache.org>
To: Maven Developers List <dev@maven.apache.org>
Cc: Maven Users List <users@maven.apache.org>
Content-Type: multipart/alternative; boundary=e89a8ff1cc9e85864804e2f8a956

--e89a8ff1cc9e85864804e2f8a956
Content-Type: text/plain; charset=ISO-8859-1

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?


On Fri, Aug 2, 2013 at 10:24 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> On 2 August 2013 16:07, Brian Fox <brianf@infinity.nu> 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
> > <stephen.alan.connolly@gmail.com> 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: <stephenc@apache.org>
> > > Date: 2 August 2013 10:52
> > > Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/
> > > project-roles.md
> > > To: commits@maven.apache.org
> > >
> > >
> > > 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:users@maven.apache.org
> > >    [3]: mailto:private@maven.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>


-- 
Cheers,
Paul

--e89a8ff1cc9e85864804e2f8a956--