maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Fedorenko <>
Subject Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Date Fri, 02 Aug 2013 16:48:56 GMT
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?


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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message