Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
MIME-Version: 1.0
References: <CABQFKi2KvbpM7XdVuBb6vcuEW1QmhSqW-s_LsEzVXt6-2XKKxw@mail.gmail.com>
 <CABQFKi1AbwE-Uk9GgnZ9DDw_GGH1SF42x13PZWreTstTCg1_eA@mail.gmail.com>
 <CANaN7bEmKo49G8OV7_SK4FFforKgxC2vv2i+ty4k3VnqaJb+Fw@mail.gmail.com>
 <CAE7C0PeO2Ztz0_BQJNEnzcWfoiSar4cAavKkgkh+kqXDJUnLcQ@mail.gmail.com>
 <CABQFKi06j4=1Cm2D77RoYGorG+m+9Rj9T0A=c8vxTmvnsLib=A@mail.gmail.com> <CAE7C0Pcby613zHR-ShHAZE69Azi7mAp=pmKpgS7iY_WK-Esf2g@mail.gmail.com>
In-Reply-To: <CAE7C0Pcby613zHR-ShHAZE69Azi7mAp=pmKpgS7iY_WK-Esf2g@mail.gmail.com>
From: Geoff Macartney <geoff.macartney@cloudsoftcorp.com>
Date: Wed, 03 May 2017 08:30:01 +0000
Message-ID: <CAE7C0PeM=wDaaowz6X-_H0naztYzrZZ29bfR-LiO=ZYKyPDZzA@mail.gmail.com>
Subject: Re: [DISCUSS][VOTE] Release Apache Brooklyn 0.11.0 [rc2]
To: Brooklyn dev <dev@brooklyn.apache.org>
Content-Type: multipart/alternative; boundary=94eb2c05c122fa381a054e9a769d
archived-at: Wed, 03 May 2017 08:30:19 -0000

--94eb2c05c122fa381a054e9a769d
Content-Type: text/plain; charset=UTF-8

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!
>> > > >>
>> > >
>> >
>>
>

--94eb2c05c122fa381a054e9a769d--