[DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)

[Stephen Connolly <st...@gmail.com>]

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: <st...@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

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...)

[Brian Fox <br...@infinity.nu>]

Yes, I will take a pass tonight.

On Mon, Aug 5, 2013 at 6:55 AM, Stephen Connolly
<st...@gmail.com> wrote:
> Brian,
>
> Did you have any suggested changes to the forks section wording to clear up
> my intent for that section?
>
> I'd like to start wrapping this up and move towards making it "official"
>
> Everyone else,
>
> Time to shout out if you have any issues / suggested improvements on the
> content
>
> - Stephen
>
> On Friday, 2 August 2013, Stephen Connolly wrote:
>
>> On 2 August 2013 16:07, Brian Fox <brianf@infinity.nu <javascript:_e({},
>> 'cvml', '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
>> <st...@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: <st...@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
>>
>>
>>
>
> --
> Sent from my phone

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

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...)

[Baptiste MATHUS <bm...@batmat.net>]

Some small formating or typos.
Added commas in a long sentence around line 280 and another one around
l298. I generally find it hard to concentrate on a whole sentence without
commas (or even periods separating ideas).
See https://gist.github.com/Batmat/6155302 for proposed patch.
If you need any other attachment format, just let me know.

Cheers


2013/8/5 Stephen Connolly <st...@gmail.com>

> Brian,
>
> Did you have any suggested changes to the forks section wording to clear up
> my intent for that section?
>
> I'd like to start wrapping this up and move towards making it "official"
>
> Everyone else,
>
> Time to shout out if you have any issues / suggested improvements on the
> content
>
> - Stephen
>
> On Friday, 2 August 2013, Stephen Connolly wrote:
>
> > On 2 August 2013 16:07, Brian Fox <brianf@infinity.nu <javascript:_e({},
> > 'cvml', '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
> > <st...@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: <st...@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
> >
> >
> >
>
> --
> Sent from my phone
>



-- 
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

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...)

[Brian Fox <br...@infinity.nu>]

Yes, I will take a pass tonight.

On Mon, Aug 5, 2013 at 6:55 AM, Stephen Connolly
<st...@gmail.com> wrote:
> Brian,
>
> Did you have any suggested changes to the forks section wording to clear up
> my intent for that section?
>
> I'd like to start wrapping this up and move towards making it "official"
>
> Everyone else,
>
> Time to shout out if you have any issues / suggested improvements on the
> content
>
> - Stephen
>
> On Friday, 2 August 2013, Stephen Connolly wrote:
>
>> On 2 August 2013 16:07, Brian Fox <brianf@infinity.nu <javascript:_e({},
>> 'cvml', '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
>> <st...@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: <st...@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
>>
>>
>>
>
> --
> Sent from my phone

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

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...)

[Baptiste MATHUS <bm...@batmat.net>]

Some small formating or typos.
Added commas in a long sentence around line 280 and another one around
l298. I generally find it hard to concentrate on a whole sentence without
commas (or even periods separating ideas).
See https://gist.github.com/Batmat/6155302 for proposed patch.
If you need any other attachment format, just let me know.

Cheers


2013/8/5 Stephen Connolly <st...@gmail.com>

> Brian,
>
> Did you have any suggested changes to the forks section wording to clear up
> my intent for that section?
>
> I'd like to start wrapping this up and move towards making it "official"
>
> Everyone else,
>
> Time to shout out if you have any issues / suggested improvements on the
> content
>
> - Stephen
>
> On Friday, 2 August 2013, Stephen Connolly wrote:
>
> > On 2 August 2013 16:07, Brian Fox <brianf@infinity.nu <javascript:_e({},
> > 'cvml', '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
> > <st...@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: <st...@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
> >
> >
> >
>
> --
> Sent from my phone
>



-- 
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

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...)

[Stephen Connolly <st...@gmail.com>]

Brian,

Did you have any suggested changes to the forks section wording to clear up
my intent for that section?

I'd like to start wrapping this up and move towards making it "official"

Everyone else,

Time to shout out if you have any issues / suggested improvements on the
content

- Stephen

On Friday, 2 August 2013, Stephen Connolly wrote:

> On 2 August 2013 16:07, Brian Fox <brianf@infinity.nu <javascript:_e({},
> 'cvml', '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
> <st...@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: <st...@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
>
>
>

-- 
Sent from my phone

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...)

[Stephen Connolly <st...@gmail.com>]

Brian,

Did you have any suggested changes to the forks section wording to clear up
my intent for that section?

I'd like to start wrapping this up and move towards making it "official"

Everyone else,

Time to shout out if you have any issues / suggested improvements on the
content

- Stephen

On Friday, 2 August 2013, Stephen Connolly wrote:

> On 2 August 2013 16:07, Brian Fox <brianf@infinity.nu <javascript:_e({},
> 'cvml', '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
> <st...@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: <st...@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
>
>
>

-- 
Sent from my phone

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...)

[Brian Fox <br...@infinity.nu>]

On Aug 2, 2013, at 12:30 PM, Paul Benedict <pb...@apache.org> wrote:

