Re: thoughts on Avalon PMC

[Leo Sutic]

Peter Donald wrote:
> > - precisely, as you wrote long ago, we're so
> > into this "not voting on something we haven't written".
>
> It is called meritocracy and it is how Apache runs.

Unfortunately it is in some cases a broken system due to
borders between projects not always being as clear-cut as
they should be in theory (more below).

> > A PMC may provide leadership in being a forum where
> > overarching issues can be decided on.
>
> the committers still vote with their feet. A committee can decide anything it
> wants> If consensus is not reached then the decisions are pointless. And
> there is no need for a PMC to reach consensus because any set of adults
> should be able to do so if they so want.
>
> > Peter Donald wrote:
> > > yep. And the technical decisions get made by those who
> > > earn the privlidge to do so ;)
> >
> > Could you be more specific, Peter? For example, how
> > would one earn this privilige?
>
> sending patches for code and documentation that fits with the vision.
> Demonstrating a willingness and want to work on the code. Understanding the
> privlidges and obligations that go hand in hand.
>
> > In particular, who decides?
>
> the component developers.
>
> I believe the process will be fairly well documented for Apache Commons and I
> intend to propose that for adoption when the time comes.
>
> At the moment there are those of us who end up developing off Avalon because
> there is no way to protect yourself against hostile attacks.
>
> Avalons system assumes we are all adults who respect each others work. Since
> that system failed there needs to be a more formal system in place to limit
> the damage that can be done. The best way to do that is to partition access
> to those who merit it.

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, 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)?

I see before me a thousand such border skirmishes, and we end up fragmenting
Avalon even more. As it is now, we do have some conflicts, but your proposal
would add yet another thing to fight over instead of removing such hazards.

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?

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?

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?

/LS



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