Hi Paul, > then used as a dependency, shouldn't there be a vote on that?
Wouldn't there be a vote for the adoption of any dependency, anyway? Or at least a code review process on the changes that bring in that dependency...? Regards, Curtis On Fri, Aug 2, 2013 at 10:32 AM, Paul Benedict <[email protected]> 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? > > > 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] > > > > > > > > > > > > -- > Cheers, > Paul >
