Berin Loritsch wrote:
Stephen McConnell wrote:
The subject is about a set of tags that describe the requirements a container has to fulfil for reliable and predictable component deployment. To achieve that we must either (a) provide a complete model, or (b) provide a model extension mechanism. One of the options described in the vote will only result in division and failure to achieve the objective. As such the vote calls for unification but presents a solution that will divide. Hopefully a majority of people will figure out that this vote is premature and that perhaps there are some important and unresolved issues to be addressed. If not, I guess its history repeating itself.
The problem is that the solution to these issues is not going to be easy.
By CMM/RUP standards that means we should tackle it first. By XP standards,
it means that we might want to take advantage of what we have already agreed
to, make a release, and expand when we know what we want to do later.
The practical approach is to use what we have already in place. It is an approach that ensures that the interests and concerns of all interested parties is addressed. It is also an approach that delivers what we promising now - validated - working - and complete.
I would like to fully address these issues, but I don't want to give the impression that the extensions are core supported Avalon tags until we have solved those issues.
Extensions became intrinsic to the component deployment model when we voted for the release of the excalibur-extension package (a vote that received your +1). At that point we said to everyone out there that there is a notion of lifecycle stage extensions in Avalon. We documented in that release the support for that abstraction in both Merlin and Fortress. There are simply no issues to solve - this is simply a matter of getting back to a process of collaboration.
That said, I would like to get a point release out there so that we can start
integrating Avalon Meta into Fortress and Phoenix (superceding what is currently
there).
Then please retract your vote and reconsider the subject with the interests of everyone involved.
We have some difficult issues ahead of us as we resolve how we want to handle
things like management extensions, ad-hoc instrumentation, lifecycle extensions,
etc. If we get the core stuff out there now, then people can start migrating
the currently defined components/containers to use the proper meta tags and
have something that we can play with in more than one container (i.e. Fortress
and Merlin).
We can do this now without introducing any fragmentation or division. Simply proceed with the platform we have.
We need to be clear that the extension mechanisms while they are really cool,
are still extensions. It lets people who are adventurous play first, thus
allowing us to gain a better understanding of the problem space and adopt the
viewpoints of others. By placing the extensions in the lifecycle namespace
now, it allows early adopters to play around with it, knowing it is alpha,
as we come up with the formal plan.
Please - you are completely ignoring the issue I've raised. The suggestion to split (delivering an incomplete solution under @avalon) combined with publication under avalon is something I cannot support. The implications of this proposal are far reaching. Things outside of @avalon will be ignored and there is nothing you can do about it. At least if we keep the model complete we have a fighting chance of turning this into something useful.
If we try to solve this now, we will essentially hold up development by a large
number of people/projects that really can use the standard for the core tags.
There is nothing to solve in the short term. A complete, viable, proven solution is in place.
Not everyone is interested in the extensions yet. I want to leverage the
existing momentum and help us move forward.
If you want to gain momentum, then please try another approach. You could consider this as a case of getting all of the players on board. That would suggest that a solution to this problem must address the intents of all parties without prejudice. So long as you try to engineer an outcome, you will not gain the momentum you seek. In fact, it will be (and are presently) achieving quite the opposite.
Who is to say that the extension
tags won't end up officially in the avalon namespace?
Spin this either way - what it comes down to is that your don't know. What you cannot deny is that this notion is in use, is appreciated, is relevant, is supported, is released, and is not less important than any other of the 10 abstractions we are discussing.
They very well may,
but by the time they get there, everyone will know how to use them and what
they enable. THen again, what finally does get adopted may be very different.
While they are being experimented with, I believe it is important not to have
them in the core avalon namespace.
Berin - please - this is not experimental stuff.
Otherwise we will end up with the equivalent
of the Component interface in our avalon tags. Arguing to hold up a potential
release and integration of the same tags library because we don't have
everything specified, seems to imply that we are closer to a solution than we
really are.
Can you at least agree to them being placed in an alternative namespace while
we hash out the implications with the goal that something enabling extensions
will be included in the avalon namespace when we are done? I would like to
do a release RSN so that we can start integration. When we solve those hard
problems, we can adopt the resolution. Does that sound fair?
Fair (within the context of this development community) means ensuring everyone's interests are addressed in what is the first step towards convergence of three containers. Fair means not putting up obstacles to convergence. Fair (towards our users) means being responsible and delivering a solution that will provide and deliver a common, complete solution where nothing is more or less important than anything else.
What I'm hoping for is that we:
* get back to the process of working together * stop once and for all this process of selective discrimination * do something that address everyone needs
Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
