ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <hi...@hiramchirino.com>
Subject Re: Ode / BPEL Donation of BPEL 2.0 Engine
Date Mon, 20 Feb 2006 15:47:35 GMT
I'm glad we are vigorously agreeing :)

Regards,
Hiram

On Feb 20, 2006, at 10:43 AM, Davanum Srinivas wrote:

> Hmm...looks like we are on the same page :) i am glad.
>
> -- dims
>
> On 2/20/06, Hiram Chirino <hiram@hiramchirino.com> wrote:
>> Hi Dims,
>>
>> On Feb 20, 2006, at 10:18 AM, Davanum Srinivas wrote:
>>
>>> James,
>>>
>>> I *TOTALLY* see your point as an end user of ode. Am asking for some
>>> TLC from all parties to each other and to both the incoming code
>>> bases. and make sure we have an environment where we support each
>>> other and watch each other's backs, help each other and get things
>>> done so that all of us benefit from the work we do at Apache and be
>>> able to use this work in our day-to-day jobs and make sure we do the
>>> right thing for our end users of ODE.
>>
>> +1
>>
>>>
>>> The posting from Paul is a great start. I don't see the rank and  
>>> file
>>> people yet pouncing on it. I just saw ur reply. Let's lay the ground
>>> work so that everyone has their bit to say on technical stuff.  
>>> Once we
>>> get started, Let's set up some guidelines for an M1 release (sooner
>>> than later) and write down requirements IRRESPECTIVE of what code  
>>> will
>>
>> +1 Getting a early M1 release should be a top priority since both
>> code bases being donated are already extremely stable.  Lets not mess
>> up things by going to large reactors/re-designs for M1.  No point in
>> making a short incubator stay into a permanent living arrangement.
>>
>>> be used. Make sure that M1 looks good , solid and solves peoples
>>> problems rather than just be a check mark on someone's list. We  
>>> should
>>> not start off saying we will split....No, it is not going to be  
>>> easy.
>>
>> Nope, we are joining under ode.  But we will have multiple options
>> when it comes to running your BPEL processes.  I think choice is
>> good, and it's even better when the choice is given to you by 1  
>> project.
>>
>>> Yes, it may take time. Please have some patience as am sure we  
>>> are all
>>> stressed out right now and don't see an end in sight. Am sure if we
>>> put our best foot forward, we will come out better. Please don't  
>>> treat
>>> either codebases as final. they are the first step towards whatever
>>> goal we as a community want to achieve (which we have to define as
>>> well as we go along :)
>>
>> A final code base would not be fun at all.  :)
>> But hey, I agree lets not rush things.  Lets get our house in order,
>> make due with what we have today, build community and aim to have a
>> more cohesive design for the next version of ode.  Let's follow the
>> open source mantra of release early and release often.
>>
>> Regards,
>> Hiram
>>
>>>
>>> thanks,
>>> dims
>>>
>>> On 2/20/06, James Strachan <james.strachan@gmail.com> wrote:
>>>> On 20 Feb 2006, at 11:04, ode-dev-help@incubator.apache.org wrote:
>>>>> From: "Noel J. Bergman" <noel@devtech.com>
>>>>> Date: 18 February 2006 06:12:10 GMT
>>>>> Subject: RE: Ode / BPEL Donation of BPEL 2.0 Engine
>>>>>
>>>>>
>>>>> Considering that people have expressed the clear desire to develop
>>>>> joint
>>>>> work, an umbrella-style project housing multiple  
>>>>> implementations of
>>>>> the same
>>>>> domain, although probably workable for a period while the
>>>>> community's active
>>>>> focus is on the joint solution, if persisted into the long term
>>>>> usually
>>>>> leads to a balkanized project that breaks up.
>>>>
>>>> If the project has to split up into some different pieces thats  
>>>> fine
>>>> too. There's no reason why there has to be just one engine for all
>>>> our orchestration/BPEL/workflow needs. But if we can end up with  
>>>> just
>>>> one, hey thats great.
>>>>
>>>>
>>>>> The ASF has, as I noted on general@, no need to deal with
>>>>> independent
>>>>> releases of the vendor products.  For that matter, we couldn't  
>>>>> care
>>>>> less
>>>>> about anyone's delivery schedules.  Our releases occur when
>>>>> determined by
>>>>> our PMCs.  Vendors may have their own schedules, but our focus is
>>>>> building
>>>>> an ASF project.  If someone wants to do a release on their
>>>>> schedule, they
>>>>> are free to pull source code and use it in accordance with our
>>>>> license.
>>>>>
>>>>> James mentioned that ServiceMix has some needs to work with
>>>>> Sybase's code.
>>>>> I am sure that no one, *especially James*, wants anyone to have  
>>>>> the
>>>>> impression that ServiceMix is trying to co-opt the direction of  
>>>>> this
>>>>> separate project.
>>>>
>>>> Agreed - particularly as we've been working with PXE for over 6
>>>> months...
>>>>
>>>>
>>>>> The Sybase code will be available for anyone, including
>>>>> ServiceMix, to use as necessary, so you should feel free to pursue
>>>>> whatever
>>>>> direction is jointly chosen by this community.
>>>>
>>>> Agreed.
>>>>
>>>> I'm now taking off my Ode hat and putting on my ServiceMix hat just
>>>> to make things completely 100% explicit so you can understand  
>>>> exactly
>>>> where I've been coming from since I've been raising my little red
>>>> flag...
>>>>
>>>>
>>>> Lets assume that the Sybase code is imported into Ode (I'll call it
>>>> Foo from now on) and the PXE code is imported (lets call that Bar);
>>>> so Foo and Bar are both Ode code bases in the org.apache.ode
>>>> namespace, anyone can use them at Apache and they have nothing  
>>>> to do
>>>> with vendors releases etc. The first day they are imported Foo and
>>>> Bar will not reuse any of each others code; then over time we  
>>>> figure
>>>> out how to refactor Foo and Bar to reuse code etc.
>>>>
>>>> Now with just my ServiceMix hat on, I don't really mind if Foo and
>>>> Bar merge together 0%, 10%, 50% or 100%. So whether or not Foo and
>>>> Bar completely merge doesn't really interest me a whole lot  
>>>> right now
>>>> - I'm totally happy if further down the road we decide that Foo and
>>>> Bar should not be completely merged and instead focus on what  
>>>> can be
>>>> shared.
>>>>
>>>>
>>>> Now as soon as Foo arrives at Apache we'll be using it in  
>>>> ServiceMix
>>>> and contributing patches to ease the integration and fix any issues
>>>> we find. We've been using PXE for over 6 months & currently use a
>>>> slightly old version of PXE. We tried to use the latest greatest  
>>>> and
>>>> found some problems. So the very day that Bar is checked into  
>>>> Apache
>>>> we will immediately move from PXE to Bar and work on the code to  
>>>> make
>>>> sure it works inside ServiceMix which will probably result in some
>>>> patches for Bar.
>>>>
>>>> So before the real meat of the unification gets done on Ode,  
>>>> we'll be
>>>> working on both the Foo and Bar codebases and providing an
>>>> integration test to both libraries and their integration with JBI.
>>>> This integration test will be useful as the unification process  
>>>> takes
>>>> place - plus there's no better way of providing input on 2  
>>>> codebases
>>>> than by using them both :)
>>>>
>>>> The little red flag I've been waving lately - which in the grand
>>>> scheme of things is no big deal - is purely that as an end user of
>>>> both Foo and Bar, I'm going to want milestone releases of Foo  
>>>> and Bar
>>>> fairly soon, plus at significant points of the unification. Up  
>>>> to now
>>>> an incubating podling tends to just have 1 release; whereas I think
>>>> it makes sense for the Ode project to support multiple releases of
>>>> Foo and Bar while we go on the unification journey and see where we
>>>> end up.
>>>>
>>>>
>>>> BTW Dims, please don't see this little wave of a red flag as me  
>>>> being
>>>> negative; I'm really excited by the Ode project and am sure its  
>>>> gonna
>>>> be a great success - I just want the project to start on the right
>>>> footing so we don't end up with unnecessary friction or worse,
>>>> another Avalon.
>>>>
>>>> James
>>>> -------
>>>> http://radio.weblogs.com/0112098/
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Davanum Srinivas : http://wso2.com/blogs/
>>
>>
>
>
> --
> Davanum Srinivas : http://wso2.com/blogs/


Mime
View raw message