> I've stated from the beginning of this thread that it's impossible to
> prevent someone from developing outside of Apache. I stand by that still.
> That can't be prevented and any attempt will fail since it's not practical.
>
> If my words today aren't clear, I'll try again. My stance isn't about
> halting developing elsewhere, but to halt what I (and maybe some others)
> perceive as a way of getting around the Apache community.
>
> I won't use your "ultra whizzbang high performance logging" :-) example
> because it doesn't fit what my concern; but imagine an existing component
> (I won't name any) that is critical and Maven's existence and Maven can't
> function without it. It's very easy for any PMC member to go to another OSS
> community, develop it, and then kind of leave the other PMCs with no real
> "choice" but to use it because the code realizes the future of Maven. Those
> other PMCs are really backed into a corner; they have no real recourse to
> preventing this, lest Maven development is simply halted altogether. The
> other OSS community has other committers, other mailing lists, other
> deliberations, etc. Community work and input becomes marginalized here.
>
> Does this make sense to you? That kind of community-splitting effort needs
> to stop and that's what I am trying to address.


The cat b / core pmc rule was already adopted to address cases like
this. The pmc voted to allow the previous cases so its not like
anything magical happened here. I don't think we need to be overly
broad to spell out every operating rule in the roles and
responsibilities. Keeping tabs on situations like that is exactly the
role of the pmc and I believe the document covers that sufficiently.

>
> Cheers,
> Paul
>
>
>
> On Fri, Aug 2, 2013 at 11:10 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> We cannot stop somebody from developing something outside of Apache.
>>
>> So I could go off and write a High Performance Logging API... now I could
>> be doing that because I want to foist that Logging API on Maven... or I
>> could be doing it as an experiment that, if successful, I may offer for
>> Maven to consume... or I could be doing it because I need it for my Day
>> Job...
>>
>> We cannot know the reasons why somebody is doing something outside of
>> Maven... we can ask, but we cannot *know* if the answer we are given is
>> truthful.
>>
>> So anyway, I now have this ultra whizzbang high performance logging API and
>> I am aware of some deficit in the logging performance of Maven, so I spin
>> up a private fork (it could be a hidden private fork, or it could be a
>> public one... doesn't matter) and integrate the logging API and low and
>> behold I see a whopping X% improvement... so I want to bring that back to
>> Maven...
>>
>> Is there anything wrong with the above?
>>
>> If the library I created is under a Category A license and open source and
>> I go with CTR and nobody vetos my commit... we have consensus... why do we
>> need to go all Iron Fist and require a vote?
>>
>> We already have established tools: review of commits, vetos on commits,
>> mandatory votes for Category B dependencies...
>>
>> Do we really need *more* processes and procedures to follow?
>>
>> On 2 August 2013 16:51, Paul Benedict <pb...@apache.org> wrote:
>>
>>> I don't understand the iron hand analogy. I was expressing the use of a
>>> vote to allow or disallow critical development outside of Apache. The
>> vote
>>> would lead to a consensus, no?
>>>
>>>
>>> On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>>> On 2 August 2013 16:32, Paul Benedict <pb...@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?
>>>>
>>>> Votes should be a tool to confirm consensus... not an iron hand.
>>>>
>>>> If the consensus of the developers is to use the dependency which is
>>>> external to the project, then that is fine. If there is no consensus
>> then
>>>> the dependency will not be introduced.
>>>>
>>>> We already have a policy that adding Category B dependencies to Core
>>>> requires approval of the PMC, I don't see that there is much value in
>>>> adding even more to this document... but if you can suggest a patch and
>>>> people agree with it...
>>>>
>>>> -Stephen
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Paul
>
>
>
> --
> Cheers,
> Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

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...)

[Ron Wheeler <rw...@artifact-software.com>]

On 02/08/2013 12:29 PM, Paul Benedict wrote:
> I've stated from the beginning of this thread that it's impossible to
> prevent someone from developing outside of Apache. I stand by that still.
> That can't be prevented and any attempt will fail since it's not practical.
>
> If my words today aren't clear, I'll try again. My stance isn't about
> halting developing elsewhere, but to halt what I (and maybe some others)
> perceive as a way of getting around the Apache community.
>
> I won't use your "ultra whizzbang high performance logging" :-) example
> because it doesn't fit what my concern; but imagine an existing component
> (I won't name any) that is critical and Maven's existence and Maven can't
> function without it. It's very easy for any PMC member to go to another OSS
> community, develop it, and then kind of leave the other PMCs with no real
> "choice" but to use it because the code realizes the future of Maven. Those
> other PMCs are really backed into a corner; they have no real recourse to
> preventing this, lest Maven development is simply halted altogether. The
> other OSS community has other committers, other mailing lists, other
> deliberations, etc. Community work and input becomes marginalized here.
>
> Does this make sense to you? That kind of community-splitting effort needs
> to stop and that's what I am trying to address.
The Maven group can always port the code back into the Maven project if 
the other project is OSS.
If it has gone to a proprietary project (lots of open source stuff goes 
that way too), then the Apache maven team will have to invent its own 
future to be better or the same as the alternative future.

Not sure how this could happen in real life.
It sounds like the "future of Maven" resided in the head of one person 
who felt that the Apache Maven project did not have room for its own 
future so he moved on to a team that wanted to make the "future" happen now.

That would appear to be a good thing for Maven users.
The users adopt to this new project and enjoy the future.

The Apache project members who see the "future" as a good thing move to 
the new group and the people who did not want to support the "future" 
keep supporting the old way.

This would not be the first project that died rather than innovate.

You can't write a policy that protects against this and still stays open 
source.
You have no way to stop this from happening nor should you try.


Ron

> Cheers,
> Paul
>
>
>
> On Fri, Aug 2, 2013 at 11:10 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> We cannot stop somebody from developing something outside of Apache.
>>
>> So I could go off and write a High Performance Logging API... now I could
>> be doing that because I want to foist that Logging API on Maven... or I
>> could be doing it as an experiment that, if successful, I may offer for
>> Maven to consume... or I could be doing it because I need it for my Day
>> Job...
>>
>> We cannot know the reasons why somebody is doing something outside of
>> Maven... we can ask, but we cannot *know* if the answer we are given is
>> truthful.
>>
>> So anyway, I now have this ultra whizzbang high performance logging API and
>> I am aware of some deficit in the logging performance of Maven, so I spin
>> up a private fork (it could be a hidden private fork, or it could be a
>> public one... doesn't matter) and integrate the logging API and low and
>> behold I see a whopping X% improvement... so I want to bring that back to
>> Maven...
>>
>> Is there anything wrong with the above?
>>
>> If the library I created is under a Category A license and open source and
>> I go with CTR and nobody vetos my commit... we have consensus... why do we
>> need to go all Iron Fist and require a vote?
>>
>> We already have established tools: review of commits, vetos on commits,
>> mandatory votes for Category B dependencies...
>>
>> Do we really need *more* processes and procedures to follow?
>>
>> On 2 August 2013 16:51, Paul Benedict <pb...@apache.org> wrote:
>>
>>> I don't understand the iron hand analogy. I was expressing the use of a
>>> vote to allow or disallow critical development outside of Apache. The
>> vote
>>> would lead to a consensus, no?
>>>
>>>
>>> On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>>> On 2 August 2013 16:32, Paul Benedict <pb...@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?
>>>> Votes should be a tool to confirm consensus... not an iron hand.
>>>>
>>>> If the consensus of the developers is to use the dependency which is
>>>> external to the project, then that is fine. If there is no consensus
>> then
>>>> the dependency will not be introduced.
>>>>
>>>> We already have a policy that adding Category B dependencies to Core
>>>> requires approval of the PMC, I don't see that there is much value in
>>>> adding even more to this document... but if you can suggest a patch and
>>>> people agree with it...
>>>>
>>>> -Stephen
>>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Paul
>>>
>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

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...)

[Fred Cooke <fr...@gmail.com>]

Thanks for the terms. I had used "apache license categories" and some other
variations.

I assume you mean this:
http://www.apache.org/legal/3party.html#criteriaandcategories

If so, is there an accepted version, other than this merely proposed
version?

Fred.

On Fri, Aug 2, 2013 at 7:39 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> Google: Apache third party licenses
>
> Should work on lucky... Or look at the head revision where I added the
> link.
>
> There is a 3rd category: Category X... Eg GPL, which we are not allowed to
> use
>
> On Friday, 2 August 2013, Fred Cooke wrote:
>
> > Are definitions of cat A and  B and others listed anywhere? I searched
> but
> > failed.
> >
> > I assume Cat A = permissive and Cat B = copyleft? or?
> >
> > On Fri, Aug 2, 2013 at 6:54 PM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> > > Correct. And it would be subject to the same CTR and potential veto if
> > Cat
> > > A. If Cat B and being added to core then you'd have a mandatory vote by
> > the
> > > PMC where the majority *of the whole PMC* are required to approve.
> > >
> > > The rational being, a Cat A licensed dependency can always be forked
> into
> > > Maven if we need to.
> > >
> > > On Friday, 2 August 2013, Igor Fedorenko wrote:
> > >
> > > > Is this really specific to PMC? Can't a regular developer like myself
> > do
> > > > the same, i.e. setup a project elsewhere, then commit <dependency> to
> > > > maven core?
> > > >
> > > > --
> > > > Regards,
> > > > Igor
> > > >
> > > > On 2013-08-02 8:29 PM, Paul Benedict wrote:
> > > >
> > > > I've stated from the beginning of this thread that it's impossible to
> > > > prevent someone from developing outside of Apache. I stand by that
> > still.
> > > > That can't be prevented and any attempt will fail since it's not
> > > practical.
> > > >
> > > > If my words today aren't clear, I'll try again. My stance isn't about
> > > > halting developing elsewhere, but to halt what I (and maybe some
> > others)
> > > > perceive as a way of getting around the Apache community.
> > > >
> > > > I won't use your "ultra whizzbang high performance logging" :-)
> example
> > > > because it doesn't fit what my concern; but imagine an existing
> > component
> > > > (I won't name any) that is critical and Maven's existence and Maven
> > can't
> > > > function without it. It's very easy for any PMC member to go to
> another
> > > OSS
> > > > community, develop it, and then kind of leave the other PMCs with no
> > real
> > > > "choice" but to use it because the code realizes the future of Maven.
> > > Those
> > > > other PMCs are really backed into a corner; they have no real
> recourse
> > to
> > > > preventing this, lest Maven development is simply halted altogether.
> > The
> > > > other OSS community has other committers, other mailing lists, other
> > > > deliberations, etc. Community work and input becomes marginalized
> here.
> > > >
> > > > Does this make sense to you? That kind of community-splitting effort
> > > needs
> > > > to stop and that's what I am trying to address.
> > > >
> > > > Cheers,
> > > > Paul
> > > >
> > > >
> > > >
> > > > On Fri, Aug 2, 2013 at 11:10 AM, Stephen Connolly <
> > > > stephen.alan.connolly@gmail.com> wrote:
> > > >
> > > >  We cannot stop somebody from developing something outside of Apache.
> > > >
> > > > So I could go off and write a High Performance Logging API... now I
> > could
> > > > be doing that because I want to foist that Logging API on Maven...
> or I
> > > > could be doing it as an experiment that, if successful, I may offer
> for
> > > > Maven to consume... or I could be doing it because I need it for my
> Day
> > > > Job...
> > > >
> > > > We cannot know the reasons why somebody is doing something outside of
> > > > Maven... we can ask, but we cannot *know* if the answer we are given
> is
> > > > truthful.
> > > >
> > > > So anyway, I now have this ultra whizzbang high performance logging
> API
> > > and
> > > > I am aware of some deficit in the logging performance of Maven, so I
> > spin
> > > > up a private fork (it could be a hidden private fork, or it could be
> a
> > > > public one... doesn't matter) and integrate the logging API and low
> and
> > > > behold I see a whopping X% improvement... so I want to bring that
> back
> > to
> > > > Maven...
> > > >
> > > > Is there anything wrong with the above?
> > > >
> > > > If the library I created is under a Category A license and open
> source
> > > and
> > > > I go with CTR and nobody vetos my commit... we have consensus... why
> do
> > > we
> > > > need to go all Iron Fist and require a vote?
> > > >
> > > > We already have established tools: review of commits, vetos on
> commits,
> > > > mandatory votes for Category B dependencies...
> > > >
> > > > Do we really need *more* processes and procedures to follow?
> > > >
> > > > On 2 August 2013 16:51, Paul Benedict <pb...@apache.org> wrote:
> > > >
> > > >  I don't under> >
> > ------------------------------**------------------------------**---------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> <javascript:;>
> > > > For additional commands, e-mail: dev-help@maven.apache.org
> <javascript:;>
> > > >
> > > >
> > >
> > > --
> > > Sent from my phone
> > >
> >
>
>
> --
> Sent from my phone
>

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...)

[Stephen Connolly <st...@gmail.com>]

Google: Apache third party licenses

Should work on lucky... Or look at the head revision where I added the link.

There is a 3rd category: Category X... Eg GPL, which we are not allowed to
use

On Friday, 2 August 2013, Fred Cooke wrote:

> Are definitions of cat A and  B and others listed anywhere? I searched but
> failed.
>
> I assume Cat A = permissive and Cat B = copyleft? or?
>
> On Fri, Aug 2, 2013 at 6:54 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > Correct. And it would be subject to the same CTR and potential veto if
> Cat
> > A. If Cat B and being added to core then you'd have a mandatory vote by
> the
> > PMC where the majority *of the whole PMC* are required to approve.
> >
> > The rational being, a Cat A licensed dependency can always be forked into
> > Maven if we need to.
> >
> > On Friday, 2 August 2013, Igor Fedorenko wrote:
> >
> > > Is this really specific to PMC? Can't a regular developer like myself
> do
> > > the same, i.e. setup a project elsewhere, then commit <dependency> to
> > > maven core?
> > >
> > > --
> > > Regards,
> > > Igor
> > >
> > > On 2013-08-02 8:29 PM, Paul Benedict wrote:
> > >
> > > I've stated from the beginning of this thread that it's impossible to
> > > prevent someone from developing outside of Apache. I stand by that
> still.
> > > That can't be prevented and any attempt will fail since it's not
> > practical.
> > >
> > > If my words today aren't clear, I'll try again. My stance isn't about
> > > halting developing elsewhere, but to halt what I (and maybe some
> others)
> > > perceive as a way of getting around the Apache community.
> > >
> > > I won't use your "ultra whizzbang high performance logging" :-) example
> > > because it doesn't fit what my concern; but imagine an existing
> component
> > > (I won't name any) that is critical and Maven's existence and Maven
> can't
> > > function without it. It's very easy for any PMC member to go to another
> > OSS
> > > community, develop it, and then kind of leave the other PMCs with no
> real
> > > "choice" but to use it because the code realizes the future of Maven.
> > Those
> > > other PMCs are really backed into a corner; they have no real recourse
> to
> > > preventing this, lest Maven development is simply halted altogether.
> The
> > > other OSS community has other committers, other mailing lists, other
> > > deliberations, etc. Community work and input becomes marginalized here.
> > >
> > > Does this make sense to you? That kind of community-splitting effort
> > needs
> > > to stop and that's what I am trying to address.
> > >
> > > Cheers,
> > > Paul
> > >
> > >
> > >
> > > On Fri, Aug 2, 2013 at 11:10 AM, Stephen Connolly <
> > > stephen.alan.connolly@gmail.com> wrote:
> > >
> > >  We cannot stop somebody from developing something outside of Apache.
> > >
> > > So I could go off and write a High Performance Logging API... now I
> could
> > > be doing that because I want to foist that Logging API on Maven... or I
> > > could be doing it as an experiment that, if successful, I may offer for
> > > Maven to consume... or I could be doing it because I need it for my Day
> > > Job...
> > >
> > > We cannot know the reasons why somebody is doing something outside of
> > > Maven... we can ask, but we cannot *know* if the answer we are given is
> > > truthful.
> > >
> > > So anyway, I now have this ultra whizzbang high performance logging API
> > and
> > > I am aware of some deficit in the logging performance of Maven, so I
> spin
> > > up a private fork (it could be a hidden private fork, or it could be a
> > > public one... doesn't matter) and integrate the logging API and low and
> > > behold I see a whopping X% improvement... so I want to bring that back
> to
> > > Maven...
> > >
> > > Is there anything wrong with the above?
> > >
> > > If the library I created is under a Category A license and open source
> > and
> > > I go with CTR and nobody vetos my commit... we have consensus... why do
> > we
> > > need to go all Iron Fist and require a vote?
> > >
> > > We already have established tools: review of commits, vetos on commits,
> > > mandatory votes for Category B dependencies...
> > >
> > > Do we really need *more* processes and procedures to follow?
> > >
> > > On 2 August 2013 16:51, Paul Benedict <pb...@apache.org> wrote:
> > >
> > >  I don't under> >
> ------------------------------**------------------------------**---------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org<javascript:;>
> > > For additional commands, e-mail: dev-help@maven.apache.org<javascript:;>
> > >
> > >
> >
> > --
> > Sent from my phone
> >
>


-- 
Sent from my phone

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...)

[Fred Cooke <fr...@gmail.com>]

Are definitions of cat A and  B and others listed anywhere? I searched but
failed.

I assume Cat A = permissive and Cat B = copyleft? or?

On Fri, Aug 2, 2013 at 6:54 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> Correct. And it would be subject to the same CTR and potential veto if Cat
> A. If Cat B and being added to core then you'd have a mandatory vote by the
> PMC where the majority *of the whole PMC* are required to approve.
>
> The rational being, a Cat A licensed dependency can always be forked into
> Maven if we need to.
>
> On Friday, 2 August 2013, Igor Fedorenko wrote:
>
> > Is this really specific to PMC? Can't a regular developer like myself do
> > the same, i.e. setup a project elsewhere, then commit <dependency> to
> > maven core?
> >
> > --
> > Regards,
> > Igor
> >
> > On 2013-08-02 8:29 PM, Paul Benedict wrote:
> >
> > I've stated from the beginning of this thread that it's impossible to
> > prevent someone from developing outside of Apache. I stand by that still.
> > That can't be prevented and any attempt will fail since it's not
> practical.
> >
> > If my words today aren't clear, I'll try again. My stance isn't about
> > halting developing elsewhere, but to halt what I (and maybe some others)
> > perceive as a way of getting around the Apache community.
> >
> > I won't use your "ultra whizzbang high performance logging" :-) example
> > because it doesn't fit what my concern; but imagine an existing component
> > (I won't name any) that is critical and Maven's existence and Maven can't
> > function without it. It's very easy for any PMC member to go to another
> OSS
> > community, develop it, and then kind of leave the other PMCs with no real
> > "choice" but to use it because the code realizes the future of Maven.
> Those
> > other PMCs are really backed into a corner; they have no real recourse to
> > preventing this, lest Maven development is simply halted altogether. The
> > other OSS community has other committers, other mailing lists, other
> > deliberations, etc. Community work and input becomes marginalized here.
> >
> > Does this make sense to you? That kind of community-splitting effort
> needs
> > to stop and that's what I am trying to address.
> >
> > Cheers,
> > Paul
> >
> >
> >
> > On Fri, Aug 2, 2013 at 11:10 AM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> >  We cannot stop somebody from developing something outside of Apache.
> >
> > So I could go off and write a High Performance Logging API... now I could
> > be doing that because I want to foist that Logging API on Maven... or I
> > could be doing it as an experiment that, if successful, I may offer for
> > Maven to consume... or I could be doing it because I need it for my Day
> > Job...
> >
> > We cannot know the reasons why somebody is doing something outside of
> > Maven... we can ask, but we cannot *know* if the answer we are given is
> > truthful.
> >
> > So anyway, I now have this ultra whizzbang high performance logging API
> and
> > I am aware of some deficit in the logging performance of Maven, so I spin
> > up a private fork (it could be a hidden private fork, or it could be a
> > public one... doesn't matter) and integrate the logging API and low and
> > behold I see a whopping X% improvement... so I want to bring that back to
> > Maven...
> >
> > Is there anything wrong with the above?
> >
> > If the library I created is under a Category A license and open source
> and
> > I go with CTR and nobody vetos my commit... we have consensus... why do
> we
> > need to go all Iron Fist and require a vote?
> >
> > We already have established tools: review of commits, vetos on commits,
> > mandatory votes for Category B dependencies...
> >
> > Do we really need *more* processes and procedures to follow?
> >
> > On 2 August 2013 16:51, Paul Benedict <pb...@apache.org> wrote:
> >
> >  I don't understand the iron hand analogy. I was expressing the use of a
> > vote to allow or disallow critical development outside of Apache. The
> >
> > vote
> >
> > would lead to a consensus, no?
> >
> >
> > On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> >  On 2 August 2013 16:32, Paul Benedict <pb...@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
> >
> > ------------------------------**------------------------------**---------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> --
> Sent from my phone
>

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...)

[Stephen Connolly <st...@gmail.com>]

Correct. And it would be subject to the same CTR and potential veto if Cat
A. If Cat B and being added to core then you'd have a mandatory vote by the
PMC where the majority *of the whole PMC* are required to approve.

The rational being, a Cat A licensed dependency can always be forked into
Maven if we need to.

On Friday, 2 August 2013, Igor Fedorenko wrote:

> Is this really specific to PMC? Can't a regular developer like myself do
> the same, i.e. setup a project elsewhere, then commit <dependency> to
> maven core?
>
> --
> Regards,
> Igor
>
> On 2013-08-02 8:29 PM, Paul Benedict wrote:
>
> I've stated from the beginning of this thread that it's impossible to
> prevent someone from developing outside of Apache. I stand by that still.
> That can't be prevented and any attempt will fail since it's not practical.
>
> If my words today aren't clear, I'll try again. My stance isn't about
> halting developing elsewhere, but to halt what I (and maybe some others)
> perceive as a way of getting around the Apache community.
>
> I won't use your "ultra whizzbang high performance logging" :-) example
> because it doesn't fit what my concern; but imagine an existing component
> (I won't name any) that is critical and Maven's existence and Maven can't
> function without it. It's very easy for any PMC member to go to another OSS
> community, develop it, and then kind of leave the other PMCs with no real
> "choice" but to use it because the code realizes the future of Maven. Those
> other PMCs are really backed into a corner; they have no real recourse to
> preventing this, lest Maven development is simply halted altogether. The
> other OSS community has other committers, other mailing lists, other
> deliberations, etc. Community work and input becomes marginalized here.
>
> Does this make sense to you? That kind of community-splitting effort needs
> to stop and that's what I am trying to address.
>
> Cheers,
> Paul
>
>
>
> On Fri, Aug 2, 2013 at 11:10 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>  We cannot stop somebody from developing something outside of Apache.
>
> So I could go off and write a High Performance Logging API... now I could
> be doing that because I want to foist that Logging API on Maven... or I
> could be doing it as an experiment that, if successful, I may offer for
> Maven to consume... or I could be doing it because I need it for my Day
> Job...
>
> We cannot know the reasons why somebody is doing something outside of
> Maven... we can ask, but we cannot *know* if the answer we are given is
> truthful.
>
> So anyway, I now have this ultra whizzbang high performance logging API and
> I am aware of some deficit in the logging performance of Maven, so I spin
> up a private fork (it could be a hidden private fork, or it could be a
> public one... doesn't matter) and integrate the logging API and low and
> behold I see a whopping X% improvement... so I want to bring that back to
> Maven...
>
> Is there anything wrong with the above?
>
> If the library I created is under a Category A license and open source and
> I go with CTR and nobody vetos my commit... we have consensus... why do we
> need to go all Iron Fist and require a vote?
>
> We already have established tools: review of commits, vetos on commits,
> mandatory votes for Category B dependencies...
>
> Do we really need *more* processes and procedures to follow?
>
> On 2 August 2013 16:51, Paul Benedict <pb...@apache.org> wrote:
>
>  I don't understand the iron hand analogy. I was expressing the use of a
> vote to allow or disallow critical development outside of Apache. The
>
> vote
>
> would lead to a consensus, no?
>
>
> On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>  On 2 August 2013 16:32, Paul Benedict <pb...@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
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

-- 
Sent from my phone

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...)

[Igor Fedorenko <ig...@ifedorenko.com>]

Is this really specific to PMC? Can't a regular developer like myself do
the same, i.e. setup a project elsewhere, then commit <dependency> to
maven core?

--
Regards,
Igor

On 2013-08-02 8:29 PM, Paul Benedict wrote:
> I've stated from the beginning of this thread that it's impossible to
> prevent someone from developing outside of Apache. I stand by that still.
> That can't be prevented and any attempt will fail since it's not practical.
>
> If my words today aren't clear, I'll try again. My stance isn't about
> halting developing elsewhere, but to halt what I (and maybe some others)
> perceive as a way of getting around the Apache community.
>
> I won't use your "ultra whizzbang high performance logging" :-) example
> because it doesn't fit what my concern; but imagine an existing component
> (I won't name any) that is critical and Maven's existence and Maven can't
> function without it. It's very easy for any PMC member to go to another OSS
> community, develop it, and then kind of leave the other PMCs with no real
> "choice" but to use it because the code realizes the future of Maven. Those
> other PMCs are really backed into a corner; they have no real recourse to
> preventing this, lest Maven development is simply halted altogether. The
> other OSS community has other committers, other mailing lists, other
> deliberations, etc. Community work and input becomes marginalized here.
>
> Does this make sense to you? That kind of community-splitting effort needs
> to stop and that's what I am trying to address.
>
> Cheers,
> Paul
>
>
>
> On Fri, Aug 2, 2013 at 11:10 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> We cannot stop somebody from developing something outside of Apache.
>>
>> So I could go off and write a High Performance Logging API... now I could
>> be doing that because I want to foist that Logging API on Maven... or I
>> could be doing it as an experiment that, if successful, I may offer for
>> Maven to consume... or I could be doing it because I need it for my Day
>> Job...
>>
>> We cannot know the reasons why somebody is doing something outside of
>> Maven... we can ask, but we cannot *know* if the answer we are given is
>> truthful.
>>
>> So anyway, I now have this ultra whizzbang high performance logging API and
>> I am aware of some deficit in the logging performance of Maven, so I spin
>> up a private fork (it could be a hidden private fork, or it could be a
>> public one... doesn't matter) and integrate the logging API and low and
>> behold I see a whopping X% improvement... so I want to bring that back to
>> Maven...
>>
>> Is there anything wrong with the above?
>>
>> If the library I created is under a Category A license and open source and
>> I go with CTR and nobody vetos my commit... we have consensus... why do we
>> need to go all Iron Fist and require a vote?
>>
>> We already have established tools: review of commits, vetos on commits,
>> mandatory votes for Category B dependencies...
>>
>> Do we really need *more* processes and procedures to follow?
>>
>> On 2 August 2013 16:51, Paul Benedict <pb...@apache.org> wrote:
>>
>>> I don't understand the iron hand analogy. I was expressing the use of a
>>> vote to allow or disallow critical development outside of Apache. The
>> vote
>>> would lead to a consensus, no?
>>>
>>>
>>> On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>>> On 2 August 2013 16:32, Paul Benedict <pb...@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?
>>>>>
>>>>
>>>> Votes should be a tool to confirm consensus... not an iron hand.
>>>>
>>>> If the consensus of the developers is to use the dependency which is
>>>> external to the project, then that is fine. If there is no consensus
>> then
>>>> the dependency will not be introduced.
>>>>
>>>> We already have a policy that adding Category B dependencies to Core
>>>> requires approval of the PMC, I don't see that there is much value in
>>>> adding even more to this document... but if you can suggest a patch and
>>>> people agree with it...
>>>>
>>>> -Stephen
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Paul
>>>
>>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

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...)

[Brian Fox <br...@infinity.nu>]

On Aug 2, 2013, at 12:30 PM, Paul Benedict <pb...@apache.org> wrote:

> I've stated from the beginning of this thread that it's impossible to
> prevent someone from developing outside of Apache. I stand by that still.
> That can't be prevented and any attempt will fail since it's not practical.
>
> If my words today aren't clear, I'll try again. My stance isn't about
> halting developing elsewhere, but to halt what I (and maybe some others)
> perceive as a way of getting around the Apache community.
>
> I won't use your "ultra whizzbang high performance logging" :-) example
> because it doesn't fit what my concern; but imagine an existing component
> (I won't name any) that is critical and Maven's existence and Maven can't
> function without it. It's very easy for any PMC member to go to another OSS
> community, develop it, and then kind of leave the other PMCs with no real
> "choice" but to use it because the code realizes the future of Maven. Those
> other PMCs are really backed into a corner; they have no real recourse to
> preventing this, lest Maven development is simply halted altogether. The
> other OSS community has other committers, other mailing lists, other
> deliberations, etc. Community work and input becomes marginalized here.
>
> Does this make sense to you? That kind of community-splitting effort needs
> to stop and that's what I am trying to address.


The cat b / core pmc rule was already adopted to address cases like
this. The pmc voted to allow the previous cases so its not like
anything magical happened here. I don't think we need to be overly
broad to spell out every operating rule in the roles and
responsibilities. Keeping tabs on situations like that is exactly the
role of the pmc and I believe the document covers that sufficiently.

>
> Cheers,
> Paul
>
>
>
> On Fri, Aug 2, 2013 at 11:10 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> We cannot stop somebody from developing something outside of Apache.
>>
>> So I could go off and write a High Performance Logging API... now I could
>> be doing that because I want to foist that Logging API on Maven... or I
>> could be doing it as an experiment that, if successful, I may offer for
>> Maven to consume... or I could be doing it because I need it for my Day
>> Job...
>>
>> We cannot know the reasons why somebody is doing something outside of
>> Maven... we can ask, but we cannot *know* if the answer we are given is
>> truthful.
>>
>> So anyway, I now have this ultra whizzbang high performance logging API and
>> I am aware of some deficit in the logging performance of Maven, so I spin
>> up a private fork (it could be a hidden private fork, or it could be a
>> public one... doesn't matter) and integrate the logging API and low and
>> behold I see a whopping X% improvement... so I want to bring that back to
>> Maven...
>>
>> Is there anything wrong with the above?
>>
>> If the library I created is under a Category A license and open source and
>> I go with CTR and nobody vetos my commit... we have consensus... why do we
>> need to go all Iron Fist and require a vote?
>>
>> We already have established tools: review of commits, vetos on commits,
>> mandatory votes for Category B dependencies...
>>
>> Do we really need *more* processes and procedures to follow?
>>
>> On 2 August 2013 16:51, Paul Benedict <pb...@apache.org> wrote:
>>
>>> I don't understand the iron hand analogy. I was expressing the use of a
>>> vote to allow or disallow critical development outside of Apache. The
>> vote
>>> would lead to a consensus, no?
>>>
>>>
>>> On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly <
>>> stephen.alan.connolly@gmail.com> wrote:
>>>
>>>> On 2 August 2013 16:32, Paul Benedict <pb...@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?
>>>>
>>>> Votes should be a tool to confirm consensus... not an iron hand.
>>>>
>>>> If the consensus of the developers is to use the dependency which is
>>>> external to the project, then that is fine. If there is no consensus
>> then
>>>> the dependency will not be introduced.
>>>>
>>>> We already have a policy that adding Category B dependencies to Core
>>>> requires approval of the PMC, I don't see that there is much value in
>>>> adding even more to this document... but if you can suggest a patch and
>>>> people agree with it...
>>>>
>>>> -Stephen
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Paul
>
>
>
> --
> Cheers,
> Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

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...)

[Paul Benedict <pb...@apache.org>]

I've stated from the beginning of this thread that it's impossible to
prevent someone from developing outside of Apache. I stand by that still.
That can't be prevented and any attempt will fail since it's not practical.

If my words today aren't clear, I'll try again. My stance isn't about
halting developing elsewhere, but to halt what I (and maybe some others)
perceive as a way of getting around the Apache community.

I won't use your "ultra whizzbang high performance logging" :-) example
because it doesn't fit what my concern; but imagine an existing component
(I won't name any) that is critical and Maven's existence and Maven can't
function without it. It's very easy for any PMC member to go to another OSS
community, develop it, and then kind of leave the other PMCs with no real
"choice" but to use it because the code realizes the future of Maven. Those
other PMCs are really backed into a corner; they have no real recourse to
preventing this, lest Maven development is simply halted altogether. The
other OSS community has other committers, other mailing lists, other
deliberations, etc. Community work and input becomes marginalized here.

Does this make sense to you? That kind of community-splitting effort needs
to stop and that's what I am trying to address.

Cheers,
Paul



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

> We cannot stop somebody from developing something outside of Apache.
>
> So I could go off and write a High Performance Logging API... now I could
> be doing that because I want to foist that Logging API on Maven... or I
> could be doing it as an experiment that, if successful, I may offer for
> Maven to consume... or I could be doing it because I need it for my Day
> Job...
>
> We cannot know the reasons why somebody is doing something outside of
> Maven... we can ask, but we cannot *know* if the answer we are given is
> truthful.
>
> So anyway, I now have this ultra whizzbang high performance logging API and
> I am aware of some deficit in the logging performance of Maven, so I spin
> up a private fork (it could be a hidden private fork, or it could be a
> public one... doesn't matter) and integrate the logging API and low and
> behold I see a whopping X% improvement... so I want to bring that back to
> Maven...
>
> Is there anything wrong with the above?
>
> If the library I created is under a Category A license and open source and
> I go with CTR and nobody vetos my commit... we have consensus... why do we
> need to go all Iron Fist and require a vote?
>
> We already have established tools: review of commits, vetos on commits,
> mandatory votes for Category B dependencies...
>
> Do we really need *more* processes and procedures to follow?
>
> On 2 August 2013 16:51, Paul Benedict <pb...@apache.org> wrote:
>
> > I don't understand the iron hand analogy. I was expressing the use of a
> > vote to allow or disallow critical development outside of Apache. The
> vote
> > would lead to a consensus, no?
> >
> >
> > On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> > > On 2 August 2013 16:32, Paul Benedict <pb...@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?
> > > >
> > >
> > > Votes should be a tool to confirm consensus... not an iron hand.
> > >
> > > If the consensus of the developers is to use the dependency which is
> > > external to the project, then that is fine. If there is no consensus
> then
> > > the dependency will not be introduced.
> > >
> > > We already have a policy that adding Category B dependencies to Core
> > > requires approval of the PMC, I don't see that there is much value in
> > > adding even more to this document... but if you can suggest a patch and
> > > people agree with it...
> > >
> > > -Stephen
> > >
> >
> >
> >
> > --
> > Cheers,
> > Paul
> >
>



-- 
Cheers,
Paul

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...)

[Brian Fox <br...@infinity.nu>]

On Fri, Aug 2, 2013 at 12:10 PM, Stephen Connolly
<st...@gmail.com> wrote:
> So anyway, I now have this ultra whizzbang high performance logging API and
> I am aware of some deficit in the logging performance of Maven, so I spin
> up a private fork (it could be a hidden private fork, or it could be a
> public one... doesn't matter) and integrate the logging API and low and
> behold I see a whopping X% improvement... so I want to bring that back to
> Maven...
>
> Is there anything wrong with the above?


 I say absolutely not. Where things can go wrong is what happens next.
If someone commits that giant chunk with no discussion, then that's
probably going to raise concerns. If instead a discussion is started
to discuss the work and decide if it's appropriate to pull in, then
fine.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

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...)

[Paul Benedict <pb...@apache.org>]

I've stated from the beginning of this thread that it's impossible to
prevent someone from developing outside of Apache. I stand by that still.
That can't be prevented and any attempt will fail since it's not practical.

If my words today aren't clear, I'll try again. My stance isn't about
halting developing elsewhere, but to halt what I (and maybe some others)
perceive as a way of getting around the Apache community.

I won't use your "ultra whizzbang high performance logging" :-) example
because it doesn't fit what my concern; but imagine an existing component
(I won't name any) that is critical and Maven's existence and Maven can't
function without it. It's very easy for any PMC member to go to another OSS
community, develop it, and then kind of leave the other PMCs with no real
"choice" but to use it because the code realizes the future of Maven. Those
other PMCs are really backed into a corner; they have no real recourse to
preventing this, lest Maven development is simply halted altogether. The
other OSS community has other committers, other mailing lists, other
deliberations, etc. Community work and input becomes marginalized here.

Does this make sense to you? That kind of community-splitting effort needs
to stop and that's what I am trying to address.

Cheers,
Paul



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

> We cannot stop somebody from developing something outside of Apache.
>
> So I could go off and write a High Performance Logging API... now I could
> be doing that because I want to foist that Logging API on Maven... or I
> could be doing it as an experiment that, if successful, I may offer for
> Maven to consume... or I could be doing it because I need it for my Day
> Job...
>
> We cannot know the reasons why somebody is doing something outside of
> Maven... we can ask, but we cannot *know* if the answer we are given is
> truthful.
>
> So anyway, I now have this ultra whizzbang high performance logging API and
> I am aware of some deficit in the logging performance of Maven, so I spin
> up a private fork (it could be a hidden private fork, or it could be a
> public one... doesn't matter) and integrate the logging API and low and
> behold I see a whopping X% improvement... so I want to bring that back to
> Maven...
>
> Is there anything wrong with the above?
>
> If the library I created is under a Category A license and open source and
> I go with CTR and nobody vetos my commit... we have consensus... why do we
> need to go all Iron Fist and require a vote?
>
> We already have established tools: review of commits, vetos on commits,
> mandatory votes for Category B dependencies...
>
> Do we really need *more* processes and procedures to follow?
>
> On 2 August 2013 16:51, Paul Benedict <pb...@apache.org> wrote:
>
> > I don't understand the iron hand analogy. I was expressing the use of a
> > vote to allow or disallow critical development outside of Apache. The
> vote
> > would lead to a consensus, no?
> >
> >
> > On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> > > On 2 August 2013 16:32, Paul Benedict <pb...@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?
> > > >
> > >
> > > Votes should be a tool to confirm consensus... not an iron hand.
> > >
> > > If the consensus of the developers is to use the dependency which is
> > > external to the project, then that is fine. If there is no consensus
> then
> > > the dependency will not be introduced.
> > >
> > > We already have a policy that adding Category B dependencies to Core
> > > requires approval of the PMC, I don't see that there is much value in
> > > adding even more to this document... but if you can suggest a patch and
> > > people agree with it...
> > >
> > > -Stephen
> > >
> >
> >
> >
> > --
> > Cheers,
> > Paul
> >
>



-- 
Cheers,
Paul

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...)

[Brian Fox <br...@infinity.nu>]

On Fri, Aug 2, 2013 at 12:10 PM, Stephen Connolly
<st...@gmail.com> wrote:
> So anyway, I now have this ultra whizzbang high performance logging API and
> I am aware of some deficit in the logging performance of Maven, so I spin
> up a private fork (it could be a hidden private fork, or it could be a
> public one... doesn't matter) and integrate the logging API and low and
> behold I see a whopping X% improvement... so I want to bring that back to
> Maven...
>
> Is there anything wrong with the above?


 I say absolutely not. Where things can go wrong is what happens next.
If someone commits that giant chunk with no discussion, then that's
probably going to raise concerns. If instead a discussion is started
to discuss the work and decide if it's appropriate to pull in, then
fine.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

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...)

[Stephen Connolly <st...@gmail.com>]

We cannot stop somebody from developing something outside of Apache.

So I could go off and write a High Performance Logging API... now I could
be doing that because I want to foist that Logging API on Maven... or I
could be doing it as an experiment that, if successful, I may offer for
Maven to consume... or I could be doing it because I need it for my Day
Job...

We cannot know the reasons why somebody is doing something outside of
Maven... we can ask, but we cannot *know* if the answer we are given is
truthful.

So anyway, I now have this ultra whizzbang high performance logging API and
I am aware of some deficit in the logging performance of Maven, so I spin
up a private fork (it could be a hidden private fork, or it could be a
public one... doesn't matter) and integrate the logging API and low and
behold I see a whopping X% improvement... so I want to bring that back to
Maven...

Is there anything wrong with the above?

If the library I created is under a Category A license and open source and
I go with CTR and nobody vetos my commit... we have consensus... why do we
need to go all Iron Fist and require a vote?

We already have established tools: review of commits, vetos on commits,
mandatory votes for Category B dependencies...

Do we really need *more* processes and procedures to follow?

On 2 August 2013 16:51, Paul Benedict <pb...@apache.org> wrote:

> I don't understand the iron hand analogy. I was expressing the use of a
> vote to allow or disallow critical development outside of Apache. The vote
> would lead to a consensus, no?
>
>
> On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > On 2 August 2013 16:32, Paul Benedict <pb...@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?
> > >
> >
> > Votes should be a tool to confirm consensus... not an iron hand.
> >
> > If the consensus of the developers is to use the dependency which is
> > external to the project, then that is fine. If there is no consensus then
> > the dependency will not be introduced.
> >
> > We already have a policy that adding Category B dependencies to Core
> > requires approval of the PMC, I don't see that there is much value in
> > adding even more to this document... but if you can suggest a patch and
> > people agree with it...
> >
> > -Stephen
> >
>
>
>
> --
> Cheers,
> Paul
>

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...)

[Stephen Connolly <st...@gmail.com>]

We cannot stop somebody from developing something outside of Apache.

So I could go off and write a High Performance Logging API... now I could
be doing that because I want to foist that Logging API on Maven... or I
could be doing it as an experiment that, if successful, I may offer for
Maven to consume... or I could be doing it because I need it for my Day
Job...

We cannot know the reasons why somebody is doing something outside of
Maven... we can ask, but we cannot *know* if the answer we are given is
truthful.

So anyway, I now have this ultra whizzbang high performance logging API and
I am aware of some deficit in the logging performance of Maven, so I spin
up a private fork (it could be a hidden private fork, or it could be a
public one... doesn't matter) and integrate the logging API and low and
behold I see a whopping X% improvement... so I want to bring that back to
Maven...

Is there anything wrong with the above?

If the library I created is under a Category A license and open source and
I go with CTR and nobody vetos my commit... we have consensus... why do we
need to go all Iron Fist and require a vote?

We already have established tools: review of commits, vetos on commits,
mandatory votes for Category B dependencies...

Do we really need *more* processes and procedures to follow?

On 2 August 2013 16:51, Paul Benedict <pb...@apache.org> wrote:

> I don't understand the iron hand analogy. I was expressing the use of a
> vote to allow or disallow critical development outside of Apache. The vote
> would lead to a consensus, no?
>
>
> On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > On 2 August 2013 16:32, Paul Benedict <pb...@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?
> > >
> >
> > Votes should be a tool to confirm consensus... not an iron hand.
> >
> > If the consensus of the developers is to use the dependency which is
> > external to the project, then that is fine. If there is no consensus then
> > the dependency will not be introduced.
> >
> > We already have a policy that adding Category B dependencies to Core
> > requires approval of the PMC, I don't see that there is much value in
> > adding even more to this document... but if you can suggest a patch and
> > people agree with it...
> >
> > -Stephen
> >
>
>
>
> --
> Cheers,
> Paul
>

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...)

[Paul Benedict <pb...@apache.org>]

I don't understand the iron hand analogy. I was expressing the use of a
vote to allow or disallow critical development outside of Apache. The vote
would lead to a consensus, no?


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

> On 2 August 2013 16:32, Paul Benedict <pb...@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?
> >
>
> Votes should be a tool to confirm consensus... not an iron hand.
>
> If the consensus of the developers is to use the dependency which is
> external to the project, then that is fine. If there is no consensus then
> the dependency will not be introduced.
>
> We already have a policy that adding Category B dependencies to Core
> requires approval of the PMC, I don't see that there is much value in
> adding even more to this document... but if you can suggest a patch and
> people agree with it...
>
> -Stephen
>



-- 
Cheers,
Paul

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...)

[Paul Benedict <pb...@apache.org>]

I don't understand the iron hand analogy. I was expressing the use of a
vote to allow or disallow critical development outside of Apache. The vote
would lead to a consensus, no?


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

> On 2 August 2013 16:32, Paul Benedict <pb...@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?
> >
>
> Votes should be a tool to confirm consensus... not an iron hand.
>
> If the consensus of the developers is to use the dependency which is
> external to the project, then that is fine. If there is no consensus then
> the dependency will not be introduced.
>
> We already have a policy that adding Category B dependencies to Core
> requires approval of the PMC, I don't see that there is much value in
> adding even more to this document... but if you can suggest a patch and
> people agree with it...
>
> -Stephen
>



-- 
Cheers,
Paul

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...)

[Stephen Connolly <st...@gmail.com>]

On 2 August 2013 16:32, Paul Benedict <pb...@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?
>

Votes should be a tool to confirm consensus... not an iron hand.

If the consensus of the developers is to use the dependency which is
external to the project, then that is fine. If there is no consensus then
the dependency will not be introduced.

We already have a policy that adding Category B dependencies to Core
requires approval of the PMC, I don't see that there is much value in
adding even more to this document... but if you can suggest a patch and
people agree with it...

-Stephen

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...)

[Curtis Rueden <ct...@wisc.edu>]

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 <pb...@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 <br...@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
> > > <st...@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: <st...@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
>

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...)

[Ron Wheeler <rw...@artifact-software.com>]

On 02/08/2013 11:32 AM, Paul Benedict 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?
For what purpose?
You can't stop the person anyway and in the discussion, it is fair to 
assume that you would have raised your objections.

The vote will come when a PMC member wants to change the dependency when 
the code comes back.
At that point you have the code and you have a chance to see the new 
functionality or performance to see if the changes live up to the 
advanced billing.

Ron


>
>
> 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 <br...@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
>>> <st...@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: <st...@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
>>>
>>>
>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

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...)

[Curtis Rueden <ct...@wisc.edu>]

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 <pb...@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 <br...@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
> > > <st...@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: <st...@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
>

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...)

[Stephen Connolly <st...@gmail.com>]

On 2 August 2013 16:32, Paul Benedict <pb...@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?
>

Votes should be a tool to confirm consensus... not an iron hand.

If the consensus of the developers is to use the dependency which is
external to the project, then that is fine. If there is no consensus then
the dependency will not be introduced.

We already have a policy that adding Category B dependencies to Core
requires approval of the PMC, I don't see that there is much value in
adding even more to this document... but if you can suggest a patch and
people agree with it...

-Stephen

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...)

[Paul Benedict <pb...@apache.org>]

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 <br...@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
> > <st...@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: <st...@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

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...)

[Paul Benedict <pb...@apache.org>]

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 <br...@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
> > <st...@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: <st...@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

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...)

[Stephen Connolly <st...@gmail.com>]

On 2 August 2013 16:07, Brian Fox <br...@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
> <st...@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: <st...@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
>
>

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...)

[Ron Wheeler <rw...@artifact-software.com>]

Line 238, 246   opertunity -> opportunity

I wonder if a statement of policy should have so much procedure written 
into it.
The procedures will change over time as people change their ideas about 
best practices whereas policies should be less volatile.

It might be easier to state the goals of the policy and leave the 
implementation up to a more informal discussion that takes the actual 
situation into account.

Ron

On 02/08/2013 11:07 AM, Brian Fox 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. 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.
>
> On Fri, Aug 2, 2013 at 5:59 AM, Stephen Connolly
> <st...@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: <st...@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
>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

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...)

[Stephen Connolly <st...@gmail.com>]

On 2 August 2013 16:07, Brian Fox <br...@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
> <st...@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: <st...@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
>
>

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...)

[Brian Fox <br...@infinity.nu>]

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. 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.

On Fri, Aug 2, 2013 at 5:59 AM, Stephen Connolly
<st...@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: <st...@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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

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...)

[Stephen Connolly <st...@gmail.com>]

On 2 August 2013 16:08, Curtis Rueden <ct...@wisc.edu> wrote:

> Hi Stephen,
>
> > 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?
>
> 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.
>

Unfortunately the review must be of what lands at Apache servers. It could
be a bare bones review because the bulk of the review happened elsewhere,
but there must still be eyes on the code when it lands at Apache.... at
least that is my understanding.


>
> 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.
>

SVN history can be rewritten if you have admin access to the Subversion
server... SVN revision properties can be edited to, e.g. change author or
commit message, etc.

This is not just a GIT issue, this is a "not happening at Apache hardware"
issue... when it happens at Apache hardware, we can be more lax about
probing for those kind of issues as we have the excuse that we rely on
infra to put in place the controls to ensure the required traceability...
when it happens on 3rd party controlled hardware, we don't have that
option, so the review needs to be more strict.


> 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.
>

Yes, and I don't think anyone was suggesting we move away from GIT... if
anything we are migrating our repositories from Subversion to GIT because
it is the better tool.


>
> 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."
>

Keep in mind that there will always be some things that we need to do in
slightly strange ways because we need to maintain the legal protection that
the foundation provides for Committers... but keep in mind that none of us
enjoy that!!!


>
> Regards,
> Curtis
>
> P.S. For those interested, Stephen's changes are more clear when reading
> the side-by-side diff:
>
> http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?r1=1507630&r2=1509594&diff_format=h
>
>
> On Fri, Aug 2, 2013 at 4: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: <st...@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
> >
>

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...)

[Baptiste MATHUS <ml...@batmat.net>]

Le 2 août 2013 20:27, "Baptiste MATHUS" <ml...@batmat.net> a écrit :
>
>
> Le 2 août 2013 17:48, "Hervé BOUTEMY" <he...@free.fr> a écrit :
>
> >
> > Le vendredi 2 août 2013 10:08:42 Curtis Rueden a écrit :
> > > 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.
> > I didn't use gerrit nor have seen anybody using it. But I hear about it
more
> > and more often as an argument why it makes git better than svn (even if
I read
> > that gerrit is a fork of rietveld, which is the same for subversion: but
> > nobody even talks about it, don't know why).
> > Is this pure theory? a dream? a reality for a minority of experts,
talking
> > about it loudly but no mere mortal can use it?
> > (intentional provocational tone to motivate people who know to show me
the
> > direction to the light :) )
>
> Just my 2 cents : been using gerrit professionally on a daily basis for 8
months now. So there's actually real people using it, I can testify ;).
>
> We're a team of ~10 guys.
>
> (For French savvy people I've given a short talk about it at the Toulouse
jug. The session was recorded ans is hosted on parleys).
>
> >
> > > 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.
> > yes, with git, you can: with git, so much things can be done.
> > But once again, I didn't see anybody do it, because it's a lot of work.
>
> You're right. I try to do it as often as I can. But perfection takes a
bit too long to commit/rework and sometimes it's ridiculous ;).

