Looks like it's time for [EMAIL PROTECTED] Noel, is that setup yet?
thanks, dims On 2/17/06, James Strachan <[EMAIL PROTECTED]> wrote: > How about this for an idea of how we can get started (particularly if > the thought of another Jakarta Commons-like project scared some > people off :)... > > Agila already has 2 codebases inside it today; the original BPM and > Twister BPEL. > > So how about we start the Ode podling with the same structure - > containing the Sybase and PXE code in separate modules. > > Then inside the Ode podling we figure out over time what BPEL stuff > we can merge etc. Over time the Twister code could merge/move into > Ode. BPM code from Ode could move into Agila. Or we can merge > everything into Ode, or Agila can become the BPM project again and > Ode can be the BPEL project - we'll see, we can figure that out > later. But the structure from day one would be we'd have a new > podling with a similar structure to the existing Agila project. > > The only issue is users of Sybase or PXE will want milestone builds > so they can test against the incubating code & to give us feedback > that things are working etc. (e.g. we already test against PXE in > ServiceMix and we want to test against Sybase too and use ServiceMix > as an integration test case for any work done on the merge). > > So we don't really need a full "Jakarta Commons" type project > structure; just a way to allow some level of independent releases of > the Sybase & PXE codebases until the day when its all one single > engine. (The Agila project might want to do this too). > > I don't see anything in the current release policies that would > explicitly prohibit a podling from having, say, 2 different kinds of > release; say 'ode-pxe' and 'ode-bpe' or whatever we call them. > http://incubator.apache.org/incubation/Incubation_Policy.html#Releases > > Does this structure seem reasonable to everyone? > > > On 17 Feb 2006, at 15:56, James Strachan wrote: > > 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] > > > > > James > ------- > http://radio.weblogs.com/0112098/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Davanum Srinivas : http://wso2.com/blogs/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
