You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Justin Ross <jr...@redhat.com> on 2011/04/14 16:39:40 UTC
[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-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Gordon Sim <gs...@redhat.com>.
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-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <eb...@apache.org> 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
Posted by Emmanuel Bourg <eb...@apache.org>.
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
Posted by Andrew Kennedy <an...@gmail.com>.
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 <jr...@redhat.com> 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-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Cliff Jansen <cl...@gmail.com>.
+1
Cliff
On Thu, Apr 14, 2011 at 7:39 AM, Justin Ross <jr...@redhat.com> 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-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Jonathan Robie <jo...@redhat.com>.
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-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Gordon Sim <gs...@redhat.com>.
On 04/27/2011 11:51 AM, Robbie Gemmell wrote:
> On 27 April 2011 11:24, Gordon Sim<gs...@redhat.com> 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-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Robbie Gemmell <ro...@gmail.com>.
On 27 April 2011 11:24, Gordon Sim <gs...@redhat.com> 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
Posted by Gordon Sim <gs...@redhat.com>.
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-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <gs...@redhat.com> 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-subscribe@qpid.apache.org
>
>
Re: [VOTE] Release 0.10
Posted by Gordon Sim <gs...@redhat.com>.
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-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Rajith Attapattu <ra...@gmail.com>.
On Wed, Apr 27, 2011 at 12:17 PM, Emmanuel Bourg <eb...@apache.org> 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-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Emmanuel Bourg <eb...@apache.org>.
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-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Rajith Attapattu <ra...@gmail.com>.
On Wed, Apr 27, 2011 at 11:46 AM, Emmanuel Bourg <eb...@apache.org> 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-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Marnie McCormack <ma...@googlemail.com>.
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 <eb...@apache.org> 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
Posted by Emmanuel Bourg <eb...@apache.org>.
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
Posted by Jonathan Robie <jo...@redhat.com>.
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-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Emmanuel Bourg <eb...@apache.org>.
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-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Rajith Attapattu <ra...@gmail.com>.
On Wed, Apr 27, 2011 at 10:51 AM, Emmanuel Bourg <eb...@apache.org> 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-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Emmanuel Bourg <eb...@apache.org>.
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-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <jr...@redhat.com> 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 <jr...@redhat.com> 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.mccormack@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
>>>>>>> <ra...@gmail.com>wrote:
>>>>>>>
>>>>>>> On Wed, Apr 20, 2011 at 10:12 AM, Gordon Sim
>>>>>>>
>>>>>>>>
>>>>>>>> <gs...@redhat.com> 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-subscribe@qpid.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>
>>>>>>> Apache Qpid - AMQP Messaging Implementation
>>>>>>>> Project: http://qpid.apache.org
>>>>>>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> Apache Qpid - AMQP Messaging Implementation
>>>>>> Project: http://qpid.apache.org
>>>>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>> Apache Qpid - AMQP Messaging Implementation
>>>> Project: http://qpid.apache.org
>>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>>
> ---------------------------------------------------------------------
>
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: [VOTE] Release 0.10
Posted by Justin Ross <jr...@redhat.com>.
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 <jr...@redhat.com> 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.mccormack@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
>>>>>> <ra...@gmail.com>wrote:
>>>>>>
>>>>>> On Wed, Apr 20, 2011 at 10:12 AM, Gordon Sim
>>>>>>>
>>>>>> <gs...@redhat.com> 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-subscribe@qpid.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>>> Apache Qpid - AMQP Messaging Implementation
>>>>>>> Project: http://qpid.apache.org
>>>>>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> Apache Qpid - AMQP Messaging Implementation
>>>>> Project: http://qpid.apache.org
>>>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project: http://qpid.apache.org
>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Justin Ross <jr...@redhat.com>.
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 <jr...@redhat.com> 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.mccormack@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
>>>>> <ra...@gmail.com>wrote:
>>>>>
>>>>> On Wed, Apr 20, 2011 at 10:12 AM, Gordon Sim
>>>>>>
>>>>> <gs...@redhat.com> 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-subscribe@qpid.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>
>>>>>> Apache Qpid - AMQP Messaging Implementation
>>>>>> Project: http://qpid.apache.org
>>>>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> Apache Qpid - AMQP Messaging Implementation
>>>> Project: http://qpid.apache.org
>>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <jr...@redhat.com> 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.mccormack@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
>>>> <ra...@gmail.com>wrote:
>>>>
>>>> On Wed, Apr 20, 2011 at 10:12 AM, Gordon Sim
>>>>>
>>>> <gs...@redhat.com> 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-subscribe@qpid.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>
>>>>> Apache Qpid - AMQP Messaging Implementation
>>>>> Project: http://qpid.apache.org
>>>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project: http://qpid.apache.org
>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
RE: [VOTE] Release 0.10
Posted by Justin Ross <jr...@redhat.com>.
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.mccormack@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
>>> <ra...@gmail.com>wrote:
>>>
>>>> On Wed, Apr 20, 2011 at 10:12 AM, Gordon Sim
>>> <gs...@redhat.com> 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-subscribe@qpid.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>>> Apache Qpid - AMQP Messaging Implementation
>>>> Project: http://qpid.apache.org
>>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: [VOTE] Release 0.10
Posted by Justin Ross <jr...@redhat.com>.
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.mccormack@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
>> <ra...@gmail.com>wrote:
>>
>>> On Wed, Apr 20, 2011 at 10:12 AM, Gordon Sim
>> <gs...@redhat.com> 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-subscribe@qpid.apache.org
>>>>
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project: http://qpid.apache.org
>>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: [VOTE] Release 0.10
Posted by Steve Huston <sh...@riverace.com>.
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.mccormack@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
> <ra...@gmail.com>wrote:
>
> > On Wed, Apr 20, 2011 at 10:12 AM, Gordon Sim
> <gs...@redhat.com> 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-subscribe@qpid.apache.org
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > Apache Qpid - AMQP Messaging Implementation
> > Project: http://qpid.apache.org
> > Use/Interact: mailto:dev-subscribe@qpid.apache.org
> >
> >
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Marnie McCormack <ma...@googlemail.com>.
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 <ra...@gmail.com>wrote:
> On Wed, Apr 20, 2011 at 10:12 AM, Gordon Sim <gs...@redhat.com> 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-subscribe@qpid.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: [VOTE] Release 0.10
Posted by Rajith Attapattu <ra...@gmail.com>.
On Wed, Apr 20, 2011 at 10:12 AM, Gordon Sim <gs...@redhat.com> 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-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Gordon Sim <gs...@redhat.com>.
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-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Rajith Attapattu <ra...@gmail.com>.
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 <gs...@redhat.com> 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-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Gordon Sim <gs...@redhat.com>.
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-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Justin Ross <jr...@redhat.com>.
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 <ra...@gmail.com>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
>> <ro...@gmail.com> wrote:
>>> +1
>>>
>>> Robbie
>>>
>>> On 14 April 2011 15:39, Justin Ross <jr...@redhat.com> 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-subscribe@qpid.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: [VOTE] Release 0.10
Posted by Steve Huston <sh...@riverace.com>.
That seems reasonable to me, Marnie.
-Steve
> -----Original Message-----
> From: Marnie McCormack [mailto:marnie.mccormack@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
> <ra...@gmail.com>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
> > <ro...@gmail.com> wrote:
> > > +1
> > >
> > > Robbie
> > >
> > > On 14 April 2011 15:39, Justin Ross <jr...@redhat.com> 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-subscribe@qpid.apache.org
> > >>
> > >>
> > >
> >
> >
> ---------------------------------------------------------------------
> > Apache Qpid - AMQP Messaging Implementation
> > Project: http://qpid.apache.org
> > Use/Interact: mailto:dev-subscribe@qpid.apache.org
> >
> >
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Marnie McCormack <ma...@googlemail.com>.
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 <ra...@gmail.com>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
> <ro...@gmail.com> wrote:
> > +1
> >
> > Robbie
> >
> > On 14 April 2011 15:39, Justin Ross <jr...@redhat.com> 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-subscribe@qpid.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: [VOTE] Release 0.10
Posted by Rajith Attapattu <ra...@gmail.com>.
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
<ro...@gmail.com> wrote:
> +1
>
> Robbie
>
> On 14 April 2011 15:39, Justin Ross <jr...@redhat.com> 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-subscribe@qpid.apache.org
>>
>>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Robbie Gemmell <ro...@gmail.com>.
+1
Robbie
On 14 April 2011 15:39, Justin Ross <jr...@redhat.com> 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-subscribe@qpid.apache.org
>
>
Re: [VOTE] Release 0.10
Posted by Alan Conway <ac...@redhat.com>.
+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-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Ken Giusti <kg...@redhat.com>.
+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-subscribe@qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: [VOTE] Release 0.10
Posted by Steve Huston <sh...@riverace.com>.
+1
> -----Original Message-----
> From: Justin Ross [mailto:jross@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-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [VOTE] Release 0.10
Posted by Chuck Rolke <cr...@redhat.com>.
+1
It works for me.
-Chuck
----- Original Message -----
> From: "Justin Ross" <jr...@redhat.com>
> 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-subscribe@qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org