qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: [VOTE] Qpid Dispatch Router 0.6.0 (RC4)
Date Thu, 09 Jun 2016 12:48:48 GMT
previous vote rescinded.

+1 - Release RC4 as Qpid Dispatch Router 0.6.0


----- Original Message -----
> From: "Robbie Gemmell" <robbie.gemmell@gmail.com>
> To: users@qpid.apache.org
> Sent: Wednesday, June 8, 2016 10:42:39 AM
> Subject: Re: [VOTE] Qpid Dispatch Router 0.6.0 (RC4)
> 
> On 8 June 2016 at 15:07, Ken Giusti <kgiusti@redhat.com> wrote:
> > Robbie -
> >
> > ----- Original Message -----
> >> From: "Robbie Gemmell" <robbie.gemmell@gmail.com>
> >> To: users@qpid.apache.org
> >> Sent: Tuesday, June 7, 2016 4:56:56 PM
> >> Subject: Re: [VOTE] Qpid Dispatch Router 0.6.0 (RC4)
> >>
> >> Is the behaviour a regression, or has it always been that way? If its
> >> the latter then I think its simply a good addition to a list of things
> >> worthy of a swift followup release, rather than a reason to hold back
> >> this one.
> >>
> >
> > Good point - no it is not a regression.
> >
> > But it is an ambiguity in the behavior that is visible to the clients that
> > will likely result in clients violating the AMQP 1.0 spec (i.e. resending
> > w/o proper delivery count or resending to a node that cannot process the
> > message).
> >
> > No I don't want to hold up the release.  I agree it's been too long since
> > the last release (but given the major refactor that has occurred it is
> > understandable why it has taken so long).  But I don't want to let this
> > issue remain open for too long once a fix is available.
> >
> > I haven't found any other issues with the RC4 candidate.
> >
> > If the consensus is to ship 0.6.0 without a fix I'll rescind my -1 but I'm
> > going to call for a 0.6.x release if 0.7.0 doesn't ship within a couple of
> > weeks after a fix is made available.
> >
> > Is this a reasonable compromise?
> >
> > -K
> 
> Yes, I think doing a 0.6.1 (or however many 0.6.x as are appropriate
> to resolve similar issues as they arise) if 0.7.0 is more than a
> couple weeks away seems like a good approach. It almost seems like the
> final digit in the versions could be useful :)
> 
> Robbie
> 
> >
> >> There will be other things requiring fixes and as people discover
> >> those we can and should do additional releases as appropriate to fix
> >> them. It looks to be almost 9 months since the last Dispatch release,
> >> its time to get a new one out and then do some more after that.
> >>
> >> I've said this before, but I think its worth repeating. In general we
> >> are guilty of taking too long to put out releases, often coupled with
> >> having putting too much in them, then putting even more things in to
> >> avoid them waiting around for the next slow release. The trouble is,
> >> the more often releases are delayed to fit in yet another thing, then
> >> the more often people will feel the need to fit yet more into it, and
> >> the longer people will put off testing the candidate builds due to
> >> expectation there will still be more of them to come, and the later we
> >> might find actual blockers as a result, and the further needless
> >> respins there are. The net result is fewer releases that can often end
> >> up being overly annoying and further encourage doing less of them.
> >>
> >> It takes us no more time and effort (probably even a good bit less) to
> >> do multiple releases in a given reasonable time period than it does to
> >> respin one over and over before release, but short of breaking API
> >> changes to consider its generally going to be nicer having the
> >> additional releases.
> >>
> >> Robbie
> >>
> >> On 7 June 2016 at 20:57, Ken Giusti <kgiusti@redhat.com> wrote:
> >> > -1 - Don't release RC4 because of
> >> > https://issues.apache.org/jira/browse/DISPATCH-366
> >> >
> >> > Sorry to be the party pooper, but this seems serious enough to block the
> >> > RC.
> >> >
> >> > If this isn't fixed we risk clients re-sending messages with the
> >> > improper
> >> > delivery-count value.
> >> >
> >> >
> >> >
> >> >
> >> > ----- Original Message -----
> >> >> From: "Ted Ross" <tross@redhat.com>
> >> >> To: users@qpid.apache.org
> >> >> Sent: Monday, June 6, 2016 5:32:14 PM
> >> >> Subject: [VOTE] Qpid Dispatch Router 0.6.0 (RC4)
> >> >>
> >> >> This is the vote thread to approve RC4 as the final Dispatch Router
> >> >> 0.6.0.
> >> >>
> >> >> Given that this is a significant release in terms of features and
> >> >> functionality, I think we should get it released.
> >> >>
> >> >> I understand that there are a number of open issues with this
> >> >> candidate,
> >> >> the most worrisome being DISPATCH-358.  This issue involves
> >> >> intermittent
> >> >> crashes, but to this point it has been unreproducible outside of the
> >> >> reporter's test environment.
> >> >>
> >> >> My proposal is to go forward with the release, get the new
> >> >> functionality
> >> >> out officially, and continue to close out the issues that are
> >> >> outstanding.  If we reproduce and fix DISPATCH-358, we can turn a 0.6.1
> >> >> on the release branch, or wait for 0.7.0 (which should be much shorter
> >> >> in duration than 0.6.0).
> >> >>
> >> >> Please weigh in with your opinion and your vote:
> >> >>
> >> >> +1 - Release RC4 as Qpid Dispatch Router 0.6.0
> >> >> -1 - Don't release RC4 because of _____________
> >> >>
> >> >> Thanks,
> >> >>
> >> >> -Ted
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> >> For additional commands, e-mail: users-help@qpid.apache.org
> >> >>
> >> >>
> >> >
> >> > --
> >> > -K
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> > For additional commands, e-mail: users-help@qpid.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> >> For additional commands, e-mail: users-help@qpid.apache.org
> >>
> >>
> >
> > --
> > -K
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 
> 

-- 
-K

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message