maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <rwhee...@artifact-software.com>
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 18:02:45 GMT
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 <pbenedict@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 <pbenedict@apache.org> wrote:
>>>>
>>>>> Furthermore, I'd like to see explicit procedural rules on Maven Core
>>> and
>>>>> forking. For example, if there's a critical component needing
>>> development
>>>>> for Core, and a PMC expresses that such development will be done
>>> outside
>>>> of
>>>>> Apache and then used as a dependency, shouldn't there be a vote on
>>> that?
>>>> 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


Mime
View raw message