brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Downer <rich...@apache.org>
Subject Re: [DISCUSS][VOTE] Release Apache Brooklyn 0.11.0 [rc2]
Date Wed, 03 May 2017 10:11:45 GMT
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.macartney@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.macartney@cloudsoftcorp.com> wrote:
>
> > Sounds good to me
> >
> >
> >
> > On Thu, 27 Apr 2017 at 21:34 Richard Downer <richard@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.macartney@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.turli@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 <richard@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 <richard@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!
> >> > > >>
> >> > >
> >> >
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message