Oops not sure I was clear. I was answering to 'lot of work's part. Not
'anybody...' because I actually do it and know many people doing it very
often. I generally do it almost each time before pushing.


>
> > And it requires to be a git black belt.
>
> It helps to practice, sure. Btw, Gerrit makes it worse. It almost forces
you to use advances features to make it really useful.
> That's why I'd say putting a whole team both beginning with git and
gerrit would be a mistake.
>
> > For the moment, just making a rebase before merging a branch seems hard
for us
> > mere mortals.
> >
> > > 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.
> > +1
> > I like it too
> >
> > Regards,
> >
> > Hervé
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >

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...)

[Baptiste MATHUS <ml...@batmat.net>]

Le 2 août 2013 17:48, "Hervé BOUTEMY" <he...@free.fr> a écrit :
>
> Le vendredi 2 août 2013 10:08:42 Curtis Rueden a écrit :
> > 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.
> I didn't use gerrit nor have seen anybody using it. But I hear about it
more
> and more often as an argument why it makes git better than svn (even if I
read
> that gerrit is a fork of rietveld, which is the same for subversion: but
> nobody even talks about it, don't know why).
> Is this pure theory? a dream? a reality for a minority of experts, talking
> about it loudly but no mere mortal can use it?
> (intentional provocational tone to motivate people who know to show me the
> direction to the light :) )

