You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2004/04/10 18:37:38 UTC
moving on (was Re: Opinion Gathering on Fortress)
Shash:
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:
* one avalon RI
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.
Cheers, Stephen.
Shash Chatterjee wrote:
>
>> I haven't yet discovered a solution which seems perfect to me.
>> Perhaps it is one of these but I need to give them more thought.
>>
>> Also, merlin is a much better candidate as a TLP. Fortress could
>> then stay in Avalon.
>
>
> As Leif and Hammett have said, there is no compelling reason for
> Fortress/Phoenix users to change containers currently. These containers
> need to be maintained and allowed to evolve gradually. As also has
> been mentioned, there are different sets of developers ready to support
> each container. I do not view breaking up the containers into either
> TLPs or, alternatively, Avalon sub-projects as a bad things; that
> politically and administratively demarcates the
> interface/implementation split that architecturally Avalon already has.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: moving on
Posted by Stephen McConnell <mc...@apache.org>.
Shash Chatterjee wrote:
> 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:
>>
>> * one avalon RI
>>
> 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.
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: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: moving on (was Re: Opinion Gathering on Fortress)
Posted by Shash Chatterjee <sh...@badfw.org>.
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:
>
> * one avalon RI
>
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. 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).
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.
> 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. 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 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.
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? 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.
Shash
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org