Hmm...looks like we are on the same page :) i am glad. -- dims
On 2/20/06, Hiram Chirino <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > >> On 20 Feb 2006, at 11:04, [EMAIL PROTECTED] wrote: > >>> From: "Noel J. Bergman" <[EMAIL PROTECTED]> > >>> 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/