Just my 2 cents : been using gerrit professionally on a daily basis for 8
months now. So there's actually real people using it, I can testify ;).

We're a team of ~10 guys.

(For French savvy people I've given a short talk about it at the Toulouse
jug. The session was recorded ans is hosted on parleys).

>
> > 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.
> yes, with git, you can: with git, so much things can be done.
> But once again, I didn't see anybody do it, because it's a lot of work.

You're right. I try to do it as often as I can. But perfection takes a bit
too long to commit/rework and sometimes it's ridiculous ;).

> And it requires to be a git black belt.

It helps to practice, sure. Btw, Gerrit makes it worse. It almost forces
you to use advances features to make it really useful.
That's why I'd say putting a whole team both beginning with git and gerrit
would be a mistake.

> For the moment, just making a rebase before merging a branch seems hard
for us
> mere mortals.
>
> > 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.
> +1
> I like it too
>
> Regards,
>
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

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...)

[Thomas Broyer <t....@gmail.com>]

On Fri, Aug 2, 2013 at 5:47 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> I didn't use gerrit nor have seen anybody using it.

Gerrit was created by and for Android: https://android-review.googlesource.com
It's used for Gerrit itself https://gerrit-review.googlesource.com
(dogfooding), Chromium and GWT, on Google infra.
It's also used by many companies contributing to Android (Sony, etc.),
and by Eclipse, Typo3, KDE, LibreOffice, Qt, OpenStack, etc.
https://code.google.com/p/gerrit/wiki/ShowCases
…and CloudFoundry:
http://blog.cloudfoundry.com/2012/04/11/the-new-cloudfoundry-org-gerrit-jenkins-github/

