Peter Donald wrote:
I've been reading this thread and *finally* we got to the core of our problems, and are able to sort them out :-)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".
With discussions @ incubaror, community, and many other places, I've reached the conclusion that *all* of the people speaking here are right.
*All* of them.
Peter (et all) is right, you should vote if you are active.
Stephen (et all) is right, we should not fracture.
There is a simple way of doing this: _ONE CODEBASE_
How the *heck* do you guys think we can move along _a_ project when effectively we have *dozens* of them?!?!?
Imagine this: One Avalon, One Framework, One implementation.
Many *proposals*.
And when one wants to challenge the main codebase, he can with the "rules for revolutionaries", by making us switch from proposal to main codebase [http://incubator.apache.org/rules-for-revolutionaries.html]
This is roughly what I envision:
1) We form an Avalon PMC *now*, and have it made active at ApacheCon.
2) We make a new CVS module calles "avalon", and start voting package by package, class by class, about what to include in the new module, and commit then one by one.
2-note) ATM we have *no* implementation to commit.
3) We discuss about a common container, and *that* will go in Avalon. Will it take months? Years? I don't care. If it can be done, it will, else it means it can't be done (here at least).
4) In the meantime, all the containers move to avalon/scratchpad/mycomtainer*/**
5) In the meantime we move the Excalibur Components to Apache Commons, by clearly stating their container dependencies.
It will take months, and hard work, but IMHO it's workable.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
