Re: Planning M5/ or whatever we call it
On 1/15/09, Robert Greig 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/%3ca4265f2a0808220232v6fc79992ja174c9db2ad46...@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
Probably not. On Fri, Jan 16, 2009 at 2:11 PM, Carl Trieloff wrote: > > Is the updated ACL for Java going to be committed for 5? > > Carl. >
Re: Planning M5/ or whatever we call it
Is the updated ACL for Java going to be committed for 5? Carl.
Re: Planning M5/ or whatever we call it
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 wrote: > 2009/1/15 Aidan Skinner : > > On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim 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
Robert Greig wrote: 2009/1/15 Aidan Skinner : On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim 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
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
2009/1/15 Aidan Skinner : > On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim 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
On Thu, Jan 15, 2009 at 3:53 PM, Marnie McCormack 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
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 wrote: > On Thu, Jan 15, 2009 at 2:26 PM, Marnie McCormack > wrote: > > On Thu, Jan 15, 2009 at 1:44 PM, Aidan Skinner >wrote: > > > >> On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim 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
On Thu, Jan 15, 2009 at 2:26 PM, Marnie McCormack wrote: > On Thu, Jan 15, 2009 at 1:44 PM, Aidan Skinner wrote: > >> On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim 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
On Thu, Jan 15, 2009 at 1:44 PM, Aidan Skinner wrote: > On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim 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
Aidan Skinner wrote: On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim 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
On Thu, Jan 15, 2009 at 11:48 AM, Gordon Sim 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
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
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 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
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
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 wrote: > On Wed, Jan 14, 2009 at 6:18 PM, Gordon Sim 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
On Wed, Jan 14, 2009 at 6:18 PM, Gordon Sim 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
2009/1/14 Gordon Sim : > 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
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
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
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
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
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
Aidan Skinner wrote: On Mon, Jan 12, 2009 at 9:53 PM, 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 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
On Mon, Jan 12, 2009 at 9:53 PM, 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 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
Re: Planning M5/ or whatever we call it
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 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. >
Planning M5/ or whatever we call it
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.
