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/

Reply via email to