Hi Geoff, Yes you are correct. With an extended weekend + ensuing backlog of work at $DAYJOB, this has been neglected somewhat. I'll get back to it.
Richard. On 3 May 2017 at 09:30, Geoff Macartney <geoff.macart...@cloudsoftcorp.com> wrote: > hi all, > > can we just clarify -- I think from the discussion above we concluded the > RC2 was blocked, but it might be worth an email confirming that? > > > If we're going to do an RC3 would it be possible to squeeze > https://github.com/apache/brooklyn-server/pull/662 into it? (As mentioned > here last week.) > > cheers > Geoff > > > > > On Fri, 28 Apr 2017 at 09:09 Geoff Macartney < > geoff.macart...@cloudsoftcorp.com> wrote: > > > Sounds good to me > > > > > > > > On Thu, 27 Apr 2017 at 21:34 Richard Downer <rich...@apache.org> wrote: > > > >> It is a tricky thing to come up with hard-and-fast rules for, so I think > >> there will have to be some subjectivity in the decision. > >> > >> In this case the bug doesn't neatly fit into any of the categories you > >> suggest: it's a minor feature so would probably not be encountered by > many > >> users. It's a new feature in this version, so it wouldn't be counted as > a > >> regression. But for those who do try to use the new feature, the failure > >> mode is pretty serious. > >> > >> Often it's better to get opinions and form a consensus rather than > write a > >> rule book to predict all future problems. You know how Apache likes > >> "consensus" and voting about things ;-) > >> > >> Consensus in this case seems pretty clear to cancelling the current vote > >> and making another release candidate. > >> > >> On 27 Apr 2017 3:14 pm, "Geoff Macartney" < > >> geoff.macart...@cloudsoftcorp.com> > >> wrote: > >> > >> > What are our guidelines on what constitutes a release blocker, or, if > we > >> > don't have any specific guidelines other than gut feeling, should we > >> create > >> > some? > >> > > >> > My own suggestion for such guidelines would be something like: > >> > > >> > 1. Clearly any "very serious" issues (by some definition of the words) > >> > should block the release. > >> > 2. For "moderately serious" issues, I would suggest: > >> > - if the issue was not present in the previous releases of Brooklyn, > >> then > >> > it should block this release (don't want to introduce regressions) > >> > - if the issue was present in the previous releases, then it need not > >> block > >> > this release (If it hasn't been reported until now then it is likely > not > >> > causing users problems) > >> > 3. For "not serious issues" don't block the release (even if it is a > >> > regression?). > >> > > >> > what category does BROOKLYN-493 [1] fall into? > >> > > >> > Geoff > >> > > >> > [1] https://issues.apache.org/jira/browse/BROOKLYN-493 > >> > > >> > > >> > On Wed, 26 Apr 2017 at 09:06 Andrea Turli < > >> andrea.tu...@cloudsoftcorp.com> > >> > wrote: > >> > > >> > > +1 Richard, > >> > > > >> > > I personally consider any rebinding issues a release blocker. > >> > > > >> > > Sorry for not having seen it during my tests. Does this mean we > should > >> > > agree on a minimum amount of "live" tests that should pass to > validate > >> > > a release? > >> > > > >> > > On 26 April 2017 at 09:01, Richard Downer <rich...@apache.org> > wrote: > >> > > > Bug BROOKLYN-493[1] has been reported this morning: "Rebind fails > >> when > >> > > > using WinRmCommandSensor". > >> > > > > >> > > > Do we consider this to be a release blocker? > >> > > > > >> > > > In favour of blocking the release: rebind failures will be a major > >> > issue > >> > > in > >> > > > a "real" deployment of Brooklyn - the ability to restart the > >> Brooklyn > >> > > > process after a failure is an important feature, and breaking this > >> will > >> > > > give an impression that our product cannot reliably stop and start > >> > > itself. > >> > > > > >> > > > In favour of continuing the release: it's for a feature which is > >> > > currently > >> > > > little used. I've heard through other channels that it is possible > >> to > >> > > > workaround the bug with a handcrafted bundle that clones the buggy > >> code > >> > > > plus a fix into a new package. > >> > > > > >> > > > Personally I'd call this a release blocker. > >> > > > > >> > > > What do others think? > >> > > > > >> > > > Thanks > >> > > > Richard. > >> > > > > >> > > > > >> > > > On 18 April 2017 at 17:09, Richard Downer <rich...@apache.org> > >> wrote: > >> > > > > >> > > >> Please use this thread for discussions about the 0.11.0 [rc2] > >> release > >> > > >> (please keep the actual vote thread just for votes). > >> > > >> > >> > > >> Thanks! > >> > > >> > >> > > > >> > > >> > > >
