ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas" <dava...@gmail.com>
Subject Re: Ode / BPEL Donation of BPEL 2.0 Engine
Date Mon, 20 Feb 2006 15:18:46 GMT

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.

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
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.
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 :)


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/

View raw message