Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 8759 invoked from network); 22 Nov 2002 14:14:58 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 22 Nov 2002 14:14:58 -0000 Received: (qmail 9176 invoked by uid 97); 22 Nov 2002 14:15:57 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 9160 invoked by uid 97); 22 Nov 2002 14:15:57 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 9148 invoked by uid 98); 22 Nov 2002 14:15:56 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3DDE3BD7.1010005@apache.org> Date: Fri, 22 Nov 2002 09:14:47 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: avalon-dev@jakarta.apache.org Subject: RE: [Proposal] Phoenix no longer reference container Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Leo Sutic wrote: > Meaning that (as I interpret it), as long as Phoenix has a > > + defined scope based on concensus. > > + sticks to that scope > > + clear understanding of its relation to Avalon > > we should be fine. +1 > A question: what is the smallest unit that can claim concensus? ASF project level. Consensus can include any number of "don't care votes", but should include three +1 votes. > Avalon does not need the consensus of Jakarta-Commons, we can > vote ourselves. At the same time, I don't want one person > creating a subproject of Avalon, declaring that he owns that > code and that his own opinion is equal to concensus. > > In short, is there any way to decouple Phoenix from Avalon > in such a way so that *all* PMC members need not vote on > *every* change to Phoenix, yet keep Phoenix from sliding > away to a little isolated group of its own? A point of order. No PMC member is *ever* required to vote on *any* specific change. If what you desire is a mechanism by which a specific PMC member is *excluded* from voting on a specific change, then you need to either propose a new top level project for Phoenix, or find another home for this code. Separate code bases with separate communities should be separate projects. Independent of the size of the codebase, if the size of the community is only a few people, then it is not an ASF project. Such efforts can be pursued outside of the ASF, be pursued inside the Incubator, or be incorporated inside an existing community � as long as all participants in that larger community are treated as peers. - Sam Ruby -- To unsubscribe, e-mail: For additional commands, e-mail: