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 robert.j.gr...@gmail.comwrote: 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
Re: Planning M5/ or whatever we call it
On 1/15/09, Robert Greig robert.j.gr...@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/%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
Aidan Skinner wrote: 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. 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 1:44 PM, Aidan Skinner aidan.skin...@gmail.comwrote: 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. What refactoring would you propose for M5 ?
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 ai...@apache.org wrote: On Thu, Jan 15, 2009 at 2:26 PM, Marnie McCormack marnie.mccorm...@googlemail.com wrote: On Thu, Jan 15, 2009 at 1:44 PM, Aidan Skinner aidan.skin...@gmail.com wrote: 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. 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
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
Robert Greig 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. 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
2009/1/14 Gordon Sim g...@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
Aidan Skinner wrote: On Mon, Jan 12, 2009 at 9:53 PM, Carl Trieloff cctriel...@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
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
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.
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.