> But I hear about it more
> and more often as an argument why it makes git better than svn (even if I read
> that gerrit is a fork of rietveld, which is the same for subversion: but
> nobody even talks about it, don't know why).

Rietveld is hard to install outside AppEngine, that's probably why. I
would have loved to use it at work otherwise, instead of that crappy
ReviewBoard; we've fortunately moved to Git and Gerrit since then.

That said, Gerrit 1.x was started as a fork of Rietveld, but Gerrit
2.x has been rewritten from scratch in Java and GWT, built on top of
JGit.

> Is this pure theory? a dream? a reality for a minority of experts, talking
> about it loudly but no mere mortal can use it?
> (intentional provocational tone to motivate people who know to show me the
> direction to the light :) )
>
>> 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.
> yes, with git, you can: with git, so much things can be done.
> But once again, I didn't see anybody do it, because it's a lot of work.
> And it requires to be a git black belt.
> For the moment, just making a rebase before merging a branch seems hard for us
> mere mortals.

WAT? You can't wrap your head around a DAG of commits and you want us
other mere mortals to use a tool you're building on top of a DAG of
transitive dependencies? (intentionally provocative tone to motivate
you to reconsider your position about git). Git is easy to work with
when you think in terms of the DAG in your repo; no need to be a git
black belt for that.
I merely use 5 git commands on a daily basis (using "git gui" to do my
commits and deal with my working directory; pull, push, checkout and
"rebase -i"; merges are generally done by Gerrit, at the push of a
button; on a relatively big project like GWT, I tend to use gitk, "git
log --grep", "git grep" and "git blame" quite a lot too; and this only
works well if you have a "clean history", which you cannot have with a
"commit then review" approach – on master/trunk I mean – but of
course, because SVN doesn't give you tools to easily look back at your
commit history, you tend to not care that much about having a "clean
history"; "git svn" mitigates it a bit).

-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

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...)

[Hervé BOUTEMY <he...@free.fr>]

thank you Curtis: all the pointers you gave are of great value!

I perfectly understand your Githubs examples: pull requests + work to give 
pull requests most chances to be accepted
In fact, in our case, for somebody having commit privileges, using such pull 
requests isn't the first thing I would have thought, but yes, it is a good 
Review Then Commit tooling

For somebody with commit privileges, would you find any key difference with a 
branch on ASF Git + discussion on mailing list before merging into master?


For gerrit, now I see what it looks like: seems really more complex than 
GitHubs pull requests. Don't know when such tooling starts to be really useful


Thanks again for your pointers: today, I learned something useful, it's a good 
day
Notice I'm having holidays and won't be on the ML for 2 weeks: I won't be able 
to continue the discussion, even if really instructive

Regards,

Hervé

