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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
