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