maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Fox <>
Subject Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Date Sat, 03 Aug 2013 02:06:09 GMT
On Aug 2, 2013, at 12:30 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 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 <
>> 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 <> 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 <
>>>> wrote:
>>>> On 2 August 2013 16:32, 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?
>>>> 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:
For additional commands, e-mail:

View raw message