On Mon, 11 Nov 2002 12:53, Leo Sutic wrote: > Peter Donald wrote: > > 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. > > ... > > > In the end darwin wins out. > > Seems like you're praising the opportunity for turf wars and conflict > here...
I am praising the ability for people to develope their ideas and code unfetted by people who may feel threatened by such development. As long as the proper forms are followed there should be no problem. You have never heard said that "The ability to fork is one of the best incentives for forks not to occur". > > > 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. > > You haven't explained how you will deal with someone who starts off > being "compatible" but then becomes "non-compatible". Because, isn't > that precisely what has happened? Nope. "non-compatible" was not a problem - thats why we embrace the ability to fork when necessary or even on a whim. Go back in avalons history and you will oodles of forks, variations and development branches. At one stage we had three version of a simple pool component - then we created yet another fork to unit the other forks ;) Recently Berin forked again to get rid of marker interface. All good I say. If someone disagrees with the direction of the codebase they are free to convince the others developing the codebase to follow their direction. If that doesn't work they can fork. The problem occured when commits were made to phoenix/cornerstone codebase by someone who had not participated in phoenix/cornerstones development and were made in violation of vetos. Especially given that the person had stated that they didn't mind if phoenix died. Then combine this with other problem behaviour (interaction with james group, licensing stuff, personal attacks, so and so forth) and you have the problems. Conflict is not a problem - the reaction to conflict is. > As I understand it, if agreeing with the vision of the project is a > requirement for voting rights, then it follows that the moment you do not > agree with the vision you lose the right to vote. As long as you participate in the development of the component then you have the privlidge of the vote. If you disappear for a while then you become emritus. You only loose the priv if you abuse it. > "if I > could make sure everyone agreed with me from the start, then I'll never > have any conflicts". Thats not the point. The point is that the community gets to decide the policy by which they grow. Conflicts will always arise and it is up to the community to resolve them following the Apache rules. People who don't participate in development may not have the best wishses of the developers in mind. Even if they do they may not be aware of the implications of various things because they are non particpating. Hence why Apache is based on merit. -- Cheers, Peter Donald ----------------------------------------------- | If you turn on the light quickly enough, | | you can see what the dark looks like. | ----------------------------------------------- -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
