RE: [0.5][README] Upcoming SVN surgery
Great, thanks for the update Martin. Dave. -Original Message- From: martin.a.ritc...@googlemail.com [mailto:martin.a.ritc...@googlemail.com] On Behalf Of Martin Ritchie Sent: Thursday, April 23, 2009 4:40 AM To: dev@qpid.apache.org Subject: Re: [0.5][README] Upcoming SVN surgery Hi David, Apologies for the complete radio silence on the 0.5 release. I have completed the reassembly of the Java broker and local testing is looking good. So we should be in good shape to create an RC for review at the end of next week. Regards Martin 2009/4/22 David Ingham : > Hi Aidan, > > I was wondering whether you have an update on the planned schedule for 0.5. I > know you're all working hard to stabilize the Java side of the house but, > selfishly, I'm keen to get the Windows updates to the C++ that Steve has been > working on out to the public in an official build. I know we were originally > targeting 3/27, what's your best guess on a revised schedule. > > Thanks, > > Dave. > > -Original Message- > From: aidan.skin...@gmail.com [mailto:aidan.skin...@gmail.com] On Behalf Of > Aidan Skinner > Sent: Friday, April 10, 2009 8:35 AM > To: dev@qpid.apache.org > Subject: [0.5][README] Upcoming SVN surgery > > This is a "watch your head, incoming svn surgery" email. Sorry. > > The Java server is currently the long sticking out thing that's > holding up 0.5, and there's significant enough concern about some of > the changes that have gone in that it's probably best to revert them. > Martin, Marnie and, to a lesser extent, I have been working on these > issues and feel that the best way forward is to back out the work > around TransactionLog and flow to disk and ship without them. > > In the interests of doing so expediently and preserving a clear, > coherent SVN history, we're going to do the following: > > 1. copy trunk at a known good revision from before this work started > onto a "newtip"[1] branch > 2. use the new 1.5 svn merge tooling to take the good patches from > trunk to newtip > 2.5 test newtip to ensure that the resulting broker is sound, safe and sane. > 3. move trunk/qpid/java/broker to a holding branch so that the work > isn't lost and can be easily retrieved later > 4. move newtip/qpid/java/broker to trunk/qpid/java/broker and copy it > to 0.5-release/qpid/java/broker > > and then proceed from there. This should be the shortest path to a > releasable code base, albiet unfortunately losing some features we'd > love to have. That seems like a better plan than continuing to bug fix > and delaying the other components unnecessarily. > > I'm not entirely sure about timescales, I expect that 4 will occur > towards the middle of next week. > > Shout if you have a problem with this. > > - Aidan > > [1] probably not its actual name > -- > Apache Qpid - World Domination through Advanced Message Queueing > http://qpid.apache.org > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [0.5][README] Upcoming SVN surgery
Hi David, Apologies for the complete radio silence on the 0.5 release. I have completed the reassembly of the Java broker and local testing is looking good. So we should be in good shape to create an RC for review at the end of next week. Regards Martin 2009/4/22 David Ingham : > Hi Aidan, > > I was wondering whether you have an update on the planned schedule for 0.5. I > know you're all working hard to stabilize the Java side of the house but, > selfishly, I'm keen to get the Windows updates to the C++ that Steve has been > working on out to the public in an official build. I know we were originally > targeting 3/27, what's your best guess on a revised schedule. > > Thanks, > > Dave. > > -Original Message- > From: aidan.skin...@gmail.com [mailto:aidan.skin...@gmail.com] On Behalf Of > Aidan Skinner > Sent: Friday, April 10, 2009 8:35 AM > To: dev@qpid.apache.org > Subject: [0.5][README] Upcoming SVN surgery > > This is a "watch your head, incoming svn surgery" email. Sorry. > > The Java server is currently the long sticking out thing that's > holding up 0.5, and there's significant enough concern about some of > the changes that have gone in that it's probably best to revert them. > Martin, Marnie and, to a lesser extent, I have been working on these > issues and feel that the best way forward is to back out the work > around TransactionLog and flow to disk and ship without them. > > In the interests of doing so expediently and preserving a clear, > coherent SVN history, we're going to do the following: > > 1. copy trunk at a known good revision from before this work started > onto a "newtip"[1] branch > 2. use the new 1.5 svn merge tooling to take the good patches from > trunk to newtip > 2.5 test newtip to ensure that the resulting broker is sound, safe and sane. > 3. move trunk/qpid/java/broker to a holding branch so that the work > isn't lost and can be easily retrieved later > 4. move newtip/qpid/java/broker to trunk/qpid/java/broker and copy it > to 0.5-release/qpid/java/broker > > and then proceed from there. This should be the shortest path to a > releasable code base, albiet unfortunately losing some features we'd > love to have. That seems like a better plan than continuing to bug fix > and delaying the other components unnecessarily. > > I'm not entirely sure about timescales, I expect that 4 will occur > towards the middle of next week. > > Shout if you have a problem with this. > > - Aidan > > [1] probably not its actual name > -- > Apache Qpid - World Domination through Advanced Message Queueing > http://qpid.apache.org > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > > -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: [0.5][README] Upcoming SVN surgery
Hi Aidan, I was wondering whether you have an update on the planned schedule for 0.5. I know you're all working hard to stabilize the Java side of the house but, selfishly, I'm keen to get the Windows updates to the C++ that Steve has been working on out to the public in an official build. I know we were originally targeting 3/27, what's your best guess on a revised schedule. Thanks, Dave. -Original Message- From: aidan.skin...@gmail.com [mailto:aidan.skin...@gmail.com] On Behalf Of Aidan Skinner Sent: Friday, April 10, 2009 8:35 AM To: dev@qpid.apache.org Subject: [0.5][README] Upcoming SVN surgery This is a "watch your head, incoming svn surgery" email. Sorry. The Java server is currently the long sticking out thing that's holding up 0.5, and there's significant enough concern about some of the changes that have gone in that it's probably best to revert them. Martin, Marnie and, to a lesser extent, I have been working on these issues and feel that the best way forward is to back out the work around TransactionLog and flow to disk and ship without them. In the interests of doing so expediently and preserving a clear, coherent SVN history, we're going to do the following: 1. copy trunk at a known good revision from before this work started onto a "newtip"[1] branch 2. use the new 1.5 svn merge tooling to take the good patches from trunk to newtip 2.5 test newtip to ensure that the resulting broker is sound, safe and sane. 3. move trunk/qpid/java/broker to a holding branch so that the work isn't lost and can be easily retrieved later 4. move newtip/qpid/java/broker to trunk/qpid/java/broker and copy it to 0.5-release/qpid/java/broker and then proceed from there. This should be the shortest path to a releasable code base, albiet unfortunately losing some features we'd love to have. That seems like a better plan than continuing to bug fix and delaying the other components unnecessarily. I'm not entirely sure about timescales, I expect that 4 will occur towards the middle of next week. Shout if you have a problem with this. - Aidan [1] probably not its actual name -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [0.5][README] Upcoming SVN surgery
2009/4/13 Martin Ritchie : > 2009/4/10 Aidan Skinner : >> This is a "watch your head, incoming svn surgery" email. Sorry. >> >> The Java server is currently the long sticking out thing that's >> holding up 0.5, and there's significant enough concern about some of >> the changes that have gone in that it's probably best to revert them. >> Martin, Marnie and, to a lesser extent, I have been working on these >> issues and feel that the best way forward is to back out the work >> around TransactionLog and flow to disk and ship without them. >> >> In the interests of doing so expediently and preserving a clear, >> coherent SVN history, we're going to do the following: >> >> 1. copy trunk at a known good revision from before this work started >> onto a "newtip"[1] branch >> 2. use the new 1.5 svn merge tooling to take the good patches from >> trunk to newtip >> 2.5 test newtip to ensure that the resulting broker is sound, safe and sane. >> 3. move trunk/qpid/java/broker to a holding branch so that the work >> isn't lost and can be easily retrieved later >> 4. move newtip/qpid/java/broker to trunk/qpid/java/broker and copy it >> to 0.5-release/qpid/java/broker >> >> and then proceed from there. This should be the shortest path to a >> releasable code base, albiet unfortunately losing some features we'd >> love to have. That seems like a better plan than continuing to bug fix >> and delaying the other components unnecessarily. >> >> I'm not entirely sure about timescales, I expect that 4 will occur >> towards the middle of next week. >> >> Shout if you have a problem with this. >> >> - Aidan >> >> [1] probably not its actual name >> -- >> Apache Qpid - World Domination through Advanced Message Queueing >> http://qpid.apache.org >> >> - >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:dev-subscr...@qpid.apache.org > > Hi all following on from Aidan's email above. I'm just about to create > the branch and start merging over the revisions from the Java broker. > When the merges are complete there will be a heads up before copying > it back to trunk and then merging to 0.5 so we can get the release > out. > > Cheers > > Martin > > -- > Martin Ritchie I've recreated the 0.5-fix broker so will now swap out the broker on trunk for this revision. Regards Martin -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [0.5][README] Upcoming SVN surgery
2009/4/10 Aidan Skinner : > This is a "watch your head, incoming svn surgery" email. Sorry. > > The Java server is currently the long sticking out thing that's > holding up 0.5, and there's significant enough concern about some of > the changes that have gone in that it's probably best to revert them. > Martin, Marnie and, to a lesser extent, I have been working on these > issues and feel that the best way forward is to back out the work > around TransactionLog and flow to disk and ship without them. > > In the interests of doing so expediently and preserving a clear, > coherent SVN history, we're going to do the following: > > 1. copy trunk at a known good revision from before this work started > onto a "newtip"[1] branch > 2. use the new 1.5 svn merge tooling to take the good patches from > trunk to newtip > 2.5 test newtip to ensure that the resulting broker is sound, safe and sane. > 3. move trunk/qpid/java/broker to a holding branch so that the work > isn't lost and can be easily retrieved later > 4. move newtip/qpid/java/broker to trunk/qpid/java/broker and copy it > to 0.5-release/qpid/java/broker > > and then proceed from there. This should be the shortest path to a > releasable code base, albiet unfortunately losing some features we'd > love to have. That seems like a better plan than continuing to bug fix > and delaying the other components unnecessarily. > > I'm not entirely sure about timescales, I expect that 4 will occur > towards the middle of next week. > > Shout if you have a problem with this. > > - Aidan > > [1] probably not its actual name > -- > Apache Qpid - World Domination through Advanced Message Queueing > http://qpid.apache.org > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org Hi all following on from Aidan's email above. I'm just about to create the branch and start merging over the revisions from the Java broker. When the merges are complete there will be a heads up before copying it back to trunk and then merging to 0.5 so we can get the release out. Cheers Martin -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
