maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curtis Rueden <ctrue...@wisc.edu>
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:41:03 GMT
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 <pbenedict@apache.org> 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 <
> 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
>

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