Re: moving on

[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