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.conno...@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 <pbened...@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.conno...@gmail.com> wrote: > > > > > On 2 August 2013 16:32, Paul Benedict <pbened...@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
