Reading this, I think we're danger of being a little over-optimistic for M5
scope.

I'd be keen to take a more considered approach to scoping M5, with estimates
(very much ballpark) on the existing JIRAs we're looking at implementing. On
the Java broker side, we need to focus on robustness and reliability
(defects) as much as new features.

The build window for a March release is around 55 days (allowing for some
testing time). Not a huge amount, given utilisation etc. Might be good to
get people to start bagging the JIRAs they plan to work on in M5 and see
what we have from there. This would give us a tangible basis for a plan. And
it'd be nice to have one of those (loose & JIRA based) to make the release
easier to close out.

If the features on the page for M5 are more, shall we say, aspirational -
let's use them as a roadmap for 2009.

Just my tuppence. I'll be assigning JIRAs out across my friends & colleagues
when we have agreed what we're doing locally. That should help a bit.

Regards,
Marnie

On Thu, Jan 15, 2009 at 9:38 AM, Aidan Skinner <aidan.skin...@gmail.com>wrote:

> On Wed, Jan 14, 2009 at 6:18 PM, Gordon Sim <g...@redhat.com> wrote:
>
> > One specific question I'd like to raise is getting interop between all
> > components. I think that is a very important goal. Can we manage it for
> the
> > next release? I think the best way to do that would be 0-10 support for
> the
> > java broker.
>
> Adding more multiprotocol support to the java broker is definately
> something we should do. There'd need to be a bit of work done on
> modularisation[1] so that things don't get really horrid. 0-10 is a
> somewhat different beast from 0-8/0-9, and 1-0 looks substantially
> different as well. If we're talking about M5 in ~ a couple of months
> that's quite a lot of work to do in a relatively short time.
>
> - Aidan
>
> [1] See http://qpid.apache.org/java-broker-modularisation.html for
> some ideas on how that would look
>
> --
> Apache Qpid - World Domination through Advanced Message Queueing
> http://qpid.apache.org
>

Reply via email to