Return-Path: X-Original-To: apmail-maven-dev-archive@www.apache.org Delivered-To: apmail-maven-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 08A7710BC9 for ; Fri, 2 Aug 2013 16:49:28 +0000 (UTC) Received: (qmail 92102 invoked by uid 500); 2 Aug 2013 16:49:26 -0000 Delivered-To: apmail-maven-dev-archive@maven.apache.org Received: (qmail 92032 invoked by uid 500); 2 Aug 2013 16:49:26 -0000 Mailing-List: contact dev-help@maven.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Maven Developers List" Reply-To: "Maven Developers List" Delivered-To: mailing list dev@maven.apache.org Received: (qmail 91693 invoked by uid 99); 2 Aug 2013 16:49:26 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Aug 2013 16:49:26 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [216.86.168.183] (HELO mxout-08.mxes.net) (216.86.168.183) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Aug 2013 16:49:20 +0000 Received: from mbp.local (unknown [31.130.159.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8CF73509B6 for ; Fri, 2 Aug 2013 12:48:58 -0400 (EDT) Message-ID: <51FBE2F8.3020702@ifedorenko.com> Date: Fri, 02 Aug 2013 20:48:56 +0400 From: Igor Fedorenko User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: dev@maven.apache.org 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...) References:

In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Is this really specific to PMC? Can't a regular developer like myself do the same, i.e. setup a project elsewhere, then commit 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 < > 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 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 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: dev-unsubscribe@maven.apache.org For additional commands, e-mail: dev-help@maven.apache.org