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.conno...@gmail.com> wrote: > On 2 August 2013 16:07, Brian Fox <bri...@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.conno...@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: <steph...@apache.org> > > > Date: 2 August 2013 10:52 > > > Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/ > > > project-roles.md > > > To: comm...@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:priv...@maven.apache.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > -- Cheers, Paul
