Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 4A531200C68 for ; Wed, 3 May 2017 12:11:50 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 48ECA160BB5; Wed, 3 May 2017 10:11:50 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 8E638160BAA for ; Wed, 3 May 2017 12:11:49 +0200 (CEST) Received: (qmail 53995 invoked by uid 500); 3 May 2017 10:11:48 -0000 Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@brooklyn.apache.org Delivered-To: mailing list dev@brooklyn.apache.org Received: (qmail 53984 invoked by uid 99); 3 May 2017 10:11:48 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 May 2017 10:11:48 +0000 Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id D5CB01A0312 for ; Wed, 3 May 2017 10:11:47 +0000 (UTC) Received: by mail-wm0-f46.google.com with SMTP id u65so141019455wmu.1 for ; Wed, 03 May 2017 03:11:47 -0700 (PDT) X-Gm-Message-State: AN3rC/6VEUokcBi0VsbZD8NSD/TNrsbvXySPwQgmCLLW3BjtFgnN4SLi IKROo/4HSRBlunRt5ucaTJi8bOinOg== X-Received: by 10.28.149.3 with SMTP id x3mr818303wmd.90.1493806306052; Wed, 03 May 2017 03:11:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.163.205 with HTTP; Wed, 3 May 2017 03:11:45 -0700 (PDT) In-Reply-To: References: From: Richard Downer Date: Wed, 3 May 2017 11:11:45 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [DISCUSS][VOTE] Release Apache Brooklyn 0.11.0 [rc2] To: Brooklyn dev Content-Type: multipart/alternative; boundary=001a1148dcf03c52a7054e9be22c archived-at: Wed, 03 May 2017 10:11:50 -0000 --001a1148dcf03c52a7054e9be22c Content-Type: text/plain; charset=UTF-8 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 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 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 > 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 > >> wrote: > >> > > > > >> > > >> Please use this thread for discussions about the 0.11.0 [rc2] > >> release > >> > > >> (please keep the actual vote thread just for votes). > >> > > >> > >> > > >> Thanks! > >> > > >> > >> > > > >> > > >> > > > --001a1148dcf03c52a7054e9be22c--