> From: Leo Sutic [mailto:[EMAIL PROTECTED]] > > Yet the way such concensus based development would work may not > be ideal - in particular, the scope of the concensus may be too > wide. > > The problem, as I see it is this: > > + We need a very stable framework. Concensus here is vital.
It has been the model of what it means for consensus. There are a number of varying different oppinions. I agree that Framework needs to be something we all agree on. That also means that alot of really neat ideas don't become part of Framework. Using a standard mechanism to extend the base Framework will help in experimenting with ideas and proving their worth. That way we have imperical data on what it means to incorporate the new contracts that a new lifecycle interface would entail. We know what it takes to implement a feature. We have something now that we can vote on whether it becomes part of Framework or not. Until such a time, the best we can do is mental masturbation. "It would be nice if...." and after going down the path you find that there is no nice way to implement it--but you have to because it is part of Framework.... > + We can not develop a framework from first assumptions, > that is, the framework must be tried by users so we get > feedback. Exactly. Hense the common extension mechanism (it does not have to follow what both Fortress and Merlin agreed upon). > + In order to have the product tested by users, we must have > a compelling product. Correct. > + As users will only consider a product compelling if it solves > their needs, that product will have to evolve to meet those > needs. Correct. But does that mean we have a reference implementation, and then point others to a more robust solution (possibly hosted by a non-apache location)? > + The rate of evolution for the product and the framework > will be different. The framework will only adopt the parts > of the product that "worked", and will thus evolve more > slowly. Yes, but the Framework should not define anything about the container's implementation. Just its contracts with the components. We have to supply a compliance test suite. That way we can have an Avalon Test Compliance icon that can be used to endorse other containers. That gives users the confidence to try other containers with the full confidence that they have something that will support their application. > Now, how do we handle those shear forces we have due to the > different rates of evolution? Same way we always have. Containers are not part of the Framework, but Framework needs to reflect not only the contracts of the component to the container, but the container to the component. > A question: what is the smallest unit that can claim concensus? > Avalon does not need the consensus of Jakarta-Commons, we can > vote ourselves. At the same time, I don't want one person > creating a subproject of Avalon, declaring that he owns that > code and that his own opinion is equal to concensus. Check the three tiered proposal. > In short, is there any way to decouple Phoenix from Avalon > in such a way so that *all* PMC members need not vote on > *every* change to Phoenix, yet keep Phoenix from sliding > away to a little isolated group of its own? PMC members do not vote on Phoenix technical direction. Avalon committers vote on Phoenix technical direction. The fact that some of the committers happen to be PMC members is only a coincidence. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
