On Mon, 11 Nov 2002 08:27, Leo Sutic wrote: > I said to Leo Simons that partitioning voting and committ priviliges would > lead to the mother of all bureaucracies - and I think your approach will > fail for similar > reasons. An example: The use of release(). > > If I understand it correctly, Phoenix usage style do not provide for > container- managed pooling of instances,
not yet :) > while ECM does. > > The ComponentManager/ServiceManager contract is mute on the point. > Does this mean that the question is local to Phoenix (i.e. can/should be > decided by those with Phoenix voting rights) or is it global to Avalon > (i.e. can/should be voted on by all)? It is local to Avalon/Framework. > Finally - two things. The first: I am a bit opposed to your "A committee > can decide anything it wants> If consensus is not reached then the > decisions are pointless." comment. As I understand it, once something has > been voted on, all committers are bound by the outcome. Traditional > democracy, that is. If not, is there any point in having a voting procedure > at all? Or am I misunderstanding you? Nope you understood correctly. Change occurs via consensus of participants on the codebase being changed. Change can not be forced from people outside those partitipants. The voting procedure is meant to be a mechanism via which consensus is built. If you are looking for the PMC to be the arbitrator of all design decisions then you will be somewhat disappointed. When you asked "If not, is there any point in having a voting procedure at all?" - I would say yep. The point is that the PMC will make votes on management issues while the develoeprs will make votes on development issues. > The second: If you limit voting rights to those who agree with the vision > of a component, then you are, in effect, deliberately setting up a group of > yes-men. Think about it: If only those that agree with your vision for > Phoenix get to vote about Phoenix things, where are you going to get > opposition from? "Yes-men"? I don't think thats fair to the people who are involved in Phoenix. However they will all share the same vision and want to work together. I don't think that has harmed the other projects that follow this pattern (ie Cocoon for one). > To put the above in a form blunt enough to be indistiguishable from > rudeness: Isn't your advocacy of "meritocracy" not just a way to set > yourself up as the uncontested ruler of Phoenix, and to get rid of Stephen? > Isn't he what you refer to as "hostile attacks"? Isn't that the problem? The idea is to set the active developers of phoenix up as uncontested rulers of Phoenix. Going by Pauls recent stats that would imply donaldp, hammant, proyal, colus and huw all have equal privlidges and responsibilities. -- Cheers, Peter Donald ------------------------------------ The two secrets to success: 1- Don't tell anyone everything. ------------------------------------ -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
