You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rafael Schloming <ra...@redhat.com> on 2009/01/09 01:41:43 UTC
[Vote] Release RC8 as M4
Here's RC8. The only change from RC7 is the fix for the header files
that Ted mentioned:
http://people.apache.org/~rhs/qpid-M4-RC8/
--Rafael
Re: RDMA buffers and maxFrameSize
Posted by Gordon Sim <gs...@redhat.com>.
gregory james marsh wrote:
>
>
> Hi,
>
> I'm looking into the use of Infiniband send/recv Buffers (ibv_reg_mr) in
> the C++ RDMA connector code (M4 RC3). As far as I can tell, the buffer
> size is based on the ConnectionSettings.maxFrameSize specified by the
> client via the following object chain:
>
> ConnectionSettings.maxFrameSize
> |
> RdmaConnector
> |
> ConnectionParams.maxRecvBufferSize
> |
> AsynchIO.bufferSize
> |
> createBuffer(bufferSize)
>
> I've noticed that default maxFrameSize is 65535 and clients can set it
> LOWER without any problem. I tried setting it to 200,000 just to see
> what would happen. It appears the code iteratively tries to reduce
> large maxFrameSizes to something below 65535:
>
> $ grep createBuffer broker_trace.txt // My own tracing
> rdma_wrap.h: QueuePair: createBuffer(3392)
> rdma_wrap.h: QueuePair: createBuffer(3392)
The maximum frame size is a 16 bit value so 65535 bytes is the maximum
value it can take. The 3392 value is the result of truncating 200000 to
16 bits.
RDMA buffers and maxFrameSize
Posted by gregory james marsh <ma...@cse.ohio-state.edu>.
Hi,
I'm looking into the use of Infiniband send/recv Buffers (ibv_reg_mr) in
the C++ RDMA connector code (M4 RC3). As far as I can tell, the buffer
size is based on the ConnectionSettings.maxFrameSize specified by the
client via the following object chain:
ConnectionSettings.maxFrameSize
|
RdmaConnector
|
ConnectionParams.maxRecvBufferSize
|
AsynchIO.bufferSize
|
createBuffer(bufferSize)
I've noticed that default maxFrameSize is 65535 and clients can set it
LOWER without any problem. I tried setting it to 200,000 just to see what
would happen. It appears the code iteratively tries to reduce large
maxFrameSizes to something below 65535:
$ grep createBuffer broker_trace.txt // My own tracing
rdma_wrap.h: QueuePair: createBuffer(3392)
rdma_wrap.h: QueuePair: createBuffer(3392)
.
.
$ grep "createBuffer(3392)" broker_trace.txt | wc -l
128 // 64 each for send & recv
Here is the calculation that appears to happen:
3392 = 200,000 - (65536 * 3)
This appears to be over compensation for too large of maxFrameSize. Could
someone point me to the file in the code base where this adjustment is
happening, I'd like to experiment a bit.
Thanks,
Gregory Marsh
Re: [Vote] Release RC8 as M4
Posted by Rafael Schloming <ra...@redhat.com>.
Ted Ross wrote:
> Carl Trieloff wrote:
>> Rafael Schloming wrote:
>>> Here's RC8. The only change from RC7 is the fix for the header files
>>> that Ted mentioned:
>>>
>>> http://people.apache.org/~rhs/qpid-M4-RC8/
>>>
>>> --Rafael
>>
>>
>> If Ted and Steve and verify the two issues have been corrected, as you
>> know what to look for.
>>
>> Thanks
>> Carl.
> I've verified that the packaging problem has been solved.
>
> There's a regression (introduced in 727362) that causes the qpid-config
> utility to fail when using Python versions earlier than 2.5. This has
> been fixed on the trunk and on the M4 branch but is not in the RC8 tag.
> It might be prudent to pick this up for the final M4.
I'll be doing a respin tomorrow morning to build an RC9 that includes
this fix, a fix from Aidan, and a fix from Rajith for an SSL connection
closing issue.
--Rafael
Re: [Vote] Release RC8 as M4
Posted by Ted Ross <tr...@redhat.com>.
Carl Trieloff wrote:
> Rafael Schloming wrote:
>> Here's RC8. The only change from RC7 is the fix for the header files
>> that Ted mentioned:
>>
>> http://people.apache.org/~rhs/qpid-M4-RC8/
>>
>> --Rafael
>
>
> If Ted and Steve and verify the two issues have been corrected, as you
> know what to look for.
>
> Thanks
> Carl.
I've verified that the packaging problem has been solved.
There's a regression (introduced in 727362) that causes the qpid-config
utility to fail when using Python versions earlier than 2.5. This has
been fixed on the trunk and on the M4 branch but is not in the RC8 tag.
It might be prudent to pick this up for the final M4.
-Ted
Re: [Vote] Release RC8 as M4
Posted by Carl Trieloff <cc...@redhat.com>.
Rafael Schloming wrote:
> Here's RC8. The only change from RC7 is the fix for the header files
> that Ted mentioned:
>
> http://people.apache.org/~rhs/qpid-M4-RC8/
>
> --Rafael
If Ted and Steve and verify the two issues have been corrected, as you
know what to look for.
Thanks
Carl.
Re: Planning M5/ or whatever we call it
Posted by Carl Trieloff <cc...@redhat.com>.
Danushka Menikkumbura wrote:
>
>>
>> We need to pick a close down date for M5, and then it would be good for
>> everyone to list the key things they want to do for it. I have started a
>> list here:
>> http://cwiki.apache.org/confluence/display/qpid/looking+to+pitch+in
>>
>> Please add / edit as needed. I am thinking close down for M5 in March.
>>
>> Regards
>> Carl.
>>
> Hi Carl,
>
> I am supposed to work on the C++ broker message priority, had very
> little time to look into it though. I will continue to work on that. I
> have started to work on the Windows client build from command line
> already. (without knowing that it was there on your list). I have a
> couple of concerns related to that and the build systems as a whole.
great, my list does not mean I will work on all those items... it is
just what I would like to see :-)
>
> 1. In source generation, the generated makefiles, rubygen.mk and
> managementgen.mk have header files listed under source variables. It
> is quite useful if we can get the source generator to omit them.
>
> 2. Its better if we can have separate directories for IDE files (ides)
> and build scripts (build) so that the root is not cluttered with all
> sorts of build scripts.
>
>
I don't have a windows build env on my machine, so am not the best to
comment on these two points. If needed I can put it into a guest if
other on the list needed extra input on the topic.
Carl.
Re: Planning M5/ or whatever we call it
Posted by Danushka Menikkumbura <da...@wso2.com>.
Hi Steve,
>
> This can also be customized with the MPC tool... Let's talk more about
> what the ultimate goal of this effort is.
>
The idea is to let anybody having an Express Edition of VS and the
Platform SDK installed on his system manage Qpid build with nmake. I
strongly believe we should have a command line build facility for Qpid
on Windows. If we take Axis2/C for an example, we can build it on
Windows from command line and I think most of the people find it quite
useful.
I never knew that you had the MPC scripts with you already :). Why don't
you go ahead and generate the nmake makefiles so that most of the devs
who prefer nmake would be benefited?.
Its quite nice if we can have the nmake build scripts and the IDE
projects in separate directories. Again this is how we have the build
scripts in Axis2/C. I dont say we should stick to how things are done
there, but that looks quite organized. (at least to me :))
Thanks,
Danushka
--
Danushka Menikkumbura
Technical Lead, WSO2 Inc.
blog : http://danushka-menikkumbura.blogspot.com/
http://wso2.com/ - "The Open Source SOA Company"
RE: Planning M5/ or whatever we call it
Posted by Steve Huston <sh...@riverace.com>.
Hi Danushka,
> > We need to pick a close down date for M5, and then it would
> be good for
> > everyone to list the key things they want to do for it. I
> have started a
> > list here:
> >
http://cwiki.apache.org/confluence/display/qpid/looking+to+pitch+in
> >
> Hi Carl,
>
> I have started to work on the Windows client build from command line
> already. (without knowing that it was there on your list). I have a
> couple of concerns related to that and the build systems as a whole.
What is the general desire here? I can easily generate different
format files with the tool that generates the VC9 .vcproj/.sln files.
> 1. In source generation, the generated makefiles, rubygen.mk and
> managementgen.mk have header files listed under source
> variables. It is
> quite useful if we can get the source generator to omit them.
>
> 2. Its better if we can have separate directories for IDE
> files (ides)
> and build scripts (build) so that the root is not cluttered with all
> sorts of build scripts.
This can also be customized with the MPC tool... Let's talk more about
what the ultimate goal of this effort is.
Thanks,
-Steve
Re: Planning M5/ or whatever we call it
Posted by Danushka Menikkumbura <da...@wso2.com>.
>
> We need to pick a close down date for M5, and then it would be good for
> everyone to list the key things they want to do for it. I have started a
> list here:
> http://cwiki.apache.org/confluence/display/qpid/looking+to+pitch+in
>
> Please add / edit as needed. I am thinking close down for M5 in March.
>
> Regards
> Carl.
>
Hi Carl,
I am supposed to work on the C++ broker message priority, had very
little time to look into it though. I will continue to work on that. I
have started to work on the Windows client build from command line
already. (without knowing that it was there on your list). I have a
couple of concerns related to that and the build systems as a whole.
1. In source generation, the generated makefiles, rubygen.mk and
managementgen.mk have header files listed under source variables. It is
quite useful if we can get the source generator to omit them.
2. Its better if we can have separate directories for IDE files (ides)
and build scripts (build) so that the root is not cluttered with all
sorts of build scripts.
Danushka
--
Danushka Menikkumbura
Technical Lead, WSO2 Inc.
blog : http://danushka-menikkumbura.blogspot.com/
http://wso2.com/ - "The Open Source SOA Company"
Re: Planning M5/ or whatever we call it
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi Carl,
Will update once I've completed some final planning this end. My impression
is that the list is large on the Java side with some complex pieces of work.
>From my pov, Flow To Disk is getting urgent and more compelling than some
other changes - this'd be my choice of big ticket item. Ill update the wiki
page shortly.
Regards,
Marnie
On Mon, Jan 12, 2009 at 9:53 PM, Carl Trieloff <cc...@redhat.com>wrote:
>
> We need to pick a close down date for M5, and then it would be good for
> everyone to list the key things they want to do for it. I have started a
> list here:
> http://cwiki.apache.org/confluence/display/qpid/looking+to+pitch+in
>
> Please add / edit as needed. I am thinking close down for M5 in March.
>
> Regards
> Carl.
>
Re: Planning M5/ or whatever we call it
Posted by Robert Greig <ro...@gmail.com>.
2009/1/14 Gordon Sim <gs...@redhat.com>:
> On the c++ side I would personally like to see a relatively light list of
> features (selectors, priorities) with more focus on consolidation (e.g.
> ensuring that federation, clustering, ssl, sasl security layers, rdma etc
> all work well in combination) and perhaps some work on performance.
>
> I'd also like to make sure we have plenty of time so that we can ensure the
> out-of-box experience across all components (individually and as a
> collective) is as good as we can make it.
>
> 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.
I completely agree with all of this. I think qpid has a very good
featureset now (the two items listed above for C++ would definitely be
worth adding though) and the key now must be to broaden adoption by
ensuring that everyone can start using it quickly. This would include
things like ensuring qpid works well with Mule, CXF etc. as well as
any .NET WCF frameworks.
RG
Re: Planning M5/ or whatever we call it
Posted by Gordon Sim <gs...@redhat.com>.
Aidan Skinner wrote:
> On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim <gs...@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.
>
> Small, iterative improvements and frequent releases tends to go more
> smoothly than hackfest + big push.
Fair enough; thats hard to argue with!
Re: Planning M5/ or whatever we call it
Posted by Aidan Skinner <ai...@gmail.com>.
On 1/15/09, Robert Greig <ro...@gmail.com> wrote:
> 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?
No, which is why I suggested the bits of refactoring that are at the
"good hygiene and cleanliness" end of the spectrum rather than the
"rip it out with a chainsaw, throw it up in the air and put it back
together with a blowtorch" end.
The I/O stuff is mostly about decoupling the protocol handler from
MINA, particularly the reliance on MINA byte buffers.
The seperation of the store into a transaction log and a disk store is
similary more about simplyfying (sp!) existing code, in this case
seperating message body storage and retrieval from metadata.
> And I really think we should bin this silly Mx release numbering convention:-)
That's an entirely different barrell of fish kettles full of worms. My
opinon hasn't changed since we discussed this in August:
http://mail-archives.apache.org/mod_mbox/incubator-qpid-dev/200808.mbox/%3Ca4265f2a0808220232v6fc79992ja174c9db2ad46167@mail.gmail.com%3E
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
Re: Planning M5/ or whatever we call it
Posted by Carl Trieloff <cc...@redhat.com>.
Robert Greig wrote:
> 2009/1/15 Aidan Skinner <ai...@gmail.com>:
>
>> On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim <gs...@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.
based on this reasoning which I think is solid, we should pick a release
and hit it hard with
the refactoring we want to do.
Carl.
Re: Planning M5/ or whatever we call it
Posted by Carl Trieloff <cc...@redhat.com>.
> And I really think we should bin this silly Mx release numbering convention:-)
>
>
+1
For 5 I vote we drop the M.
Carl.
Re: Planning M5/ or whatever we call it
Posted by Marnie McCormack <ma...@googlemail.com>.
Probably not.
On Fri, Jan 16, 2009 at 2:11 PM, Carl Trieloff <cc...@redhat.com>wrote:
>
> Is the updated ACL for Java going to be committed for 5?
>
> Carl.
>
Re: Planning M5/ or whatever we call it
Posted by Carl Trieloff <cc...@redhat.com>.
Is the updated ACL for Java going to be committed for 5?
Carl.
Re: Planning M5/ or whatever we call it
Posted by Marnie McCormack <ma...@googlemail.com>.
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 <ro...@gmail.com>wrote:
> 2009/1/15 Aidan Skinner <ai...@gmail.com>:
> > On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim <gs...@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
>
Re: Planning M5/ or whatever we call it
Posted by Robert Greig <ro...@gmail.com>.
2009/1/15 Aidan Skinner <ai...@gmail.com>:
> On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim <gs...@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
Re: Planning M5/ or whatever we call it
Posted by Aidan Skinner <ai...@apache.org>.
On Thu, Jan 15, 2009 at 3:53 PM, Marnie McCormack
<ma...@googlemail.com> wrote:
> Let's try to narrow this list down a bit for a target M5 timescale ?
>
> As we've chatted about, I agree we should timebox our releases. But I think
> the Doctor might struggle with that lot before end March :-)
Obviously it depends on how many people are working on it. I think I
could manage the changes to the store interface and contribute some
work on the test coverage front.
Other people have expressed an interest in working on the transport
layer, so hopefully they might speak up?
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
Re: Planning M5/ or whatever we call it
Posted by Marnie McCormack <ma...@googlemail.com>.
Let's try to narrow this list down a bit for a target M5 timescale ?
As we've chatted about, I agree we should timebox our releases. But I think
the Doctor might struggle with that lot before end March :-)
Bfn,
Marnie
On Thu, Jan 15, 2009 at 2:40 PM, Aidan Skinner <ai...@apache.org> wrote:
> On Thu, Jan 15, 2009 at 2:26 PM, Marnie McCormack
> <ma...@googlemail.com> wrote:
> > On Thu, Jan 15, 2009 at 1:44 PM, Aidan Skinner <aidan.skinner@gmail.com
> >wrote:
> >
> >> On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim <gs...@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.
> >>
> >> What refactoring would you propose for M5 ?
>
> The modularisation and decoupling described at
> http://qpid.apache.org/java-broker-modularisation.html
>
> I'd probably start with the event model, I/O layer and peristance
> interfaces.
>
> Flow to disk will be a lot easier to implement with a clear seperation
> between a transaction log and a retrieval store (which are really two
> separate things).
>
> The event model and I/O layer are the areas that will require the most
> modification for implementing additional protocols and are currently,
> IMVHO, the messiest. If this was done right it would also allow us to
> address the problem with unbounded buffers (QPID-1447 and friends).
>
> The session and model changes aren't as large, and don't have as much
> of an impact.
>
> - Aidan
> --
> Apache Qpid - World Domination through Advanced Message Queueing
> http://qpid.apache.org
>
Re: Planning M5/ or whatever we call it
Posted by Aidan Skinner <ai...@apache.org>.
On Thu, Jan 15, 2009 at 2:26 PM, Marnie McCormack
<ma...@googlemail.com> wrote:
> On Thu, Jan 15, 2009 at 1:44 PM, Aidan Skinner <ai...@gmail.com>wrote:
>
>> On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim <gs...@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.
>>
>> What refactoring would you propose for M5 ?
The modularisation and decoupling described at
http://qpid.apache.org/java-broker-modularisation.html
I'd probably start with the event model, I/O layer and peristance interfaces.
Flow to disk will be a lot easier to implement with a clear seperation
between a transaction log and a retrieval store (which are really two
separate things).
The event model and I/O layer are the areas that will require the most
modification for implementing additional protocols and are currently,
IMVHO, the messiest. If this was done right it would also allow us to
address the problem with unbounded buffers (QPID-1447 and friends).
The session and model changes aren't as large, and don't have as much
of an impact.
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
Re: Planning M5/ or whatever we call it
Posted by Marnie McCormack <ma...@googlemail.com>.
On Thu, Jan 15, 2009 at 1:44 PM, Aidan Skinner <ai...@gmail.com>wrote:
> On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim <gs...@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.
>
> What refactoring would you propose for M5 ?
Re: Planning M5/ or whatever we call it
Posted by Aidan Skinner <ai...@gmail.com>.
On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim <gs...@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.
Small, iterative improvements and frequent releases tends to go more
smoothly than hackfest + big push.
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
Re: Planning M5/ or whatever we call it
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi,
I think (and some of this I wasn't around for) that we had agreed that more
was more on the release front. Certainly it gives us more
confidence/motivation to keep everything in good shape on trunk (i.e. test
it !).
For the Java releases, I'd personally rather keep an early & frequent
approach to releasing and have goals for each one that match up (loosely)
with the time available and the commitment in people terms to tasks. We can
plan different release schedules for the verious components, with an
agreement around interop testing, though.
If people know that they're going to be working on, let's start there and
then see if anyone has any time left.
I should know what that looks like for me next week. How is everyone else
fixed in terms of shouting out what they plan to do ?
Interop is a definite goal and an important one for us all I agree. On the
Java broker side I have come around (personally) to thinking that Flow To
Disk blows everything else of the water in importance terms. Let's make our
broker survive (without yeuch recovery) in all cases then do everything
else. Just seeing how that plans in/out with available resources to make it
happen.
I think we'll need to talk about which changes to branch for - some things
on the list are pretty big items that might well span more than one release
cycle.
Again, just my penny's worth.
Hth,
Marnie
On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim <gs...@redhat.com> wrote:
> Marnie McCormack wrote:
>
>> The build window for a March release is around 55 days (allowing for some
>> testing time). Not a huge amount, given utilisation etc.
>>
>
> Maybe March is too soon?
>
> 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.
>
Re: Planning M5/ or whatever we call it
Posted by Carl Trieloff <cc...@redhat.com>.
Gordon Sim wrote:
> Marnie McCormack wrote:
>> The build window for a March release is around 55 days (allowing for
>> some
>> testing time). Not a huge amount, given utilisation etc.
>
> Maybe March is too soon?
I would say end April at the latest.
Carl.
Re: Planning M5/ or whatever we call it
Posted by Gordon Sim <gs...@redhat.com>.
Marnie McCormack wrote:
> The build window for a March release is around 55 days (allowing for some
> testing time). Not a huge amount, given utilisation etc.
Maybe March is too soon?
> 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.
Re: Planning M5/ or whatever we call it
Posted by Marnie McCormack <ma...@googlemail.com>.
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 <ai...@gmail.com>wrote:
> On Wed, Jan 14, 2009 at 6:18 PM, Gordon Sim <gs...@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
>
Re: Planning M5/ or whatever we call it
Posted by Aidan Skinner <ai...@gmail.com>.
On Wed, Jan 14, 2009 at 6:18 PM, Gordon Sim <gs...@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
Re: Planning M5/ or whatever we call it
Posted by Gordon Sim <gs...@redhat.com>.
Carl Trieloff wrote:
>
> We need to pick a close down date for M5, and then it would be good for
> everyone to list the key things they want to do for it. I have started a
> list here:
> http://cwiki.apache.org/confluence/display/qpid/looking+to+pitch+in
>
> Please add / edit as needed. I am thinking close down for M5 in March.
On the c++ side I would personally like to see a relatively light list
of features (selectors, priorities) with more focus on consolidation
(e.g. ensuring that federation, clustering, ssl, sasl security layers,
rdma etc all work well in combination) and perhaps some work on performance.
I'd also like to make sure we have plenty of time so that we can ensure
the out-of-box experience across all components (individually and as a
collective) is as good as we can make it.
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.
Re: Planning M5/ or whatever we call it
Posted by Carl Trieloff <cc...@redhat.com>.
Aidan Skinner wrote:
> On Mon, Jan 12, 2009 at 9:53 PM, Carl Trieloff <cc...@redhat.com> wrote:
>
>
>> We need to pick a close down date for M5, and then it would be good for
>> everyone to list the key things they want to do for it. I have started a
>> list here:
>> http://cwiki.apache.org/confluence/display/qpid/looking+to+pitch+in
>>
>
> Is there a reason not to use Jira for capturing this? Issues raised
> against a milestone would make producing the release notes at the end
> a lot easier.
>
> - Aidan
>
yes, it is easier to see the top level topics that people want to work
on in a list on a wiki page. I
would however agree that once we have a target list that we then break
it into JIRA. I expect that
some items might land up being a whole list of JIRA's, so this serves to
create a high level summary.
I also believe that the JIRA will have a bunch of bugs that we would
want to do in it. So I suggest
that we create the list on wiki, in parallel clean JIRA. Then add the
feature JIRA's from the wiki
to the JIRA at the end of the process
Carl.
Re: Planning M5/ or whatever we call it
Posted by Aidan Skinner <ai...@gmail.com>.
On Mon, Jan 12, 2009 at 9:53 PM, Carl Trieloff <cc...@redhat.com> wrote:
> We need to pick a close down date for M5, and then it would be good for
> everyone to list the key things they want to do for it. I have started a
> list here:
> http://cwiki.apache.org/confluence/display/qpid/looking+to+pitch+in
Is there a reason not to use Jira for capturing this? Issues raised
against a milestone would make producing the release notes at the end
a lot easier.
- Aidan
--
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org
Planning M5/ or whatever we call it
Posted by Carl Trieloff <cc...@redhat.com>.
We need to pick a close down date for M5, and then it would be good for
everyone to list the key things they want to do for it. I have started a
list here:
http://cwiki.apache.org/confluence/display/qpid/looking+to+pitch+in
Please add / edit as needed. I am thinking close down for M5 in March.
Regards
Carl.
Re: [Vote] Release RC8 as M4
Posted by Carl Trieloff <cc...@redhat.com>.
Steve Huston wrote:
>> Here's RC8. The only change from RC7 is the fix for the header files
>>
>
>
>> that Ted mentioned:
>>
>> http://people.apache.org/~rhs/qpid-M4-RC8/
>>
>
> +1
>
> Thanks!
> -Steve
>
>
+1 legal seems good, Carl.
Re: [Vote] Release RC8 as M4
Posted by Danushka Menikkumbura <da...@wso2.com>.
> Which artifact? The C++ release has generated code.
>
I tried cpp in qpid-M4. Sorry for not being specific.
Danushka
--
Danushka Menikkumbura
Technical Lead, WSO2 Inc.
blog : http://danushka-menikkumbura.blogspot.com/
http://wso2.com/ - "The Open Source SOA Company"
RE: [Vote] Release RC8 as M4
Posted by Steve Huston <sh...@riverace.com>.
Danushka Menikkumbura wrote:
> I do not see generated source in this artifact.
Which artifact? The C++ release has generated code.
-Steve
Re: [Vote] Release RC8 as M4
Posted by Carl Trieloff <cc...@redhat.com>.
Danushka Menikkumbura wrote:
> I do not see generated source in this artifact. Was it decided not to
> include generated source in the source dist?. (Sorry I did not follow
> most of the threads lately).
>
> Danushka
>
so far we have never included generated source
Carl.
Re: [Vote] Release RC8 as M4
Posted by Danushka Menikkumbura <da...@wso2.com>.
I do not see generated source in this artifact. Was it decided not to
include generated source in the source dist?. (Sorry I did not follow
most of the threads lately).
Danushka
--
Danushka Menikkumbura
Technical Lead, WSO2 Inc.
blog : http://danushka-menikkumbura.blogspot.com/
http://wso2.com/ - "The Open Source SOA Company"
RE: [Vote] Release RC8 as M4
Posted by Steve Huston <sh...@riverace.com>.
> Here's RC8. The only change from RC7 is the fix for the header files
> that Ted mentioned:
>
> http://people.apache.org/~rhs/qpid-M4-RC8/
+1
Thanks!
-Steve