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 < > [email protected]> 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 <[email protected]> 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 < > [email protected]> wrote: > > On 2 August 2013 16:32, Paul Benedict <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > > -- Sent from my phone
