Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of james.strachan@gmail.com
 designates 66.249.92.200 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer;
        b=n3gkhals6rHS6gumWqv1h8AWo1FGOnvq2fwpBRQMfJ9DsLIp0vW8NffLPZnW+kkk0JYoLfHRt6DdNVDJGAQVqJQFz/7wDPu+ATE8BQkHIjYQbGd1F+Un2ovAK3l69SyzEY9ZJI3ghCjxe/C7U5Aph90yizFF5n2+h+UIK3S2X6A=
In-Reply-To: <1140181090.25299.10.camel@localhost.localdomain>
References: <52b3da2a0602160739o638b2d04ib61b460b55a775fb@mail.gmail.com>
 <NBBBJGEAGJAKLIDBKJOPMEDGGIAC.noel@devtech.com>
 <52b3da2a0602160841w6f6e931v6ca2e4a1d70b1359@mail.gmail.com>
 <D47F85AB-64E6-44E4-9317-91023A60BAEB@gmail.com>
 <1140129656.3182.20.camel@localhost.localdomain>
 <1C14B30B-85B6-459E-ABFE-E649868C59DC@gmail.com>
 <1140177588.25299.7.camel@localhost.localdomain>
 <8AB8256E-1F91-42DF-8717-448D157F6328@gmail.com>
 <1140181090.25299.10.camel@localhost.localdomain>
Mime-Version: 1.0 (Apple Message framework v746.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <45848AC0-C673-427D-9C07-D05CA3D83AFE@gmail.com>
Cc: "Noel J. Bergman" <noel@devtech.com>,
 Bill Flood <bill.f.flood@gmail.com>
Content-Transfer-Encoding: 7bit
From: James Strachan <james.strachan@gmail.com>
Subject: Re: Ode / BPEL Donation of BPEL 2.0 Engine
Date: Fri, 17 Feb 2006 15:56:36 +0000
To: general@incubator.apache.org

On 17 Feb 2006, at 12:58, Sanjiva Weerawarana wrote:
> My concern is that the proposed path

I wasn't proposing a specific path, just highlighting issues we'll  
have if we assume the "only one engine" approach.


> is one where there's little
> convergence in the near term

FWIW convergence will happen however many projects we use


> and where the single incubating project
> releases multiple files on their own schedules. That's fine, but  
> that's
> not one project.

It depends on how you define a project.

There are many moving pieces; today they are all separate, over time  
they will merge together in some way.  If we're including the Agila  
code and maybe the BPEL4People code (if thats separate - haven't  
looked at it yet), we might have 5 completely different code bases  
all solving different problems in different ways. Turning those into  
"one engine" might not be possible any time soon - it might not even  
make sense to do so ever; at the same time each of these 5+ codebases  
have users somewhere.

I don't think in the grand scheme of things it makes a massive  
difference how many individual modules we have and at what  
granularity they are released (by release here I'm not necessarily  
talking post-incubator official release, I just mean making some  
kinda milestone that users can actually work with). Most reasonably  
complex Java software is made up of many modules; often different  
modules that implement the same feature but in different ways.

So we could do this in one project if we allow it to be modular and  
for the parts to be released (even as a milestone) as and when they  
are ready & have user demand.


> What's the point of being one project if there's no viable plan to  
> make
> the code marry?

To unite the community and encourage them to work together and share  
code.

I don't think uniting the community under one project necessarily  
means that we absolutely must force everything into one unified  
engine just to release some code to users. e.g. what if we never  
reach agreement? What if X% of the community want engine A and Y% of  
the community want engine B - imagine the voting fun when folks try  
to release B?

So I'm wondering if it might make sense to start the incubation  
process as an umbrella project; we let the code move into whatever  
modules as we think we need (which will change over time) - including  
allowing multiple implementations to coexist for however long we  
think is necessary. Then we let the modules have their own lifecycles  
and see how we get on. It might be we release everything in one go;  
or release in N different parts. I don't know the answer yet - I'm  
just raising a red flag that waiting for complete consensus across 5  
different codebases as to what the one-true-engine is just doesn't  
seem practical.

e.g. imagine a Jakarta Commons-like model for a second. Its got lots  
of modules that do lots of different things all developed under one  
project by one community; now in the orchestration/correlation/bpel/ 
human workflow space we are hopefully talking a much more focussed  
and less diverse area than Jakarta Commons - there may only be 1-3  
modules (who knows when we start adding tooling and human workflow  
there may be many modules) - but the general principle of different  
modules that live on their own, yet developed by the community at  
large - could work well here.

Over time I hope we merge modules together and promote code reuse; it  
may be we need to diversify too (e.g. different persistence modules,  
state machines v pi calculus etc). If the community decides to split  
off a piece (like commons-httpclient) then that's all well and good -  
but generally the community works together and we share code & ideas  
incrementally without forcing "one engine".

If we don't go for some kind of umbrella project then I'd suggest  
starting things with separate podlings to begin with and then seeing  
where the common areas for reuse lie during the incubation process.  
But given the problem space I think an umbrella-style project  
(restricted to all things orchestration/correlation/bpel/workflow)  
could well work.

One of the aims of the incubator is to develop communities; why don't  
we start with one community with the goal to make orchestration/bpel/ 
workflow software in a single project, import all the modules, let  
each module have its own lifecycle and see what happens. Then further  
down the road we can start deciding whether or not we should split  
parts of into separate podlings or not. I think its gonna take quite  
a bit of incubation before we really know what all the parts are  
gonna be - so why don't we stay as flexible as we can be in the early  
stages of incubation and see what happens? We then can always change  
our minds further down the line once we've had a chance to work  
together as a community on the code.


> I of course know the task is complex and indeed was
> quite surprised when everyone was willing to say "merge 'em all"

I think the desire is more to unite the community together - than to  
"merge them all into one engine". I'm not sure if anyone seriously  
thinks there will ever be one single engine for all use cases of  
orchestration/correlation/BPEL/human workflow; whether or not there  
is one single engine or several doesn't matter much really - whats  
more important is we try to work together and share as much code and  
ideas as possible.


> but
> there's no point at all in pretending we're merging if the task is
> indeed too complex.

I think we're all agreed that merging is complex; will take a lot of  
time and we've no real idea as yet how much code will get merged and  
what code we'll be left with at the end. Though as well I think we're  
all agreed that uniting the community together is a good thing too -  
I just think we need to keep things flexible and modular.

BTW its worth mentioning that currently Agila consists of 2  
completely different code bases existing side-by-side - they have  
been separate code bases for 1 year or so. So I don't see a problem  
with starting the incubation process as a single umbrella project -  
unless folks think it will restrict the ability for us to make  
milestone releases of the Sybase & PXE code during incubation?

James
-------
http://radio.weblogs.com/0112098/


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org