I agree, very well put RG !

In terms of the details, can people start assigning Release 5 JIRAs to
themselves and scoping them in, please? We can then update the
roadmap/feature list from the JIRAs people have identified for inclusion.

Regards,
Marnie

On Thu, Jan 15, 2009 at 8:14 PM, Robert Greig <robert.j.gr...@gmail.com>wrote:

> 2009/1/15 Aidan Skinner <aidan.skin...@gmail.com>:
> > On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim <g...@redhat.com> wrote:
> >
> >>> If the features on the page for M5 are more, shall we say, aspirational
> -
> >>> let's use them as a roadmap for 2009.
> >>
> >> I'm certainly keen on understanding how our roadmap will take us to the
> >> point where all Qpid components interoperate with each other. If it is
> not
> >> feasible for the next release thats fine.
> >
> > I suspect the most achievable way to approach this is to refactor the
> > broker and improve the test coverage for M5, then add extra protocols
> > after that.
>
> Let me play devil's advocate for a moment.
>
> I buy the argument that a full java multi-protocol bonanza is not
> achievable in M5 timeline. And I also agree that one of the key things
> users want is a stable product even in unforseen production
> circumstances, so flow to disk would seem to be an important feature
> to add for M5.
>
> So if we accept that M5 will be a stability release, do we want to
> risk destabilising other areas by performing signfiicant refactoring?
> Even with the best efforts for test coverage, you would have to be
> honest to potential users to say that there is some degree of risk in
> an M5 that also had significant refactoring.
>
> So with that logic I'm led to the conclusion that M5 should be a
> relatively focussed "stability and minor feature" release (for Java
> broker at least) before it embarks upon major upheaval for M6. M6 will
> probably really be a "point zero" release and users who demand total
> production stability would only look to pick up M7 or M8.
>
> And I really think we should bin this silly Mx release numbering
> convention:-)
>
> RG
>

Reply via email to