Peter Donald wrote:
On Mon, 11 Nov 2002 12:53, Leo Sutic wrote:Hi Pete - I'm honoured to see your referencing me in discussions concerning the Phoenix/cornerstone development activities. I think particular vetos, their validity, the extent of quality of communication and dicussion, the timing of related development actions - many of these can be taken in isolatation and argued on way or another. At the end of the day - both you and I have blood on our hands. I definately want to move on - and just between you and I (and everyone else on this list) I want that to be a healthy relationship, no barriers, one community, good structure and accountability. I am a Phoneix user, I have a vested interest in cornerstone components, I'm not contributing code to Phoenix but that's basically because I'm prevented from doing so. Keep in mind that I have a great deal of experience using and working with Phoenix, I've contributed to Phoenix user documetation, and provided a lot of email support to Phoenix users over the years.
Peter Donald wrote: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.
> 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...
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 isNope. "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.
> > 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?
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.
How does this relate to the Avalon PMC?
Well, I been really furtunate to see the Jakarta PMC in action dealing with recent accusations. I'm impressed with their assessment of the situation, and the effort spent getting to the real facts. I see this as a good example of a process of resolving what would otherwise could be an intractible conflict.
Especially given that the person had stated that they didn't mind if phoenix died.:-)
Somewhat out of context - but anyway, just for clarification - people can see my comments about Phoenix over on the Merlin FAQ. Seems to me that the assessment is if anything rather positive towards Phoenix. http://jakarta.apache.org/avalon/excalibur/merlin/faq.html
Then combine this with other problem behaviour (interaction with james group,Paul requested that I take over the role he was playing of liaising with James. The James/Avalon relationship is complex - covering framework, serveral facilities in Excalibur, several components from cornerstone, and Phoenix. Yes - I'm actively encoraging a migration of James to a "container neutral" deployment approach - one where the role of Phoenix is the deployment environment. I think this is healthy, improves James portability, and is basically founded on good design pricipals. Of couse, anyone here is free to post messages to James supporting alternative approaches or opinions.
licensing stuff,Glad you brought this one up - latest news - everything is moving very positely here - all the members of the OpenORB community have submitted their CLAs to Apache, and the board have been great in respect to facilitating the corporate side of things. I'm really pleased with the way things are going. This again relates to the topic of this thread - the Avalon PMC. Clearly there is a process in place dealing with the license matters pertaiing to the OpenORB codebase and derived works. Once that is finalized, there will be clearly a need to address the enterprise package as part of the overall restructuring of Avalon.
personal attacks, so and so forth) and you have the problems. Conflict is not a problem - the reaction to conflict is.I don't think you can isolate conflicts in the way your suggesting. There are simply two many connections between things. Yes - granted - the work I'm going on Merlin raises all sort of questions concerning containment. It's pushed in one direction by the requirements and interest of Cocoon. Its pushed in other directions by requirements from Phoenix/Cornerstone/James. It's pushed in other directions by my own requirements for distributed service management. It's pushed in even more directions my members of this list. That's simply brilliant. I would love to see more collaboration with Phoenix and I think that there is real value to be gained for both Merlin and Phoenix - but that does require positive approach.
What if an individual is effectively excluded from development? What is the exclusion tactics become questionable? What is the exclusion is driven by non-technical motifs? What is the exclusion is more to do with one persons opposition to the opinions of another? How does this relate to the Avalon PMC - because just as the Jakarta PMC has had to intervene with respect to the Steve/Pete scenario - there is the chance that the Avalon PMC may need or be requested to do the same (but hopefully not). The only difference is that should such a situation arise, an Avalon PMC will be much better equipped to deal with the situation quickly and effectively therby avoiding escalation.As I understand it, if agreeing with the vision of the project is aAs 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.
requirement for voting rights, then it follows that the moment you do not
agree with the vision you lose the right to vote.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@;osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
