Stephen,
The Avalon community took a vote on this subject and decided to resolve things with one architecture, one platform, one container. That decision has ripple effect which your currently witnessing - but the upside is that people are actually making decisions based on fact:I understand that. But as feedback before and after that vote has made it apparent, many users from the current base find that to be the incorrect decision.
* one avalon RI
We have a slightly different view here. What I'm seeing is a lot of existing users that want to see (a) protection of their existing investment, (b) an avenue for migration, (c) benefits arising from a united avalon product base.
New adopters of Avalon can go in droves for Merlin, as they are adopting something new in any case, but that does not mean much for current users. A vote happened, but nothing says that is cast in stone. It is up to us as a community to review decisions on a continual basis, and make error corrections to the course as necessary (I realize, not up to me individually, since I am not even a committer).
Your posting and expressing an opinion - that makes you part of the community.
It cannot be that we continually steer towards an impending shipwreck, just because we once took a vote and made what to many seems like a wrong decision. You and others in the PMC have the power to reevaluate and, if necessary, correct past decisions.
We can actually gain a great deal by looking at past decisions. If we look way back we can isolate one decision (stated or otherwise) concerning the two product strategy Phoenix and ECM. My involvement in avalon came about after that event and over the years I've learnt a few things about the implications of the separation. Two different products serving two different communities - very little overlap, and a progressive divergence in terms of interests.
The end result was literally two different communities within the same umbrella, sharing a think called framework (with different semantic interpretations), compromises due to respective pressures, but a willingness to accept a status quo. From a technical point of view it was just pull-based versus push-based COP .. but combine that with feature creep and you end up with different component models.
No consider evolution here in avalon - with multiple solutions every "common" step is a compromise to consensus. Because of this so many things that could have been achieved has not be achieved. If anything this is the single biggest cost of division.
This isn't about setting a context to get framework right - its about going way beyond framework and doing what Avalon has been chartered to do:
* component and service management
On the context of one RI and our charter, we do have a responsibility to provide a viable migration path. I hope that you'll contribute to that because there a lot of benefit in getting the migration process right. That benefit is all about one community working together on one platform. Looking further out its about going beyond "containers" - focusing much more on the bigger picture of an globally integrated service management environment. From this perspective the current issues concerning migration are short term and addressable - and a necessary part of moving on.
That is fantastic. I look forward to great advances in service management, and as I said in an earlier post, really look forward to a migration path to Merlin and its service management capabilities. I will also pitch in areas that pike my interest or need.
I really glad to hear this. You won't be alone!
But, we have a lot of inertia in existing projects that I don't ever see migrating to Merlin, even if there is a migration path;
I completely understand - and its one of the reasons that I prefer to see Fortress here at Avalon than elsewhere. Avalon is responsible for the products it releases and that means that we assure the binary user base that they are not hung-out-to-dry. At the same time .. there are developers that have already locked into a migration process - and that needs our attention.
I see new projects starting to take advantage of the new capabilities. The existing projects need stability in the framework interfaces, a way to get bug fixes, and take advantage of incremental advances in capability.
Irrespective on anything you read in all of the blogs out there - framework is not dissapearing. We have 4.1.5 today. I'm personally working on a 4.2 (with no change to interfaces - just some backward compatible semantics). Niclas is working on the big picture in terms of the next major iteration - but that's future space. Remember that for classic merlin users - the framework spec is the contract and that contract will be respected.
The reality is that currently Avalon is about containment. Merlin is the one forging ahead, it is new, its users are new. Why not leave Avalon as it is and form a new TLP for the future?
Because in doing so - we would destroy Avalon. Avalon not simply framework - it's the most significant initiative in COP on the face of the planet - it's the place where the next really big steps will be made (and I'm not talking about trivial things like Type X injection).
Within this context - Merlin is just one part of a platform. I agree with you today the container is in focus - but that's transient. There are so many related things to do that are at least peer subject relative to a container. That's why Avalon is much more important that a product called Merlin.
Those needing their mission-critical applications supported can get that. Those needing advance service management can get that too. It is a win-win for all, if we both support the status-quo as well as move ahead with a new model. It does not need to be either or, there are enough developers for both.
Irrespective of the head count - your still talking about the numbers of solders fighting for divergent product factions. Instead - I urge you to move on to United Avalon - one container, one architecture, one platform.
Cheers, Stephen.
Shash
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