Le vendredi 2 août 2013 11:13:50 Curtis Rueden a écrit :
> Hi Herve,
> 
> > I didn't use gerrit nor have seen anybody using it. ... Is this pure
> > theory? a dream? a reality for a minority of experts, talking about it
> > loudly but no mere mortal can use it?
> 
> Google uses it (of course). For example, for Chromium:
> https://gerrit.chromium.org/
> Kitware uses it. ITK, VTK, etc.: http://review.source.kitware.com/
> I'm sure there are many others.
> 
> Personally my colleagues and I don't use it; we use GitHub's code review
> mechanism which is simple and effective. You can comment on any Pull
> Request, and on any line of any commit.
> 
> > I hear about it more and more often as an argument why it makes git
> > better than svn
> 
> It was not my goal to argue that "Gerrit makes Git better than SVN" but
> rather than good code review tools make code review *much* easier.
> 
> Git is better than SVN for many, many reasons that have nothing to do with
> code review tools. :-P
> 
> > yes, with git, you can: with git, so much things can be done. But once
> > again, I didn't see anybody do it, because it's a lot of work. And it
> > requires to be a git black belt.
> 
> As a programmer, revision control in one of your bread-and-butter tools.
> Shouldn't you be taking the time to become a VCS black belt? Doing so will
> save you loads of time in the long run, for the same reasons that becoming
> a command line master, or an IDE master, or a master of *any* effective
> productivity tool, will. Embrace Larry Wall's virtues of the programmer --
> laziness, impatience and hubris -- and always seek the better, faster path!
> Computers are different than other skill sets: a professional sprinter may
> be able to sprint 2x or 3x or even 5x faster than you, but a professional
> programmer can accomplish a task on a computer thousands or even millions
> of times faster than a neophyte... *if* the programmer has a thirst for
> knowledge and self-improvement.
> 
> </soapbox>
> 
> Anyway, yes, my colleagues and I *do* use Git in this way: work on topic
> branches, rewrite history to make review easier, and sometimes file Pull
> Requests on GitHub to specifically invite review for possibly disruptive
> changes.
> 
> I'm not really sure what to point you at here, other than the "Contribution
> Activity" section of my GitHub page:
> https://github.com/ctrueden
> Of course, it is changing all the time...
> 
> Regards,
> Curtis
> 
> On Fri, Aug 2, 2013 at 10:47 AM, Hervé BOUTEMY <he...@free.fr>wrote:
> > Le vendredi 2 août 2013 10:08:42 Curtis Rueden a écrit :
> > > 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.
> > I didn't use gerrit nor have seen anybody using it. But I hear about it
> > more
> > and more often as an argument why it makes git better than svn (even if I
> > read
> > that gerrit is a fork of rietveld, which is the same for subversion: but
> > nobody even talks about it, don't know why).
> > Is this pure theory? a dream? a reality for a minority of experts, talking
> > about it loudly but no mere mortal can use it?
> > (intentional provocational tone to motivate people who know to show me the
> > direction to the light :) )
> > 
> > > 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.
> > 
> > yes, with git, you can: with git, so much things can be done.
> > But once again, I didn't see anybody do it, because it's a lot of work.
> > And it requires to be a git black belt.
> > For the moment, just making a rebase before merging a branch seems hard
> > for us
> > mere mortals.
> > 
> > > 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.
> > 
> > +1
> > I like it too
> > 
> > Regards,
> > 
> > Hervé
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

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...)

[Curtis Rueden <ct...@wisc.edu>]

Hi Herve,

> I didn't use gerrit nor have seen anybody using it. ... Is this pure
> theory? a dream? a reality for a minority of experts, talking about it
> loudly but no mere mortal can use it?

Google uses it (of course). For example, for Chromium:
https://gerrit.chromium.org/
Kitware uses it. ITK, VTK, etc.: http://review.source.kitware.com/
I'm sure there are many others.

Personally my colleagues and I don't use it; we use GitHub's code review
mechanism which is simple and effective. You can comment on any Pull
Request, and on any line of any commit.

> I hear about it more and more often as an argument why it makes git
> better than svn

It was not my goal to argue that "Gerrit makes Git better than SVN" but
rather than good code review tools make code review *much* easier.

Git is better than SVN for many, many reasons that have nothing to do with
code review tools. :-P

> yes, with git, you can: with git, so much things can be done. But once
> again, I didn't see anybody do it, because it's a lot of work. And it
> requires to be a git black belt.

As a programmer, revision control in one of your bread-and-butter tools.
Shouldn't you be taking the time to become a VCS black belt? Doing so will
save you loads of time in the long run, for the same reasons that becoming
a command line master, or an IDE master, or a master of *any* effective
productivity tool, will. Embrace Larry Wall's virtues of the programmer --
laziness, impatience and hubris -- and always seek the better, faster path!
Computers are different than other skill sets: a professional sprinter may
be able to sprint 2x or 3x or even 5x faster than you, but a professional
programmer can accomplish a task on a computer thousands or even millions
of times faster than a neophyte... *if* the programmer has a thirst for
knowledge and self-improvement.

</soapbox>

Anyway, yes, my colleagues and I *do* use Git in this way: work on topic
branches, rewrite history to make review easier, and sometimes file Pull
Requests on GitHub to specifically invite review for possibly disruptive
changes.

I'm not really sure what to point you at here, other than the "Contribution
Activity" section of my GitHub page:
https://github.com/ctrueden
Of course, it is changing all the time...

Regards,
Curtis


On Fri, Aug 2, 2013 at 10:47 AM, Hervé BOUTEMY <he...@free.fr>wrote:

> Le vendredi 2 août 2013 10:08:42 Curtis Rueden a écrit :
> > 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.
> I didn't use gerrit nor have seen anybody using it. But I hear about it
> more
> and more often as an argument why it makes git better than svn (even if I
> read
> that gerrit is a fork of rietveld, which is the same for subversion: but
> nobody even talks about it, don't know why).
> Is this pure theory? a dream? a reality for a minority of experts, talking
> about it loudly but no mere mortal can use it?
> (intentional provocational tone to motivate people who know to show me the
> direction to the light :) )
>
> > 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.
> yes, with git, you can: with git, so much things can be done.
> But once again, I didn't see anybody do it, because it's a lot of work.
> And it requires to be a git black belt.
> For the moment, just making a rebase before merging a branch seems hard
> for us
> mere mortals.
>
> > 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.
> +1
> I like it too
>
> Regards,
>
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

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...)

[Hervé BOUTEMY <he...@free.fr>]

Le vendredi 2 août 2013 10:08:42 Curtis Rueden a écrit :
> 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.
I didn't use gerrit nor have seen anybody using it. But I hear about it more 
and more often as an argument why it makes git better than svn (even if I read 
that gerrit is a fork of rietveld, which is the same for subversion: but 
nobody even talks about it, don't know why).
Is this pure theory? a dream? a reality for a minority of experts, talking 
about it loudly but no mere mortal can use it?
(intentional provocational tone to motivate people who know to show me the 
direction to the light :) )

> 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.
yes, with git, you can: with git, so much things can be done.
But once again, I didn't see anybody do it, because it's a lot of work.
And it requires to be a git black belt.
For the moment, just making a rebase before merging a branch seems hard for us 
mere mortals.

> 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.
+1
I like it too

Regards,

Hervé

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

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...)

[Stephen Connolly <st...@gmail.com>]

On 2 August 2013 16:08, Curtis Rueden <ct...@wisc.edu> wrote:

> Hi Stephen,
>
> > 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?
>
> 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.
>

Unfortunately the review must be of what lands at Apache servers. It could
be a bare bones review because the bulk of the review happened elsewhere,
but there must still be eyes on the code when it lands at Apache.... at
least that is my understanding.


>
> 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.
>

SVN history can be rewritten if you have admin access to the Subversion
server... SVN revision properties can be edited to, e.g. change author or
commit message, etc.

This is not just a GIT issue, this is a "not happening at Apache hardware"
issue... when it happens at Apache hardware, we can be more lax about
probing for those kind of issues as we have the excuse that we rely on
infra to put in place the controls to ensure the required traceability...
when it happens on 3rd party controlled hardware, we don't have that
option, so the review needs to be more strict.


> 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.
>

Yes, and I don't think anyone was suggesting we move away from GIT... if
anything we are migrating our repositories from Subversion to GIT because
it is the better tool.


>
> 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."
>

Keep in mind that there will always be some things that we need to do in
slightly strange ways because we need to maintain the legal protection that
the foundation provides for Committers... but keep in mind that none of us
enjoy that!!!


>
> Regards,
> Curtis
>
> P.S. For those interested, Stephen's changes are more clear when reading
> the side-by-side diff:
>
> http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?r1=1507630&r2=1509594&diff_format=h
>
>
> On Fri, Aug 2, 2013 at 4: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: <st...@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
> >
>

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...)

[Curtis Rueden <ct...@wisc.edu>]

Hi Stephen,

> 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?

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."

Regards,
Curtis

P.S. For those interested, Stephen's changes are more clear when reading
the side-by-side diff:
http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?r1=1507630&r2=1509594&diff_format=h


On Fri, Aug 2, 2013 at 4: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: <st...@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
>

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...)

[Brian Fox <br...@infinity.nu>]

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. 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.

On Fri, Aug 2, 2013 at 5:59 AM, Stephen Connolly
<st...@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: <st...@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

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...)

[Curtis Rueden <ct...@wisc.edu>]

Hi Stephen,

> 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?

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."

Regards,
Curtis

P.S. For those interested, Stephen's changes are more clear when reading
the side-by-side diff:
http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?r1=1507630&r2=1509594&diff_format=h


On Fri, Aug 2, 2013 at 4: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: <st...@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
>