Paul and Peter,

regarding my "yes-men" comment: In short: I'm sticking
by it. Long reply: see below.

Peter Donald wrote:
> > 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.

Which illustrates my point: Now you have those with Avalon/Framework
voting rights voting on something that will affect Phoenix, even though
an equally valid response would be that it is local to Phoenix (if it isn't
in the contract, an implementation may do as it pleases).

How will these areas of voting/responsibility be determined?

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

Then what you are in effect saying is that one is free to ignore the
result of any vote.

Of course, committ priviliges may be revoked but haven't you
then created the arbitrator you said didn't exist?

> "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).

Granting voting rights to people based on how they will vote is
just plain bad. For example, what will you do if someone, after having
been granted voting rights, suddenly disagrees vehemently with the
vision of the project? Revoke voting rights?

As for Cocoon, I have never seen Stefano worry about "hostile attacks",
so don't compare your proposal to that project. If you want to run Avalon
like Cocoon, fine. But your proposal do not lead to that.

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

Regarding that: If this really is a meritocracy, shouldn't merit, and not administrative
rules be used to make people uncontested rulers? To me, meritocracy meant that
ones design decisions are so good that they are accepted without having to
pull rank.

/LS



--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>

Reply via email to