avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: thoughts on Avalon PMC
Date Mon, 11 Nov 2002 00:07:41 GMT
On Mon, 11 Nov 2002 10:48, Leo Sutic wrote:
> 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?

Those who vote on Avalon/Framework will most likely be a superset of 
Avalon/Phoenix developers but even if they are not and the Avalon/Framework 
make a decsion that negatively effects Avalon/Phoenix or didn't take into 
consideration the needs of Avalon/Phoenix then Avalon/Phoenix is free to drop 
Avalon/Framework and create it's own framework.

However thats unlikely to happen. Avalon/Phoenix has already been negatively 
effected by changes in Avalon/Framework - it would have to be a significant 
problem before a move was considered.

In the end darwin wins out.

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

nope. The developers on Avalon/Phoenix vote on development issues of 
Avalon/Phoenix while the Avalon PMC votes on management issues of Avalon. It 
would be rare that the two would overlap on voting issues.

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

eh? That was never said - it is based on merit and compatability with existing 
community. If they are not compatible then it will only lead to conflict - 
precisely what we want to avoid.

> As for Cocoon, I have never seen Stefano worry about "hostile attacks",

A year ago no one in Avalon-land would have ever dreamed of worrying about 
"hostile attacks". Times change.

> Regarding that: If this really is a meritocracy, shouldn't merit, and not
> administrative
> rules be used to make people uncontested rulers? 

thats precisely the point.

> To me, meritocracy meant
> that ones design decisions are so good that they are accepted without
> having to pull rank.

If someone has a really great idea then it will most likely be incorporated - 
if the idea is not so great then it wont be. However the decision of how to 
implement the idea and how to action it rests on the developers of the 
codebase - not on any outside agency. I think you termed that outside agency 
beuracracy and "administrative rules".

-- 
Cheers,

Peter Donald
*--------------------------------*
| Every rule has an exception,   |
| except the rule of exceptions. |
*--------------------------------* 


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


Mime
View raw message