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 <[email protected]> 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:[email protected]] >>>> Sent: Thursday, April 21, 2011 4:44 AM >>>> To: [email protected] >>>> 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 >>>> <[email protected]>wrote: >>>> >>>> On Wed, Apr 20, 2011 at 10:12 AM, Gordon Sim >>>>> >>>> <[email protected]> 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:[email protected] >>>>>> >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>> >>>>> Apache Qpid - AMQP Messaging Implementation >>>>> Project: http://qpid.apache.org >>>>> Use/Interact: mailto:[email protected] >>>>> >>>>> >>>>> >>>> >>> >>> --------------------------------------------------------------------- >>> Apache Qpid - AMQP Messaging Implementation >>> Project: http://qpid.apache.org >>> Use/Interact: mailto:[email protected] >>> >>> >>> >> > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > >
