Re: [VOTE] Release 0.10
Can I kindly ask this thread move off the VOTE thread please ? Many Thanks, Marnie On Thu, Apr 28, 2011 at 10:29 AM, Emmanuel Bourg wrote: > Le 27/04/2011 21:34, Jonathan Robie a écrit : > > > Would there be copyright issues? >> > > With the proper copyright notice on the Javadoc pages there is nothing to > worry about. > > Emmanuel Bourg > >
Re: [VOTE] Release 0.10
Le 27/04/2011 21:34, Jonathan Robie a écrit : Would there be copyright issues? With the proper copyright notice on the Javadoc pages there is nothing to worry about. Emmanuel Bourg smime.p7s Description: S/MIME Cryptographic Signature
Re: [VOTE] Release 0.10
On 04/27/2011 11:46 AM, Emmanuel Bourg wrote: Le 27/04/2011 17:17, Rajith Attapattu a écrit : Since we don't support any API other than the JMS API, we don't really have any java doc to publish. That doesn't hurt to publish the javadoc even if you only support the JMS API. It's a very useful documentation to people hacking around the Qpid code, be it on the client or on the server side. Would there be copyright issues? Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Release 0.10
On Wed, Apr 27, 2011 at 12:17 PM, Emmanuel Bourg wrote: > Le 27/04/2011 18:01, Rajith Attapattu a écrit : > >> Well we don't have a clear API or proper documentation to publish >> something meaningful (at least on the client side). >> IMO it will only confuse people and encourage them to use code that >> can potentially change between releases. >> (In the past this code has indeed been changed a few times between >> releases.) > > The lack of Javadoc is a barrier of entry to people interested in > contributing to Qpid. For sure :) I am not saying we shouldn't document - rather we shouldn't publish something which is not documented properly ! > Documentation is not only aimed at end users using the JMS client. > > Emmanuel Bourg > > - > 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: [VOTE] Release 0.10
Le 27/04/2011 18:01, Rajith Attapattu a écrit : Well we don't have a clear API or proper documentation to publish something meaningful (at least on the client side). IMO it will only confuse people and encourage them to use code that can potentially change between releases. (In the past this code has indeed been changed a few times between releases.) The lack of Javadoc is a barrier of entry to people interested in contributing to Qpid. Documentation is not only aimed at end users using the JMS client. Emmanuel Bourg - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Release 0.10
On Wed, Apr 27, 2011 at 11:46 AM, Emmanuel Bourg wrote: > Le 27/04/2011 17:17, Rajith Attapattu a écrit : > >> Since we don't support any API other than the JMS API, we don't really >> have any java doc to publish. > > That doesn't hurt to publish the javadoc even if you only support the JMS > API. It's a very useful documentation to people hacking around the Qpid > code, be it on the client or on the server side. Well we don't have a clear API or proper documentation to publish something meaningful (at least on the client side). IMO it will only confuse people and encourage them to use code that can potentially change between releases. (In the past this code has indeed been changed a few times between releases.) Rajith > Emmanuel Bourg > > - > 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: [VOTE] Release 0.10
Le 27/04/2011 17:17, Rajith Attapattu a écrit : Since we don't support any API other than the JMS API, we don't really have any java doc to publish. That doesn't hurt to publish the javadoc even if you only support the JMS API. It's a very useful documentation to people hacking around the Qpid code, be it on the client or on the server side. Emmanuel Bourg - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Release 0.10
On Wed, Apr 27, 2011 at 10:51 AM, Emmanuel Bourg wrote: > Le 27/04/2011 01:26, Robbie Gemmell a écrit : >> >> I have promoted the maven artifacts to the release repository, they are >> now >> available at https://repository.apache.org/content/repositories/releases >> and >> should get mirrored to the central repo imminently. > > Thank you Robbie. The artifacts are now in the central repo and I can > confirm it works great. > > Do you think it's possible to publish the javadoc for the latest release on > the Qpid site? Since we don't support any API other than the JMS API, we don't really have any java doc to publish. Rajith > Emmanuel Bourg > > - > 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: [VOTE] Release 0.10
Le 27/04/2011 01:26, Robbie Gemmell a écrit : I have promoted the maven artifacts to the release repository, they are now available at https://repository.apache.org/content/repositories/releases and should get mirrored to the central repo imminently. Thank you Robbie. The artifacts are now in the central repo and I can confirm it works great. Do you think it's possible to publish the javadoc for the latest release on the Qpid site? Emmanuel Bourg - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Release 0.10
On 04/27/2011 07:04 AM, Gordon Sim wrote: iframes are even better for this case - what about using them? iframes would probably hurt our Google ranking. See this: http://www.google.com/support/webmasters/bin/answer.py?answer=72746#4"; IFrames are sometimes used to display content on web pages. Content displayed via iFrames may not be indexed and available to appear in Google's search results. We recommend that you avoid the use of iFrames to display content. If you do include iFrames, make sure to provide additional text-based links to the content they display, so that Googlebot can crawl and index this content. Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Release 0.10
On 04/27/2011 11:51 AM, Robbie Gemmell wrote: On 27 April 2011 11:24, Gordon Sim wrote: On 04/27/2011 10:08 AM, Robbie Gemmell wrote: Since we don't actually have anything too complicated and we are just storing the pages as html source anyway rather than some base format that gets converted, ideally I would prefer to just be able to edit the live site files for *everything* and do away with the generation step entirely. To do that would probably require a bit of re engineering though to make things more maintainable though. I dont believe we have access to PHP on the main ASF webserver but it does have Server Side Includes enabled which could also be used to allow including the menus, header, footer etc from a central copy rather than requiring per-page maintenance. The downside with any improvements along this line though is that you then probably need to test your updates using an webserver rather than just viewing the files locally. What about just using frame elements? Is that considered bad form these days? Frames are in general considered evil by most people yes, to the extent that I believe only iframes have survived the cut in HTML5. iframes are even better for this case - what about using them? - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Release 0.10
On 27 April 2011 11:24, Gordon Sim wrote: > On 04/27/2011 10:08 AM, Robbie Gemmell wrote: > >> You currently have to edit all the web page files in two places, with the >> source files being the core content and the generation step adding all the >> headers, footer, menu information to produce the final page which is >> published to /site so that the webserver pulls down the changes and >> publishes them. >> > > Ok, that explains it. Apologies again for failing to adhere to correct > process! I have checked in a change that applies my change directly to the > source to re-synchronise. > > > Since we don't actually have anything too complicated and we are just >> storing the pages as html source anyway rather than some base format that >> gets converted, ideally I would prefer to just be able to edit the live >> site >> files for *everything* and do away with the generation step entirely. To >> do >> that would probably require a bit of re engineering though to make things >> more maintainable though. I dont believe we have access to PHP on the main >> ASF webserver but it does have Server Side Includes enabled which could >> also >> be used to allow including the menus, header, footer etc from a central >> copy >> rather than requiring per-page maintenance. The downside with any >> improvements along this line though is that you then probably need to test >> your updates using an webserver rather than just viewing the files >> locally. >> > > What about just using frame elements? Is that considered bad form these > days? > > Frames are in general considered evil by most people yes, to the extent that I believe only iframes have survived the cut in HTML5.
Re: [VOTE] Release 0.10
On 04/27/2011 10:08 AM, Robbie Gemmell wrote: You currently have to edit all the web page files in two places, with the source files being the core content and the generation step adding all the headers, footer, menu information to produce the final page which is published to /site so that the webserver pulls down the changes and publishes them. Ok, that explains it. Apologies again for failing to adhere to correct process! I have checked in a change that applies my change directly to the source to re-synchronise. Since we don't actually have anything too complicated and we are just storing the pages as html source anyway rather than some base format that gets converted, ideally I would prefer to just be able to edit the live site files for *everything* and do away with the generation step entirely. To do that would probably require a bit of re engineering though to make things more maintainable though. I dont believe we have access to PHP on the main ASF webserver but it does have Server Side Includes enabled which could also be used to allow including the menus, header, footer etc from a central copy rather than requiring per-page maintenance. The downside with any improvements along this line though is that you then probably need to test your updates using an webserver rather than just viewing the files locally. What about just using frame elements? Is that considered bad form these days? - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Release 0.10
You currently have to edit all the web page files in two places, with the source files being the core content and the generation step adding all the headers, footer, menu information to produce the final page which is published to /site so that the webserver pulls down the changes and publishes them. Since we don't actually have anything too complicated and we are just storing the pages as html source anyway rather than some base format that gets converted, ideally I would prefer to just be able to edit the live site files for *everything* and do away with the generation step entirely. To do that would probably require a bit of re engineering though to make things more maintainable though. I dont believe we have access to PHP on the main ASF webserver but it does have Server Side Includes enabled which could also be used to allow including the menus, header, footer etc from a central copy rather than requiring per-page maintenance. The downside with any improvements along this line though is that you then probably need to test your updates using an webserver rather than just viewing the files locally. Robbie On 27 April 2011 08:01, Gordon Sim wrote: > On 04/27/2011 12:26 AM, Robbie Gemmell wrote: > >> You are editing the right file Justin, but it looks like the live version >> was updated without updating the source file accordingly (see >> http://svn.apache.org/viewvc?view=revision&revision=1088983). >> > > My bad, sorry! Let me ask however why you need to edit that file in two > different locations? I can understand having the 'source' for generated > content under trunk and also having specific generated output from that > checked in under site. For the download page however its checked in 'as is' > to site, right? So what purpose does the version under trunk serve? > > It also looks like the files had diverged before that last commit... > > > - > > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > >
Re: [VOTE] Release 0.10
On 04/27/2011 12:26 AM, Robbie Gemmell wrote: You are editing the right file Justin, but it looks like the live version was updated without updating the source file accordingly (see http://svn.apache.org/viewvc?view=revision&revision=1088983). My bad, sorry! Let me ask however why you need to edit that file in two different locations? I can understand having the 'source' for generated content under trunk and also having specific generated output from that checked in under site. For the download page however its checked in 'as is' to site, right? So what purpose does the version under trunk serve? It also looks like the files had diverged before that last commit... - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Release 0.10
I have promoted the maven artifacts to the release repository, they are now available at https://repository.apache.org/content/repositories/releases and should get mirrored to the central repo imminently. You are editing the right file Justin, but it looks like the live version was updated without updating the source file accordingly (see http://svn.apache.org/viewvc?view=revision&revision=1088983). The live version is the example to follow when updating the source, it was updated to remove the older release info after some discussion between the PMC following a mail from infra about removing old artifacts from the mirrors. Only the latest version should get a specific call out on the download page since its what we recommend people use, but anything older is always available in the archives. Once the 0.10 release is mirrored, announcements made, website updated etc then we should probably remove 0.8 from the dist mirrors fairly promptly this time. Robbie On 26 April 2011 20:47, Justin Ross wrote: > With some help (thanks, Nuno), the 0.10 artifacts are now moved into > position. The apache documentation suggests it will be 24 to 48 hours > before they propagate to all the mirrors. > > A question: I'm preparing a patch for the qpid download page, but trunk's > download.html doesn't match what's on the web. Trunk's has a previous > release section (for 0.6 at present) and the web just has a link to the > release archive. Am I editing the right file? > (qpid/trunk/qpid/doc/website/content/download.html) > > Thanks, > Justin > > > On Tue, 26 Apr 2011, Justin Ross wrote: > > Thanks, Robbie. The note about the maven artifacts is indeed helpful. I >> wasn't sure about that. >> >> On Tue, 26 Apr 2011, Robbie Gemmell wrote: >> >> Thats great Justin, good work on getting us here :) >>> >>> Let me know when the files get pushed out to the dist server to be >>> mirrored >>> and I can promote the staged maven artifacts to the release repository >>> for >>> mirroring to the central repo (just so there is no doubt: the maven >>> subdirectory produced by the release script should not be distributed via >>> the apache dist mirrors). >>> >>> Regards >>> Robbie. >>> >>> On 26 April 2011 16:39, Justin Ross wrote: >>> >>> Hi, this is just to note that the 0.10 release using the existing RC is >>>> as >>>> of now confirmed and the vote is closed. I've begun the steps to >>>> publish >>>> the release. >>>> >>>> >>>> On Thu, 21 Apr 2011, Justin Ross wrote: >>>> >>>> Restating Steve's and Marnie's conclusions just so everyone knows our >>>> >>>>> status: >>>>> >>>>> This vote will remain open until Monday morning. Anyone who wants to >>>>> change his or her vote should do so before that time. If the vote >>>>> passes, >>>>> we will release the existing RC as our final 0.10 release. >>>>> >>>>> Justin >>>>> >>>>> On Thu, 21 Apr 2011, Steve Huston wrote: >>>>> >>>>> I agree, Marnie. I'd give until Monday morning for anyone to change >>>>> >>>>>> their vote, or to vote at all, and then close it. >>>>>> >>>>>> -Steve >>>>>> >>>>>> -Original Message- >>>>>> >>>>>>> From: Marnie McCormack [mailto:marnie.mccorm...@googlemail.com] >>>>>>> Sent: Thursday, April 21, 2011 4:44 AM >>>>>>> To: dev@qpid.apache.org >>>>>>> Subject: Re: [VOTE] Release 0.10 >>>>>>> >>>>>>> >>>>>>> All, >>>>>>> >>>>>>> I think this [VOTE} thread could be closed. The question is >>>>>>> does anyone wish to change their vote in the light of the >>>>>>> discussions over the 7 days it has been open ? >>>>>>> >>>>>>> We should decide today if we're proceeding or not, as its all >>>>>>> getting a little confusing ;-) >>>>>>> >>>>>>> If people are uncomfortable with the muddying of the [VOTE] >>>>>>> thread with discussions, we could re-start but I don't think >>>>>>> we 'need' to from a process point of view. >>>>>>> >>>>>>> Tha
Re: [VOTE] Release 0.10
With some help (thanks, Nuno), the 0.10 artifacts are now moved into position. The apache documentation suggests it will be 24 to 48 hours before they propagate to all the mirrors. A question: I'm preparing a patch for the qpid download page, but trunk's download.html doesn't match what's on the web. Trunk's has a previous release section (for 0.6 at present) and the web just has a link to the release archive. Am I editing the right file? (qpid/trunk/qpid/doc/website/content/download.html) Thanks, Justin On Tue, 26 Apr 2011, Justin Ross wrote: Thanks, Robbie. The note about the maven artifacts is indeed helpful. I wasn't sure about that. On Tue, 26 Apr 2011, Robbie Gemmell wrote: Thats great Justin, good work on getting us here :) Let me know when the files get pushed out to the dist server to be mirrored and I can promote the staged maven artifacts to the release repository for mirroring to the central repo (just so there is no doubt: the maven subdirectory produced by the release script should not be distributed via the apache dist mirrors). Regards Robbie. On 26 April 2011 16:39, Justin Ross wrote: Hi, this is just to note that the 0.10 release using the existing RC is as of now confirmed and the vote is closed. I've begun the steps to publish the release. On Thu, 21 Apr 2011, Justin Ross wrote: Restating Steve's and Marnie's conclusions just so everyone knows our status: This vote will remain open until Monday morning. Anyone who wants to change his or her vote should do so before that time. If the vote passes, we will release the existing RC as our final 0.10 release. Justin On Thu, 21 Apr 2011, Steve Huston wrote: I agree, Marnie. I'd give until Monday morning for anyone to change their vote, or to vote at all, and then close it. -Steve -Original Message- From: Marnie McCormack [mailto:marnie.mccorm...@googlemail.com] Sent: Thursday, April 21, 2011 4:44 AM To: dev@qpid.apache.org Subject: Re: [VOTE] Release 0.10 All, I think this [VOTE} thread could be closed. The question is does anyone wish to change their vote in the light of the discussions over the 7 days it has been open ? We should decide today if we're proceeding or not, as its all getting a little confusing ;-) If people are uncomfortable with the muddying of the [VOTE] thread with discussions, we could re-start but I don't think we 'need' to from a process point of view. Thanks & Regards, Marnie On Wed, Apr 20, 2011 at 4:17 PM, Rajith Attapattu wrote: On Wed, Apr 20, 2011 at 10:12 AM, Gordon Sim wrote: On 04/20/2011 02:38 PM, Rajith Attapattu wrote: While the root cause for both these items have been present in 0.8 (and perhaps before for QPID-3216) these issues are *more likely* to happen in the current release than in 0.8 In that sense they are regressions, and certainly from a users pov of they are. What is that based on? The fact that we've seen these test failures? Or identification of specific changes first included in 0.10 that make this worse? All commits related to QPID-3214 are in 0.10 and in 0.8 as well (I stand to be corrected on this). But somehow this became more visible now. My suspicion is that some other changes in that time frame has made this issue more likely. Unfortunately I am unable to pin point what exactly those changes are. The fact that our tests are failing is not helping either. I think recent changes in the client and broker may have made these issues happen more likely. While r1092510 may have caused QPID-3216 to happen more readily there may be other triggers that can cause this as well. (Also please note that r1092510 is actually the correct behaviour and if thats causing a deadlock then it's a concern.) The point is r1092510 is not included in the current 0.10 release candidate. Correct and one reason why it wasn't was bcos I wasn't sure about it's consequences and nobody seems to know why the existing code was done that way. However that is just one code path that caused this deadlock, there can be others and bcos of test failures we are not sure. Perhaps I am a bit pessimistic here, but then it's always better be safer than sorry. Same can be said for QPID-3214. The fact remains that we do have deadlocks lying around in the code and they have a better chance of happening with 0.10 ! Again, why do 'they have a better chance of happening with 0.10'? I'm not saying it is not true, and I'm not disagreeing the current locking 'strategy' seems very prone to deadlocks. I would just like to see a more concrete demonstration that there is regression. Unfortunately I am unable to pin point to certain commits to backup my assertions. That is one reason why I didn
Re: [VOTE] Release 0.10
Thanks, Robbie. The note about the maven artifacts is indeed helpful. I wasn't sure about that. On Tue, 26 Apr 2011, Robbie Gemmell wrote: Thats great Justin, good work on getting us here :) Let me know when the files get pushed out to the dist server to be mirrored and I can promote the staged maven artifacts to the release repository for mirroring to the central repo (just so there is no doubt: the maven subdirectory produced by the release script should not be distributed via the apache dist mirrors). Regards Robbie. On 26 April 2011 16:39, Justin Ross wrote: Hi, this is just to note that the 0.10 release using the existing RC is as of now confirmed and the vote is closed. I've begun the steps to publish the release. On Thu, 21 Apr 2011, Justin Ross wrote: Restating Steve's and Marnie's conclusions just so everyone knows our status: This vote will remain open until Monday morning. Anyone who wants to change his or her vote should do so before that time. If the vote passes, we will release the existing RC as our final 0.10 release. Justin On Thu, 21 Apr 2011, Steve Huston wrote: I agree, Marnie. I'd give until Monday morning for anyone to change their vote, or to vote at all, and then close it. -Steve -Original Message- From: Marnie McCormack [mailto:marnie.mccorm...@googlemail.com] Sent: Thursday, April 21, 2011 4:44 AM To: dev@qpid.apache.org Subject: Re: [VOTE] Release 0.10 All, I think this [VOTE} thread could be closed. The question is does anyone wish to change their vote in the light of the discussions over the 7 days it has been open ? We should decide today if we're proceeding or not, as its all getting a little confusing ;-) If people are uncomfortable with the muddying of the [VOTE] thread with discussions, we could re-start but I don't think we 'need' to from a process point of view. Thanks & Regards, Marnie On Wed, Apr 20, 2011 at 4:17 PM, Rajith Attapattu wrote: On Wed, Apr 20, 2011 at 10:12 AM, Gordon Sim wrote: On 04/20/2011 02:38 PM, Rajith Attapattu wrote: While the root cause for both these items have been present in 0.8 (and perhaps before for QPID-3216) these issues are *more likely* to happen in the current release than in 0.8 In that sense they are regressions, and certainly from a users pov of they are. What is that based on? The fact that we've seen these test failures? Or identification of specific changes first included in 0.10 that make this worse? All commits related to QPID-3214 are in 0.10 and in 0.8 as well (I stand to be corrected on this). But somehow this became more visible now. My suspicion is that some other changes in that time frame has made this issue more likely. Unfortunately I am unable to pin point what exactly those changes are. The fact that our tests are failing is not helping either. I think recent changes in the client and broker may have made these issues happen more likely. While r1092510 may have caused QPID-3216 to happen more readily there may be other triggers that can cause this as well. (Also please note that r1092510 is actually the correct behaviour and if thats causing a deadlock then it's a concern.) The point is r1092510 is not included in the current 0.10 release candidate. Correct and one reason why it wasn't was bcos I wasn't sure about it's consequences and nobody seems to know why the existing code was done that way. However that is just one code path that caused this deadlock, there can be others and bcos of test failures we are not sure. Perhaps I am a bit pessimistic here, but then it's always better be safer than sorry. Same can be said for QPID-3214. The fact remains that we do have deadlocks lying around in the code and they have a better chance of happening with 0.10 ! Again, why do 'they have a better chance of happening with 0.10'? I'm not saying it is not true, and I'm not disagreeing the current locking 'strategy' seems very prone to deadlocks. I would just like to see a more concrete demonstration that there is regression. Unfortunately I am unable to pin point to certain commits to backup my assertions. That is one reason why I didn't want to hold up the release and didn't make any of the two JIRA's as blockers. But it's still makes me a bit uncomfortable. Rajith - 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: [VOTE] Release 0.10
Thats great Justin, good work on getting us here :) Let me know when the files get pushed out to the dist server to be mirrored and I can promote the staged maven artifacts to the release repository for mirroring to the central repo (just so there is no doubt: the maven subdirectory produced by the release script should not be distributed via the apache dist mirrors). Regards Robbie. On 26 April 2011 16:39, Justin Ross wrote: > Hi, this is just to note that the 0.10 release using the existing RC is as > of now confirmed and the vote is closed. I've begun the steps to publish > the release. > > > On Thu, 21 Apr 2011, Justin Ross wrote: > > Restating Steve's and Marnie's conclusions just so everyone knows our >> status: >> >> This vote will remain open until Monday morning. Anyone who wants to >> change his or her vote should do so before that time. If the vote passes, >> we will release the existing RC as our final 0.10 release. >> >> Justin >> >> On Thu, 21 Apr 2011, Steve Huston wrote: >> >> I agree, Marnie. I'd give until Monday morning for anyone to change >>> their vote, or to vote at all, and then close it. >>> >>> -Steve >>> >>> -Original Message- >>>> From: Marnie McCormack [mailto:marnie.mccorm...@googlemail.com] >>>> Sent: Thursday, April 21, 2011 4:44 AM >>>> To: dev@qpid.apache.org >>>> Subject: Re: [VOTE] Release 0.10 >>>> >>>> >>>> All, >>>> >>>> I think this [VOTE} thread could be closed. The question is >>>> does anyone wish to change their vote in the light of the >>>> discussions over the 7 days it has been open ? >>>> >>>> We should decide today if we're proceeding or not, as its all >>>> getting a little confusing ;-) >>>> >>>> If people are uncomfortable with the muddying of the [VOTE] >>>> thread with discussions, we could re-start but I don't think >>>> we 'need' to from a process point of view. >>>> >>>> Thanks & Regards, >>>> Marnie >>>> >>>> On Wed, Apr 20, 2011 at 4:17 PM, Rajith Attapattu >>>> wrote: >>>> >>>> On Wed, Apr 20, 2011 at 10:12 AM, Gordon Sim >>>>> >>>> wrote: >>>> >>>>> On 04/20/2011 02:38 PM, Rajith Attapattu wrote: >>>>>> >>>>>>> >>>>>>> While the root cause for both these items have been >>>>>>> >>>>>> present in 0.8 >>>> >>>>> (and perhaps before for QPID-3216) these issues are >>>>>>> >>>>>> *more likely* >>>> >>>>> to happen in the current release than in 0.8 In that >>>>>>> >>>>>> sense they are >>>> >>>>> regressions, and certainly from a users pov of >>>>>>> >>>>>> they >>>>> >>>>>> are. >>>>>>> >>>>>> >>>>>> What is that based on? The fact that we've seen these >>>>>> >>>>> test failures? >>>> >>>>> Or identification of specific changes first included in 0.10 that >>>>>> make this worse? >>>>>> >>>>> >>>>> All commits related to QPID-3214 are in 0.10 and in 0.8 as well (I >>>>> stand to be corrected on this). But somehow this became >>>>> >>>> more visible >>>> >>>>> now. My suspicion is that some other changes in that time frame has >>>>> made this issue more likely. >>>>> Unfortunately I am unable to pin point what exactly those >>>>> >>>> changes are. >>>> >>>>> The fact that our tests are failing is not helping either. >>>>> >>>>> I think recent changes in the client and broker may have >>>>>>> >>>>>> made these >>>> >>>>> issues happen more likely. While r1092510 may have >>>>>>> >>>>>> caused QPID-3216 >>>> >>>>> to happen more readily there may be other triggers that >>>>>>> >>>>>> can cause >>>> >>>>> this as well. (Also please note that r1092510 is actually the >>>>>>> correct behaviour a
RE: [VOTE] Release 0.10
Hi, this is just to note that the 0.10 release using the existing RC is as of now confirmed and the vote is closed. I've begun the steps to publish the release. On Thu, 21 Apr 2011, Justin Ross wrote: Restating Steve's and Marnie's conclusions just so everyone knows our status: This vote will remain open until Monday morning. Anyone who wants to change his or her vote should do so before that time. If the vote passes, we will release the existing RC as our final 0.10 release. Justin On Thu, 21 Apr 2011, Steve Huston wrote: I agree, Marnie. I'd give until Monday morning for anyone to change their vote, or to vote at all, and then close it. -Steve -Original Message- From: Marnie McCormack [mailto:marnie.mccorm...@googlemail.com] Sent: Thursday, April 21, 2011 4:44 AM To: dev@qpid.apache.org Subject: Re: [VOTE] Release 0.10 All, I think this [VOTE} thread could be closed. The question is does anyone wish to change their vote in the light of the discussions over the 7 days it has been open ? We should decide today if we're proceeding or not, as its all getting a little confusing ;-) If people are uncomfortable with the muddying of the [VOTE] thread with discussions, we could re-start but I don't think we 'need' to from a process point of view. Thanks & Regards, Marnie On Wed, Apr 20, 2011 at 4:17 PM, Rajith Attapattu wrote: On Wed, Apr 20, 2011 at 10:12 AM, Gordon Sim wrote: On 04/20/2011 02:38 PM, Rajith Attapattu wrote: While the root cause for both these items have been present in 0.8 (and perhaps before for QPID-3216) these issues are *more likely* to happen in the current release than in 0.8 In that sense they are regressions, and certainly from a users pov of they are. What is that based on? The fact that we've seen these test failures? Or identification of specific changes first included in 0.10 that make this worse? All commits related to QPID-3214 are in 0.10 and in 0.8 as well (I stand to be corrected on this). But somehow this became more visible now. My suspicion is that some other changes in that time frame has made this issue more likely. Unfortunately I am unable to pin point what exactly those changes are. The fact that our tests are failing is not helping either. I think recent changes in the client and broker may have made these issues happen more likely. While r1092510 may have caused QPID-3216 to happen more readily there may be other triggers that can cause this as well. (Also please note that r1092510 is actually the correct behaviour and if thats causing a deadlock then it's a concern.) The point is r1092510 is not included in the current 0.10 release candidate. Correct and one reason why it wasn't was bcos I wasn't sure about it's consequences and nobody seems to know why the existing code was done that way. However that is just one code path that caused this deadlock, there can be others and bcos of test failures we are not sure. Perhaps I am a bit pessimistic here, but then it's always better be safer than sorry. Same can be said for QPID-3214. The fact remains that we do have deadlocks lying around in the code and they have a better chance of happening with 0.10 ! Again, why do 'they have a better chance of happening with 0.10'? I'm not saying it is not true, and I'm not disagreeing the current locking 'strategy' seems very prone to deadlocks. I would just like to see a more concrete demonstration that there is regression. Unfortunately I am unable to pin point to certain commits to backup my assertions. That is one reason why I didn't want to hold up the release and didn't make any of the two JIRA's as blockers. But it's still makes me a bit uncomfortable. Rajith - 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 - 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: Publishing the Maven artifacts for the 0.10 Java client (was Re: [VOTE] Release 0.10)
I staged the 0.10 maven artifacts last night. Should anyone else wish to test them before they get promoted or dropped, they are now available here: https://repository.apache.org/content/repositories/orgapacheqpid-109/ Robbie On 19 April 2011 13:09, Robbie Gemmell wrote: > Moving this off the 0.10 vote thread as I actually planned to last time :) > > The process for releasing these is detailed at > http://www.apache.org/dev/publishing-maven-artifacts.html as previously > mentioned, and involves them being published to the ASF's Nexus instance at > https://repository.apache.org , from where they will be synced to the > central Maven repo. Once the artifacts are initially uploaded they are > placed into a Staging repo, which can then either be closed to prepare it > for release or dropped if something goes wrong with the upload. Once the > repo is closed, the staged artifacts can then be tested and voted on, and > then either dropped or promoted to the Releases repo once the vote > concludes. > > I had previously investigated using Ant+Ivy in the way detailed at the dev > page above, and so put together a task to publish our current maven release > artifacts (found at > http://people.apache.org/~astitcher/dist/qpid-0.10/maven/ ) to a Nexus > Community Edition instance I set up locally. I also requested infra to > enable our access to the ASF's Nexus Professional instance, which has now > been completed. I have just tested that the task is able to successfully > upload to the ASF's instance, and so have committed the work against > https://issues.apache.org/jira/browse/QPID-3213. The task is currently > standalone from the rest of the build, and instructions for using it are on > the JIRA (probably best added to a nice release process page at some > point..). > > I have dropped the staged artifacts I created when doing the above, because > the staging repos are named based partially on an IP for the uploader and I > am currently stuck behind a load balancing proxy server which resulted in 3 > staging repos being created instead of just 1 for all the artifacts. I am > happy to either perform the staging myself when I am at home later, or for > Andrew Stitcher to do so in keeping with his publishing of the other > artifacts. > > Robbie > > On 15 April 2011 14:29, Robbie Gemmell wrote: > >> The instructions cover an upload-only use of Ivy, which is something I >> have been investigating and plan to put in place so we can publish the >> artifacts to Nexus. >> >> Robbie >> >> >> On 15 April 2011 13:57, Emmanuel Bourg wrote: >> >>> Le 15/04/2011 13:50, Andrew Kennedy a écrit : >>> >>> >>> One thing I'm not clear on. Since the genpom stuff has been fixed (See QPID-1916 - thx, Robbie and Emmanuel) are we going to disseminate Maven artifacts as part of 0.10 now? That would definitely be nice to have. I believe we can upload to https://repository.apache.org/content/repositories/releases/ once we have the approved release artifacts, but I'm not sure of the correct process. I can find out if nobody else knows? >>> >>> There are some instructions on the Apache site: >>> >>> http://www.apache.org/dev/publishing-maven-artifacts.html >>> >>> >>> These instructions are for a Maven or an Ant+Ivy setup. For Qpid we used >>> an Ant+Maven Task setup, so I don't really know how to publish to Nexus with >>> our build. >>> >>> >>> Emmanuel Bourg >>> >>> >> >
RE: [VOTE] Release 0.10
Restating Steve's and Marnie's conclusions just so everyone knows our status: This vote will remain open until Monday morning. Anyone who wants to change his or her vote should do so before that time. If the vote passes, we will release the existing RC as our final 0.10 release. Justin On Thu, 21 Apr 2011, Steve Huston wrote: I agree, Marnie. I'd give until Monday morning for anyone to change their vote, or to vote at all, and then close it. -Steve -Original Message- From: Marnie McCormack [mailto:marnie.mccorm...@googlemail.com] Sent: Thursday, April 21, 2011 4:44 AM To: dev@qpid.apache.org Subject: Re: [VOTE] Release 0.10 All, I think this [VOTE} thread could be closed. The question is does anyone wish to change their vote in the light of the discussions over the 7 days it has been open ? We should decide today if we're proceeding or not, as its all getting a little confusing ;-) If people are uncomfortable with the muddying of the [VOTE] thread with discussions, we could re-start but I don't think we 'need' to from a process point of view. Thanks & Regards, Marnie On Wed, Apr 20, 2011 at 4:17 PM, Rajith Attapattu wrote: On Wed, Apr 20, 2011 at 10:12 AM, Gordon Sim wrote: On 04/20/2011 02:38 PM, Rajith Attapattu wrote: While the root cause for both these items have been present in 0.8 (and perhaps before for QPID-3216) these issues are *more likely* to happen in the current release than in 0.8 In that sense they are regressions, and certainly from a users pov of they are. What is that based on? The fact that we've seen these test failures? Or identification of specific changes first included in 0.10 that make this worse? All commits related to QPID-3214 are in 0.10 and in 0.8 as well (I stand to be corrected on this). But somehow this became more visible now. My suspicion is that some other changes in that time frame has made this issue more likely. Unfortunately I am unable to pin point what exactly those changes are. The fact that our tests are failing is not helping either. I think recent changes in the client and broker may have made these issues happen more likely. While r1092510 may have caused QPID-3216 to happen more readily there may be other triggers that can cause this as well. (Also please note that r1092510 is actually the correct behaviour and if thats causing a deadlock then it's a concern.) The point is r1092510 is not included in the current 0.10 release candidate. Correct and one reason why it wasn't was bcos I wasn't sure about it's consequences and nobody seems to know why the existing code was done that way. However that is just one code path that caused this deadlock, there can be others and bcos of test failures we are not sure. Perhaps I am a bit pessimistic here, but then it's always better be safer than sorry. Same can be said for QPID-3214. The fact remains that we do have deadlocks lying around in the code and they have a better chance of happening with 0.10 ! Again, why do 'they have a better chance of happening with 0.10'? I'm not saying it is not true, and I'm not disagreeing the current locking 'strategy' seems very prone to deadlocks. I would just like to see a more concrete demonstration that there is regression. Unfortunately I am unable to pin point to certain commits to backup my assertions. That is one reason why I didn't want to hold up the release and didn't make any of the two JIRA's as blockers. But it's still makes me a bit uncomfortable. Rajith - 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 - 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: [VOTE] Release 0.10
+1 > -Original Message- > From: Justin Ross [mailto:jr...@redhat.com] > Sent: Thursday, April 14, 2011 10:40 AM > To: dev@qpid.apache.org > Subject: [VOTE] Release 0.10 > > > Hello, everyone. The blocker issue raised earlier this week has been > resolved. There's more information, including release notes, at the > release page[1]. > > The proposed final distribution of Qpid 0.10 is available > from the link > below. It's from revision 1091571 of the 0.10 branch. > >http://people.apache.org/~astitcher/dist/qpid-0.10/ > > Andrew has graciously generated and signed this distro. It therefore > meets the requirements for a vote. > > If you favor releasing this distribution as Qpid 0.10, vote +1. > > If you are aware of problems that ought to prevent this > distribution from > being released, vote -1. > > Thanks, > Justin > > --- > [1] https://cwiki.apache.org/confluence/display/qpid/0.10+Release > > - > 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: [VOTE] Release 0.10
I agree, Marnie. I'd give until Monday morning for anyone to change their vote, or to vote at all, and then close it. -Steve > -Original Message- > From: Marnie McCormack [mailto:marnie.mccorm...@googlemail.com] > Sent: Thursday, April 21, 2011 4:44 AM > To: dev@qpid.apache.org > Subject: Re: [VOTE] Release 0.10 > > > All, > > I think this [VOTE} thread could be closed. The question is > does anyone wish to change their vote in the light of the > discussions over the 7 days it has been open ? > > We should decide today if we're proceeding or not, as its all > getting a little confusing ;-) > > If people are uncomfortable with the muddying of the [VOTE] > thread with discussions, we could re-start but I don't think > we 'need' to from a process point of view. > > Thanks & Regards, > Marnie > > On Wed, Apr 20, 2011 at 4:17 PM, Rajith Attapattu > wrote: > > > On Wed, Apr 20, 2011 at 10:12 AM, Gordon Sim > wrote: > > > On 04/20/2011 02:38 PM, Rajith Attapattu wrote: > > >> > > >> While the root cause for both these items have been > present in 0.8 > > >> (and perhaps before for QPID-3216) these issues are > *more likely* > > >> to happen in the current release than in 0.8 In that > sense they are > > >> regressions, and certainly from a users pov of > > they > > >> are. > > > > > > What is that based on? The fact that we've seen these > test failures? > > > Or identification of specific changes first included in 0.10 that > > > make this worse? > > > > All commits related to QPID-3214 are in 0.10 and in 0.8 as well (I > > stand to be corrected on this). But somehow this became > more visible > > now. My suspicion is that some other changes in that time frame has > > made this issue more likely. > > Unfortunately I am unable to pin point what exactly those > changes are. > > The fact that our tests are failing is not helping either. > > > > >> I think recent changes in the client and broker may have > made these > > >> issues happen more likely. While r1092510 may have > caused QPID-3216 > > >> to happen more readily there may be other triggers that > can cause > > >> this as well. (Also please note that r1092510 is actually the > > >> correct behaviour and if thats causing a deadlock then it's a > > >> concern.) > > > > > > The point is r1092510 is not included in the current 0.10 release > > candidate. > > > > Correct and one reason why it wasn't was bcos I wasn't sure > about it's > > consequences and nobody seems to know why the existing code > was done > > that way. However that is just one code path that caused this > > deadlock, there can be others and bcos of test failures we are not > > sure. Perhaps I am a bit pessimistic here, but then it's > always better > > be safer than sorry. > > > > >> Same can be said for QPID-3214. > > >> > > >> The fact remains that we do have deadlocks lying around > in the code > > >> and they have a better chance of happening with 0.10 ! > > > > > > Again, why do 'they have a better chance of happening with 0.10'? > > > I'm not saying it is not true, and I'm not disagreeing > the current > > > locking 'strategy' seems very prone to deadlocks. I would > just like > > > to see a more concrete demonstration that there is regression. > > > > Unfortunately I am unable to pin point to certain commits > to backup my > > assertions. That is one reason why I didn't want to hold up the > > release and didn't make any of the two JIRA's as blockers. > > But it's still makes me a bit uncomfortable. > > > > Rajith > > > > > > > > > - > > > 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 > > > > > - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Release 0.10
All, I think this [VOTE} thread could be closed. The question is does anyone wish to change their vote in the light of the discussions over the 7 days it has been open ? We should decide today if we're proceeding or not, as its all getting a little confusing ;-) If people are uncomfortable with the muddying of the [VOTE] thread with discussions, we could re-start but I don't think we 'need' to from a process point of view. Thanks & Regards, Marnie On Wed, Apr 20, 2011 at 4:17 PM, Rajith Attapattu wrote: > On Wed, Apr 20, 2011 at 10:12 AM, Gordon Sim wrote: > > On 04/20/2011 02:38 PM, Rajith Attapattu wrote: > >> > >> While the root cause for both these items have been present in 0.8 > >> (and perhaps before for QPID-3216) these issues are *more likely* to > >> happen in the current release than in 0.8 > >> In that sense they are regressions, and certainly from a users pov of > they > >> are. > > > > What is that based on? The fact that we've seen these test failures? Or > > identification of specific changes first included in 0.10 that make this > > worse? > > All commits related to QPID-3214 are in 0.10 and in 0.8 as well (I > stand to be corrected on this). > But somehow this became more visible now. > My suspicion is that some other changes in that time frame has made > this issue more likely. > Unfortunately I am unable to pin point what exactly those changes are. > The fact that our tests are failing is not helping either. > > >> I think recent changes in the client and broker may have made these > >> issues happen more likely. > >> While r1092510 may have caused QPID-3216 to happen more readily there > >> may be other triggers that can cause this as well. > >> (Also please note that r1092510 is actually the correct behaviour and > >> if thats causing a deadlock then it's a concern.) > > > > The point is r1092510 is not included in the current 0.10 release > candidate. > > Correct and one reason why it wasn't was bcos I wasn't sure about it's > consequences and nobody seems to know why the existing code was done > that way. > However that is just one code path that caused this deadlock, there > can be others and bcos of test failures we are not sure. > Perhaps I am a bit pessimistic here, but then it's always better be > safer than sorry. > > >> Same can be said for QPID-3214. > >> > >> The fact remains that we do have deadlocks lying around in the code > >> and they have a better chance of happening with 0.10 ! > > > > Again, why do 'they have a better chance of happening with 0.10'? I'm not > > saying it is not true, and I'm not disagreeing the current locking > > 'strategy' seems very prone to deadlocks. I would just like to see a more > > concrete demonstration that there is regression. > > Unfortunately I am unable to pin point to certain commits to backup my > assertions. > That is one reason why I didn't want to hold up the release and didn't > make any of the two JIRA's as blockers. > But it's still makes me a bit uncomfortable. > > Rajith > > > - > > 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: [VOTE] Release 0.10
On Wed, Apr 20, 2011 at 10:12 AM, Gordon Sim wrote: > On 04/20/2011 02:38 PM, Rajith Attapattu wrote: >> >> While the root cause for both these items have been present in 0.8 >> (and perhaps before for QPID-3216) these issues are *more likely* to >> happen in the current release than in 0.8 >> In that sense they are regressions, and certainly from a users pov of they >> are. > > What is that based on? The fact that we've seen these test failures? Or > identification of specific changes first included in 0.10 that make this > worse? All commits related to QPID-3214 are in 0.10 and in 0.8 as well (I stand to be corrected on this). But somehow this became more visible now. My suspicion is that some other changes in that time frame has made this issue more likely. Unfortunately I am unable to pin point what exactly those changes are. The fact that our tests are failing is not helping either. >> I think recent changes in the client and broker may have made these >> issues happen more likely. >> While r1092510 may have caused QPID-3216 to happen more readily there >> may be other triggers that can cause this as well. >> (Also please note that r1092510 is actually the correct behaviour and >> if thats causing a deadlock then it's a concern.) > > The point is r1092510 is not included in the current 0.10 release candidate. Correct and one reason why it wasn't was bcos I wasn't sure about it's consequences and nobody seems to know why the existing code was done that way. However that is just one code path that caused this deadlock, there can be others and bcos of test failures we are not sure. Perhaps I am a bit pessimistic here, but then it's always better be safer than sorry. >> Same can be said for QPID-3214. >> >> The fact remains that we do have deadlocks lying around in the code >> and they have a better chance of happening with 0.10 ! > > Again, why do 'they have a better chance of happening with 0.10'? I'm not > saying it is not true, and I'm not disagreeing the current locking > 'strategy' seems very prone to deadlocks. I would just like to see a more > concrete demonstration that there is regression. Unfortunately I am unable to pin point to certain commits to backup my assertions. That is one reason why I didn't want to hold up the release and didn't make any of the two JIRA's as blockers. But it's still makes me a bit uncomfortable. Rajith > - > 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: [VOTE] Release 0.10
On 04/20/2011 02:38 PM, Rajith Attapattu wrote: While the root cause for both these items have been present in 0.8 (and perhaps before for QPID-3216) these issues are *more likely* to happen in the current release than in 0.8 In that sense they are regressions, and certainly from a users pov of they are. What is that based on? The fact that we've seen these test failures? Or identification of specific changes first included in 0.10 that make this worse? I think recent changes in the client and broker may have made these issues happen more likely. While r1092510 may have caused QPID-3216 to happen more readily there may be other triggers that can cause this as well. (Also please note that r1092510 is actually the correct behaviour and if thats causing a deadlock then it's a concern.) The point is r1092510 is not included in the current 0.10 release candidate. Same can be said for QPID-3214. The fact remains that we do have deadlocks lying around in the code and they have a better chance of happening with 0.10 ! Again, why do 'they have a better chance of happening with 0.10'? I'm not saying it is not true, and I'm not disagreeing the current locking 'strategy' seems very prone to deadlocks. I would just like to see a more concrete demonstration that there is regression. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Release 0.10
While the root cause for both these items have been present in 0.8 (and perhaps before for QPID-3216) these issues are *more likely* to happen in the current release than in 0.8 In that sense they are regressions, and certainly from a users pov of they are. I think recent changes in the client and broker may have made these issues happen more likely. While r1092510 may have caused QPID-3216 to happen more readily there may be other triggers that can cause this as well. (Also please note that r1092510 is actually the correct behaviour and if thats causing a deadlock then it's a concern.) Same can be said for QPID-3214. The fact remains that we do have deadlocks lying around in the code and they have a better chance of happening with 0.10 ! Having said that I agree with Marnie that we should not be holding up the release, as fixing these issues safely may not be possible within the next week or so. (We need to release note both these issues, if we go ahead with the release.) Regards, Rajith On Wed, Apr 20, 2011 at 9:14 AM, Gordon Sim wrote: > On 04/20/2011 10:36 AM, Marnie McCormack wrote: >> >> I've had a look at the details and I'd like to propose the release go >> ahead >> now, rather than be delayed any further. >> >> The reasoning is that the Java items highlighted are not strictly >> regressions (existing largely in Qpid 0.8) and more importantly the fixes >> for them, and associated issues, are likely best measured in weeks and >> 0.12 >> seems a realistic target for them. > > QPID-3216 was apparently caused by r1092510, itself a fix to QPID-3207 made > last Thursday, which isn't even on the 0-10 branch as far as I can see. That > being the case I don't think we need to consider blocking for this one > (unless QPID-3207 was considered a blocker). > That leaves QPID-3214 which was apparently caused by r985262 made on Aug 13 > 2010. As Marnie points out we didn't branch for 0.8 until Nov 7 2010, > r1032358, so this bug exists in 0.8 and is not *in itself* a regression. > > That particular deadlock looks like it may be triggered when the > cancellation of a subscription occurs. It *could* therefore be more visible > following the changes made to the c++ broker for QPID-2324, which was fixed > for 0.10 (throw 404 if client attempts to close a non-existent > subscription). > > I tend to agree with Marnie. If the fix looks like it may take some time (or > if there is any doubt or risk associated with it), it may be best to proceed > with the 0.10 release without this change. > > - > 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: [VOTE] Release 0.10
Marnie, that sounds quite reasonable to me. Justin On Wed, 20 Apr 2011, Marnie McCormack wrote: All, I've had a look at the details and I'd like to propose the release go ahead now, rather than be delayed any further. The reasoning is that the Java items highlighted are not strictly regressions (existing largely in Qpid 0.8) and more importantly the fixes for them, and associated issues, are likely best measured in weeks and 0.12 seems a realistic target for them. If they are fixed earlier, we could consider bringing forward the schedule for 0.12. Thoughts ? Regards, Marnie On Tue, Apr 19, 2011 at 4:22 PM, Rajith Attapattu wrote: We do have two serious regressions in QPID-3214 & QPID-3216 But I don't think we should stop the release as I don't believe we can fix them quickly and safely enough to make this release viable. We are trying very hard to release often and I don't want to jeopardize that. Since we do have another release coming in another 2 months, there is no point delaying this release any further. Therefore IMO we should "release-note" these issues and go ahead. Another option is to do an errata just for the java client (or any other component with a similar problem) as soon as we are confident about the fixes. Regards, Rajith On Tue, Apr 19, 2011 at 7:36 AM, Robbie Gemmell wrote: +1 Robbie On 14 April 2011 15:39, Justin Ross wrote: Hello, everyone. The blocker issue raised earlier this week has been resolved. There's more information, including release notes, at the release page[1]. The proposed final distribution of Qpid 0.10 is available from the link below. It's from revision 1091571 of the 0.10 branch. http://people.apache.org/~astitcher/dist/qpid-0.10/ Andrew has graciously generated and signed this distro. It therefore meets the requirements for a vote. If you favor releasing this distribution as Qpid 0.10, vote +1. If you are aware of problems that ought to prevent this distribution from being released, vote -1. Thanks, Justin --- [1] https://cwiki.apache.org/confluence/display/qpid/0.10+Release - 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 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Release 0.10
On 04/20/2011 10:36 AM, Marnie McCormack wrote: I've had a look at the details and I'd like to propose the release go ahead now, rather than be delayed any further. The reasoning is that the Java items highlighted are not strictly regressions (existing largely in Qpid 0.8) and more importantly the fixes for them, and associated issues, are likely best measured in weeks and 0.12 seems a realistic target for them. QPID-3216 was apparently caused by r1092510, itself a fix to QPID-3207 made last Thursday, which isn't even on the 0-10 branch as far as I can see. That being the case I don't think we need to consider blocking for this one (unless QPID-3207 was considered a blocker). That leaves QPID-3214 which was apparently caused by r985262 made on Aug 13 2010. As Marnie points out we didn't branch for 0.8 until Nov 7 2010, r1032358, so this bug exists in 0.8 and is not *in itself* a regression. That particular deadlock looks like it may be triggered when the cancellation of a subscription occurs. It *could* therefore be more visible following the changes made to the c++ broker for QPID-2324, which was fixed for 0.10 (throw 404 if client attempts to close a non-existent subscription). I tend to agree with Marnie. If the fix looks like it may take some time (or if there is any doubt or risk associated with it), it may be best to proceed with the 0.10 release without this change. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: [VOTE] Release 0.10
That seems reasonable to me, Marnie. -Steve > -Original Message- > From: Marnie McCormack [mailto:marnie.mccorm...@googlemail.com] > Sent: Wednesday, April 20, 2011 5:37 AM > To: dev@qpid.apache.org > Subject: Re: [VOTE] Release 0.10 > > > All, > > I've had a look at the details and I'd like to propose the > release go ahead now, rather than be delayed any further. > > The reasoning is that the Java items highlighted are not > strictly regressions (existing largely in Qpid 0.8) and more > importantly the fixes for them, and associated issues, are > likely best measured in weeks and 0.12 seems a realistic > target for them. If they are fixed earlier, we could consider > bringing forward the schedule for 0.12. > > Thoughts ? > Regards, > Marnie > On Tue, Apr 19, 2011 at 4:22 PM, Rajith Attapattu > wrote: > > > We do have two serious regressions in QPID-3214 & QPID-3216 > > > > But I don't think we should stop the release as I don't > believe we can > > fix them quickly and safely enough to make this release > viable. We are > > trying very hard to release often and I don't want to > jeopardize that. > > Since we do have another release coming in another 2 > months, there is > > no point delaying this release any further. > > > > Therefore IMO we should "release-note" these issues and go ahead. > > Another option is to do an errata just for the java client (or any > > other component with a similar problem) as soon as we are confident > > about the fixes. > > > > Regards, > > > > Rajith > > > > On Tue, Apr 19, 2011 at 7:36 AM, Robbie Gemmell > > wrote: > > > +1 > > > > > > Robbie > > > > > > On 14 April 2011 15:39, Justin Ross wrote: > > > > > >> Hello, everyone. The blocker issue raised earlier this week has > > >> been resolved. There's more information, including > release notes, > > >> at the > > release > > >> page[1]. > > >> > > >> The proposed final distribution of Qpid 0.10 is > available from the > > >> link below. It's from revision 1091571 of the 0.10 branch. > > >> > > >> http://people.apache.org/~astitcher/dist/qpid-0.10/ > > >> > > >> Andrew has graciously generated and signed this distro. It > > >> therefore > > meets > > >> the requirements for a vote. > > >> > > >> If you favor releasing this distribution as Qpid 0.10, vote +1. > > >> > > >> If you are aware of problems that ought to prevent this > > >> distribution > > from > > >> being released, vote -1. > > >> > > >> Thanks, > > >> Justin > > >> > > >> --- > > >> [1] https://cwiki.apache.org/confluence/display/qpid/0.10+Release > > >> > > >> > --- > > >> -- > > >> 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 > > > > > - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Release 0.10
All, I've had a look at the details and I'd like to propose the release go ahead now, rather than be delayed any further. The reasoning is that the Java items highlighted are not strictly regressions (existing largely in Qpid 0.8) and more importantly the fixes for them, and associated issues, are likely best measured in weeks and 0.12 seems a realistic target for them. If they are fixed earlier, we could consider bringing forward the schedule for 0.12. Thoughts ? Regards, Marnie On Tue, Apr 19, 2011 at 4:22 PM, Rajith Attapattu wrote: > We do have two serious regressions in QPID-3214 & QPID-3216 > > But I don't think we should stop the release as I don't believe we can > fix them quickly and safely enough to make this release viable. > We are trying very hard to release often and I don't want to jeopardize > that. > Since we do have another release coming in another 2 months, there is > no point delaying this release any further. > > Therefore IMO we should "release-note" these issues and go ahead. > Another option is to do an errata just for the java client (or any > other component with a similar problem) as soon as we are confident > about the fixes. > > Regards, > > Rajith > > On Tue, Apr 19, 2011 at 7:36 AM, Robbie Gemmell > wrote: > > +1 > > > > Robbie > > > > On 14 April 2011 15:39, Justin Ross wrote: > > > >> Hello, everyone. The blocker issue raised earlier this week has been > >> resolved. There's more information, including release notes, at the > release > >> page[1]. > >> > >> The proposed final distribution of Qpid 0.10 is available from the link > >> below. It's from revision 1091571 of the 0.10 branch. > >> > >> http://people.apache.org/~astitcher/dist/qpid-0.10/ > >> > >> Andrew has graciously generated and signed this distro. It therefore > meets > >> the requirements for a vote. > >> > >> If you favor releasing this distribution as Qpid 0.10, vote +1. > >> > >> If you are aware of problems that ought to prevent this distribution > from > >> being released, vote -1. > >> > >> Thanks, > >> Justin > >> > >> --- > >> [1] https://cwiki.apache.org/confluence/display/qpid/0.10+Release > >> > >> - > >> 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: [VOTE] Release 0.10
We do have two serious regressions in QPID-3214 & QPID-3216 But I don't think we should stop the release as I don't believe we can fix them quickly and safely enough to make this release viable. We are trying very hard to release often and I don't want to jeopardize that. Since we do have another release coming in another 2 months, there is no point delaying this release any further. Therefore IMO we should "release-note" these issues and go ahead. Another option is to do an errata just for the java client (or any other component with a similar problem) as soon as we are confident about the fixes. Regards, Rajith On Tue, Apr 19, 2011 at 7:36 AM, Robbie Gemmell wrote: > +1 > > Robbie > > On 14 April 2011 15:39, Justin Ross wrote: > >> Hello, everyone. The blocker issue raised earlier this week has been >> resolved. There's more information, including release notes, at the release >> page[1]. >> >> The proposed final distribution of Qpid 0.10 is available from the link >> below. It's from revision 1091571 of the 0.10 branch. >> >> http://people.apache.org/~astitcher/dist/qpid-0.10/ >> >> Andrew has graciously generated and signed this distro. It therefore meets >> the requirements for a vote. >> >> If you favor releasing this distribution as Qpid 0.10, vote +1. >> >> If you are aware of problems that ought to prevent this distribution from >> being released, vote -1. >> >> Thanks, >> Justin >> >> --- >> [1] https://cwiki.apache.org/confluence/display/qpid/0.10+Release >> >> - >> 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
Publishing the Maven artifacts for the 0.10 Java client (was Re: [VOTE] Release 0.10)
Moving this off the 0.10 vote thread as I actually planned to last time :) The process for releasing these is detailed at http://www.apache.org/dev/publishing-maven-artifacts.html as previously mentioned, and involves them being published to the ASF's Nexus instance at https://repository.apache.org , from where they will be synced to the central Maven repo. Once the artifacts are initially uploaded they are placed into a Staging repo, which can then either be closed to prepare it for release or dropped if something goes wrong with the upload. Once the repo is closed, the staged artifacts can then be tested and voted on, and then either dropped or promoted to the Releases repo once the vote concludes. I had previously investigated using Ant+Ivy in the way detailed at the dev page above, and so put together a task to publish our current maven release artifacts (found at http://people.apache.org/~astitcher/dist/qpid-0.10/maven/ ) to a Nexus Community Edition instance I set up locally. I also requested infra to enable our access to the ASF's Nexus Professional instance, which has now been completed. I have just tested that the task is able to successfully upload to the ASF's instance, and so have committed the work against https://issues.apache.org/jira/browse/QPID-3213. The task is currently standalone from the rest of the build, and instructions for using it are on the JIRA (probably best added to a nice release process page at some point..). I have dropped the staged artifacts I created when doing the above, because the staging repos are named based partially on an IP for the uploader and I am currently stuck behind a load balancing proxy server which resulted in 3 staging repos being created instead of just 1 for all the artifacts. I am happy to either perform the staging myself when I am at home later, or for Andrew Stitcher to do so in keeping with his publishing of the other artifacts. Robbie On 15 April 2011 14:29, Robbie Gemmell wrote: > The instructions cover an upload-only use of Ivy, which is something I have > been investigating and plan to put in place so we can publish the artifacts > to Nexus. > > Robbie > > > On 15 April 2011 13:57, Emmanuel Bourg wrote: > >> Le 15/04/2011 13:50, Andrew Kennedy a écrit : >> >> >> One thing I'm not clear on. Since the genpom stuff has been fixed (See >>> QPID-1916 - thx, Robbie and Emmanuel) are we going to disseminate >>> Maven artifacts as part of 0.10 now? That would definitely be nice to >>> have. I believe we can upload to >>> https://repository.apache.org/content/repositories/releases/ once we >>> have the approved release artifacts, but I'm not sure of the correct >>> process. I can find out if nobody else knows? >>> >> >> There are some instructions on the Apache site: >> >> http://www.apache.org/dev/publishing-maven-artifacts.html >> >> >> These instructions are for a Maven or an Ant+Ivy setup. For Qpid we used >> an Ant+Maven Task setup, so I don't really know how to publish to Nexus with >> our build. >> >> >> Emmanuel Bourg >> >> >
Re: [VOTE] Release 0.10
+1 Robbie On 14 April 2011 15:39, Justin Ross wrote: > Hello, everyone. The blocker issue raised earlier this week has been > resolved. There's more information, including release notes, at the release > page[1]. > > The proposed final distribution of Qpid 0.10 is available from the link > below. It's from revision 1091571 of the 0.10 branch. > > http://people.apache.org/~astitcher/dist/qpid-0.10/ > > Andrew has graciously generated and signed this distro. It therefore meets > the requirements for a vote. > > If you favor releasing this distribution as Qpid 0.10, vote +1. > > If you are aware of problems that ought to prevent this distribution from > being released, vote -1. > > Thanks, > Justin > > --- > [1] https://cwiki.apache.org/confluence/display/qpid/0.10+Release > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org > >
Re: [VOTE] Release 0.10
+1 It works for me. -Chuck - Original Message - > From: "Justin Ross" > To: dev@qpid.apache.org > Sent: Thursday, April 14, 2011 10:39:40 AM > Subject: [VOTE] Release 0.10 > Hello, everyone. The blocker issue raised earlier this week has been > resolved. There's more information, including release notes, at the > release page[1]. > > The proposed final distribution of Qpid 0.10 is available from the > link > below. It's from revision 1091571 of the 0.10 branch. > > http://people.apache.org/~astitcher/dist/qpid-0.10/ > > Andrew has graciously generated and signed this distro. It therefore > meets the requirements for a vote. > > If you favor releasing this distribution as Qpid 0.10, vote +1. > > If you are aware of problems that ought to prevent this distribution > from > being released, vote -1. > > Thanks, > Justin > > --- > [1] https://cwiki.apache.org/confluence/display/qpid/0.10+Release > > - > 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: [VOTE] Release 0.10
+1 -K - Original Message - > Hello, everyone. The blocker issue raised earlier this week has been > resolved. There's more information, including release notes, at the > release page[1]. > > The proposed final distribution of Qpid 0.10 is available from the > link > below. It's from revision 1091571 of the 0.10 branch. > > http://people.apache.org/~astitcher/dist/qpid-0.10/ > > Andrew has graciously generated and signed this distro. It therefore > meets the requirements for a vote. > > If you favor releasing this distribution as Qpid 0.10, vote +1. > > If you are aware of problems that ought to prevent this distribution > from > being released, vote -1. > > Thanks, > Justin > > --- > [1] https://cwiki.apache.org/confluence/display/qpid/0.10+Release > > - > 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: [VOTE] Release 0.10
+1 Cliff On Thu, Apr 14, 2011 at 7:39 AM, Justin Ross wrote: > Hello, everyone. The blocker issue raised earlier this week has been > resolved. There's more information, including release notes, at the release > page[1]. > > The proposed final distribution of Qpid 0.10 is available from the link > below. It's from revision 1091571 of the 0.10 branch. > > http://people.apache.org/~astitcher/dist/qpid-0.10/ > > Andrew has graciously generated and signed this distro. It therefore meets > the requirements for a vote. > > If you favor releasing this distribution as Qpid 0.10, vote +1. > > If you are aware of problems that ought to prevent this distribution from > being released, vote -1. > > Thanks, > Justin > > --- > [1] https://cwiki.apache.org/confluence/display/qpid/0.10+Release > > - > 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: [VOTE] Release 0.10
On 04/14/2011 03:39 PM, Justin Ross wrote: Hello, everyone. The blocker issue raised earlier this week has been resolved. There's more information, including release notes, at the release page[1]. The proposed final distribution of Qpid 0.10 is available from the link below. It's from revision 1091571 of the 0.10 branch. http://people.apache.org/~astitcher/dist/qpid-0.10/ Andrew has graciously generated and signed this distro. It therefore meets the requirements for a vote. If you favor releasing this distribution as Qpid 0.10, vote +1. If you are aware of problems that ought to prevent this distribution from being released, vote -1. +1 - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [VOTE] Release 0.10
+1 On 04/14/2011 10:39 AM, Justin Ross wrote: Hello, everyone. The blocker issue raised earlier this week has been resolved. There's more information, including release notes, at the release page[1]. The proposed final distribution of Qpid 0.10 is available from the link below. It's from revision 1091571 of the 0.10 branch. http://people.apache.org/~astitcher/dist/qpid-0.10/ Andrew has graciously generated and signed this distro. It therefore meets the requirements for a vote. If you favor releasing this distribution as Qpid 0.10, vote +1. If you are aware of problems that ought to prevent this distribution from being released, vote -1. Thanks, Justin --- [1] https://cwiki.apache.org/confluence/display/qpid/0.10+Release - 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: [VOTE] Release 0.10
The instructions cover an upload-only use of Ivy, which is something I have been investigating and plan to put in place so we can publish the artifacts to Nexus. Robbie On 15 April 2011 13:57, Emmanuel Bourg wrote: > Le 15/04/2011 13:50, Andrew Kennedy a écrit : > > > One thing I'm not clear on. Since the genpom stuff has been fixed (See >> QPID-1916 - thx, Robbie and Emmanuel) are we going to disseminate >> Maven artifacts as part of 0.10 now? That would definitely be nice to >> have. I believe we can upload to >> https://repository.apache.org/content/repositories/releases/ once we >> have the approved release artifacts, but I'm not sure of the correct >> process. I can find out if nobody else knows? >> > > There are some instructions on the Apache site: > > http://www.apache.org/dev/publishing-maven-artifacts.html > > > These instructions are for a Maven or an Ant+Ivy setup. For Qpid we used an > Ant+Maven Task setup, so I don't really know how to publish to Nexus with > our build. > > > Emmanuel Bourg > >
Re: [VOTE] Release 0.10
Le 15/04/2011 13:50, Andrew Kennedy a écrit : One thing I'm not clear on. Since the genpom stuff has been fixed (See QPID-1916 - thx, Robbie and Emmanuel) are we going to disseminate Maven artifacts as part of 0.10 now? That would definitely be nice to have. I believe we can upload to https://repository.apache.org/content/repositories/releases/ once we have the approved release artifacts, but I'm not sure of the correct process. I can find out if nobody else knows? There are some instructions on the Apache site: http://www.apache.org/dev/publishing-maven-artifacts.html These instructions are for a Maven or an Ant+Ivy setup. For Qpid we used an Ant+Maven Task setup, so I don't really know how to publish to Nexus with our build. Emmanuel Bourg smime.p7s Description: S/MIME Cryptographic Signature
Re: [VOTE] Release 0.10
Hi. One thing I'm not clear on. Since the genpom stuff has been fixed (See QPID-1916 - thx, Robbie and Emmanuel) are we going to disseminate Maven artifacts as part of 0.10 now? That would definitely be nice to have. I believe we can upload to https://repository.apache.org/content/repositories/releases/ once we have the approved release artifacts, but I'm not sure of the correct process. I can find out if nobody else knows? Andrew. -- -- andrew d kennedy ? edinburgh : +44 7582 293 255 On 14 April 2011 15:39, Justin Ross wrote: > Hello, everyone. The blocker issue raised earlier this week has been > resolved. There's more information, including release notes, at the release > page[1]. > > The proposed final distribution of Qpid 0.10 is available from the link > below. It's from revision 1091571 of the 0.10 branch. > > http://people.apache.org/~astitcher/dist/qpid-0.10/ > > Andrew has graciously generated and signed this distro. It therefore meets > the requirements for a vote. > > If you favor releasing this distribution as Qpid 0.10, vote +1. > > If you are aware of problems that ought to prevent this distribution from > being released, vote -1. > > Thanks, > Justin > > --- > [1] https://cwiki.apache.org/confluence/display/qpid/0.10+Release > > - > 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