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
ASF project level. Consensus can include any number of "don't care votes", but should include three +1 votes.A question: what is the smallest unit that can claim concensus?
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.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?
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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
