Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Wed, 28 Jun 2017 11:14:48 +0200 (CEST)
From: Wido den Hollander <wido@widodh.nl>
To: Rajani Karuturi <rajani@apache.org>, dev@cloudstack.apache.org
Message-ID: <692997858.2949.1498641289095@ox.pcextreme.nl>
In-Reply-To: <dc0a3329-82ce-4464-900c-b6198ccd4ce0@msgid.missiveapp.com>
References: <CAPpf5a1-pYbDM3o63sC1T0h9_Z-gPAop6Ty+jFrKP54P5VOpkg@mail.gmail.com>
 <7C282245-1E88-4D89-9633-640C9C7A9A71@netapp.com>
 <31fccd69-6028-4781-b6e6-ef27bb8284ed@msgid.missiveapp.com>
 <F78063C6-1F91-4977-A51A-8B1FCEF69530@netapp.com>
 <0757774A-4329-4B26-81C6-B6119F7B2257@netapp.com>
 <1BC50AB6-92BA-4148-8075-C6BA95BADCF4@netapp.com>
 <861040891.1735.1497256840264@ox.pcextreme.nl>
 <1D2B1462-53AE-4F47-B39E-FF12EC61D187@netapp.com>
 <0cf97d6e-8c0a-48e1-97a2-b5124795c2ec@msgid.missiveapp.com>
 <CAC2panqs9wzFF1G3rer6aHrG__GWgmfHJisbDTkjnicvrqht1Q@mail.gmail.com>
 <CAGQtxvab6Mn93xmkodQa+dCF48o=9dZGfG6_ZmMuUmTN1LiQ2A@mail.gmail.com>
 <09EC0EEF-F376-4CDA-8929-24836303DE55@netapp.com>
 <DB5PR07MB13345220642E424FC8F8E3618CDC0@DB5PR07MB1334.eurprd07.prod.outlook.com>
 <CAG97rafySpqTR7sE1DkAfFXAL+1JMVqXo_ZO85PMU=eS_bjT_Q@mail.gmail.com>
 <13418e61-3d20-48de-9f70-8b2927f76bd6@msgid.missiveapp.com>
 <DB5PR07MB1334E28BA029CFBF0BE315688CDD0@DB5PR07MB1334.eurprd07.prod.outlook.com>
 <8202747a-641d-44fe-b1e4-18019179cf71@msgid.missiveapp.com>
 <DB5PR07MB133487E169BA2021F70CFBB18CDD0@DB5PR07MB1334.eurprd07.prod.outlook.com>
 <dc0a3329-82ce-4464-900c-b6198ccd4ce0@msgid.missiveapp.com>
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Medium
archived-at: Wed, 28 Jun 2017 09:15:04 -0000


> Op 28 juni 2017 om 11:10 schreef Rajani Karuturi <rajani@apache.org>:
>=20
>=20
> Yes, those shouldn't have been merged.  We should have released
> faster and then merged.
>=20
> Lets think of it as ours and us than theirs and those.
>=20

True!

So let's see if we can get 4.10 out of the door and get 4.11 out there fast=
er.

Merge what needs to be done, test, and go for 4.11 and 4.12

We might say that we don't merge everything for 4.11 and leave a few bits f=
or 4.12.

Wido

> ~ Rajani
>=20
> http://cloudplatform.accelerite.com/
>=20
> On June 28, 2017 at 12:19 PM, Paul Angus
> (paul.angus@shapeblue.com) wrote:
>=20
> Those new PRs should not have been merged.
>=20
> Those on the mailing list should respect the process and accept
> that they will have to wait until code is unfrozen.
>=20
> Kind regards,
>=20
> Paul Angus
>=20
> paul.angus@shapeblue.com
> www.shapeblue.com ( http://www.shapeblue.com )
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
> @shapeblue
>=20
> -----Original Message-----
> From: Rajani Karuturi [mailto:rajani@apache.org]
> Sent: 28 June 2017 07:45
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3
>=20
> Paul,
>=20
> Which shows we are not actively following RCs. That PR was a
> blocker for RC3 and was well discussed. That PR is a perfect
> example that we are not working as community to release code.
> That is a fix for a blocker which stayed open for more than 45
> days.
>=20
> If you see till RC2 it was only blockers that were merged. But,
> since it has taken a lot more time to fix blockers, more PRs were
> merged on request on the mailing list(and we don't have people
> even to object it). you can think of it as a combination of two
> releases due to the time it has taken.
>=20
> ~ Rajani
>=20
> http://cloudplatform.accelerite.com/
>=20
> On June 28, 2017 at 12:06 PM, Paul Angus
> (paul.angus@shapeblue.com) wrote:
>=20
> Rajani,
>=20
> I suspect that fatigue with the 4.10 release testing that we are
> seeing is due to the time it has taken to release it. And that is
> has been caused by new code going in, which have introduced new
> bugs.
>=20
> This was demonstrated in the last -1 from Kris. This change was
> merged 10 days ago.
>=20
> Kind regards,
>=20
> Paul Angus
>=20
> paul.angus@shapeblue.com
> www.shapeblue.com ( http://www.shapeblue.com )=20
> ( http://www.shapeblue.com )
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
>=20
> -----Original Message-----
> From: Rajani Karuturi [mailto:rajani@apache.org]
> Sent: 28 June 2017 06:14
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3
>=20
> We can do a release every month as long as we have enough people
> actively participating in the release process.
>=20
> We have people who wants to have their code/features checked in.
> We, very clearly do not have enough people working on
> releases/blockers. How many of us are testing/voting on releases
> or PRs? We have blockers in jira, with no one to fix. We have PRs
> open for release blockers for more than a month with no one to
> test.
>=20
> I would ask everyone to start testing releases/PRs and voting on
> them actively.
>=20
> We need people who can do the work. We already know what needs
> to be done as outlined in the release principles wiki after long
> discussions on this list.
>=20
> Whether we create a branch off RC or continue on master wont
> change the current situation.
>=20
> We, as community should commit to testing and releasing code.
> principles and theory wont help.
>=20
> Thanks,
>=20
> ~ Rajani
>=20
> http://cloudplatform.accelerite.com/
>=20
> On June 27, 2017 at 9:43 PM, Rafael Weing=C3=A4rtner
> (rafaelweingartner@gmail.com) wrote:
>=20
> +1 to what Paul said.
> IMHO, as soon as we start a release candidate to close a
> version, all merges should stop (period); the only exceptions
> should be PRs that address specific problems in the RC.
> I always thought that we had a protocol for that [1]; maybe for
> this version, we have not followed it?
>=20
> [1]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles=
+for+Apache+CloudStack+4.6+and+up#ReleaseprinciplesforApacheCloudStack4.6an=
dup-Preparingnewrelease:masterfrozen
>=20
> On Tue, Jun 27, 2017 at 1:32 AM, Paul Angus
> <paul.angus@shapeblue.com>
> wrote:
>=20
> Hi All,
>=20
> From my view point 'we' have been the architects of our own
> downfall. Once a code freeze is in place NO new features, NO
> enhancements should be going in. Once we're at an RC stage, NO
> new bug fixes other that for the blockers should be going in.
> that way the release gets out, and the next one can get going.
> If
> 4.10 had gone out in a timely fashion, then we'd probably be on
> 4.11 if not 4.12 by now, with all the new features AND all the
> new fixes in.
>=20
> People sliding new changes/bug fixes/enhancements in are not
> making the product better, they're stopping progress. As we can
> clearly see here.
>=20
> Kind regards,
>=20
> Paul Angus
>=20
> paul.angus@shapeblue.com
> www.shapeblue.com ( http://www.shapeblue.com )=20
> ( http://www.shapeblue.com ) ( http://www.shapeblue.com )
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
>=20
> -----Original Message-----
> From: Tutkowski, Mike [mailto:Mike.Tutkowski@netapp.com]
> Sent: 27 June 2017 01:25
> To: dev@cloudstack.apache.org
> Cc: Wido den Hollander <wido@widodh.nl>
> Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3
>=20
> I tend to agree with you here, Daan. I know the downside we=E2=80=99ve
> discussed in the past is that overall community participation in
> the RC process has dropped off when such a new branch is created
> (since the community as a whole tends to focus more on the new
> branch rather than on testing the RC and releasing it).
>=20
> I believe we should do the following: As we approach the first
> RC, we need to limit the number of PRs going into the branch (in
> order to stabilize it). If we had a super duper array of
> automated regression tests that ran against the code, then we
> might be able to avoid this, but our automated test suite is not
> extensive enough for us to do so.
>=20
> As we approach the first RC, only blockers and trivial (ex. text
> changes)
> PRs should be permitted in. Once we cut the first RC, create a
> new branch for ongoing dev work. In between RCs, we can only
> allow in code related to blocker PRs (or trivial text changes, as
> discussed before).
>=20
> What do people think?
>=20
> On 6/13/17, 4:56 AM, "Daan Hoogland" <daan.hoogland@gmail.com>
> wrote:
>=20
> this is why i say we should branch on first RC, fix in release
> branch only and merge forward
>=20
> On Tue, Jun 13, 2017 at 12:41 PM, Will Stevens <
> williamstevens@gmail.com> wrote:
>=20
> I know it is hard to justify not merging PRs that seem ready but
> are
>=20
> not
>=20
> blockers in an RC, but it is a vicious circle which ultimately
>=20
> results in a
>=20
> longer RC process.
>=20
> It is something i struggled with as a release manager as well.
>=20
> On Jun 13, 2017 1:56 AM, "Rajani Karuturi" <rajani@apache.org>
>=20
> wrote:
>=20
> Thanks Mike,
>=20
> Will hold off next RC until we hear an update from you.
>=20
> Regarding merging non-blockers, unfortunately, its a side-effect
> of taking more than three months in the RC phase :(
>=20
> Thanks,
>=20
> ~ Rajani
>=20
> http://cloudplatform.accelerite.com/
>=20
> On June 13, 2017 at 10:10 AM, Tutkowski, Mike
> (Mike.Tutkowski@netapp.com) wrote:
>=20
> Hi everyone,
>=20
> I had a little time this evening and re-ran some VMware-related
> tests around managed storage. I noticed a problem that I=E2=80=99d like
> to investigate before we spin up the next RC. Let=E2=80=99s hold off on
> the next RC until I can find out more (I should know more within
> 24 hours).
>=20
> Thanks!
> Mike
>=20
> On 6/12/17, 2:40 AM, "Wido den Hollander" <wido@widodh.nl>
> wrote:
>=20
> Op 10 juni 2017 om 21:18 schreef "Tutkowski, Mike"
>=20
> <Mike.Tutkowski@netapp.com>:
>=20
> Hi,
>=20
> I opened a PR against the most recent RC:
>=20
> https://github.com/apache/cloudstack/pull/2141
>=20
> I ran all managed-storage regression tests against it and they
>=20
> pass (as noted in detail in the PR).
>=20
> If someone wants to take this code and create a new RC from
>=20
> it, I=E2=80=99m +1 on the new RC as long as this is the only commit
> addedto it since the current RC.
>=20
> Thanks Mike!
>=20
> If this PR is good we should probably merge it asap and go for
> RC5.
>=20
> 4.10 should really be released by now.
>=20
> Wido
>=20
> Thanks!
> Mike
>=20
> On 6/9/17, 7:43 PM, "Tutkowski, Mike"
>=20
> <Mike.Tutkowski@netapp.com> wrote:
>=20
> Hi everyone,
>=20
> I found a critical issue that was introduced into this RC
>=20
> since the most recent RC, so I am -1 on this RC.
>=20
> The fix for this ticket breaks the support for storing volume
>=20
> snapshots on primary storage (which is a feature managed
> storagecan support):
>=20
> https://issues.apache.org/jira/browse/CLOUDSTACK-9685
>=20
> Here is the SHA: 336df84f1787de962a67d0a34551f9027303040e
>=20
> At a high level, what it does is remove a row from the
>=20
> cloud.snapshot_store_ref table when a volume is deleted that
> hasone or more volume snapshots.
>=20
> This is fine for non-managed (traditional) storage; however,
>=20
> managed storage can store volume snapshots on primary storage,
> soremoving this row breaks that functionality.
>=20
> I can fix the problem that this commit introduced by looking
>=20
> at the primary storage that supports the volume snapshot
> andchecking the following: 1) Is this managed storage? 2) If yes,
> is the snapshot in question stored on that primary storage?
>=20
> The problem is I will be out of the office for a couple weeks
>=20
> and will not be able to address this until I return.
>=20
> We could revert the commit, but I still will not have time to
>=20
> run the managed-storage regression test suite until I return.
>=20
> On a side note, it looks like this commit was introduced since
>=20
> the most recent RC. I would argue that it was not a blocker
> andshould not have been placed into the new RC. We (as a
> community)
> tend to have a lot of code go in between RCs and that just
> increases the chances of introducing critical issues and thus
> delaying the release. We=E2=80=99ve gotten better at this over the years,
> but we should focus more on only allowing the entry of new code
> into a follow-on RC that is critical (or so trivial as to not at
> all be likely to introduce any problems=E2=80=A6like fixing an error
> message).
>=20
> Thanks for your efforts on this, everyone!
> Mike
>=20
> On 6/9/17, 8:52 AM, "Tutkowski, Mike"
>=20
> <Mike.Tutkowski@netapp.com> wrote:
>=20
> Hi Rajani,
>=20
> I will see if I can get all of my managed-storage testing
>=20
> (both automated and manual) done today. If not, we=E2=80=99ll need to
> seeif someone else can complete it before we OK this RC as I
> won=E2=80=99t be back in the office for a couple weeks. I=E2=80=99ll repo=
rt back
> later today.
>=20
> Thanks,
> Mike
>=20
> On 6/9/17, 2:34 AM, "Rajani Karuturi" <rajani@apache.org>
>=20
> wrote:
>=20
> Yup. thats right. I dont know how it happened but, it created
> from the previous RC commit. The script is supposed to do a
>=20
> git
>=20
> pull. I didn't notice any failures. Not sure what went wrong.
>=20
> Thanks for finding it mike. I am creating RC4 now and
>=20
> cancelling
>=20
> this.
>=20
> ~ Rajani
>=20
> http://cloudplatform.accelerite.com/
>=20
> On June 9, 2017 at 12:07 PM, Tutkowski, Mike
> (Mike.Tutkowski@netapp.com) wrote:
>=20
> Hi Rajani,
>=20
> I don=E2=80=99t see the following PR in this RC:
>=20
> https://github.com/apache/cloudstack/pull/2098
>=20
> I ran all of my managed-storage regression tests. They all
> passed with the exception of the one that led to PR 2098.
>=20
> As I examine the RC in a bit more detail, it sits on top of
> ed2f573, but I think it should sit on top of ed376fc.
>=20
> As a result, I am -1 on the RC.
>=20
> It takes me about a day to run all of the managed-storage
> regression tests and I am out of the office for the next
>=20
> couple
>=20
> weeks, so I=E2=80=99d really like to avoid another RC until I=E2=80=99m b=
ack
>=20
> and
>=20
> able to test the next RC.
>=20
> Thanks!
> Mike
>=20
> On 6/7/17, 4:36 AM, "Rajani Karuturi" <rajani@apache.org>
>=20
> wrote:
>=20
> Hi All,
>=20
> I've created 4.10.0.0 release with the following artifacts up
> for a vote:
>=20
> Git Branch and Commit SH:
>=20
> https://gitbox.apache.org/repos/asf?p=3Dcloudstack.git;a=3Dcommit;h=3Da55=
738a31d0073f2925c6fb84bf7a6bb32f4ca27
>=20
> Commit:a55738a31d0073f2925c6fb84bf7a6bb32f4ca27
> Branch: 4.10.0.0-RC20170607T1407
>=20
> Source release (checksums and signatures are available at the
> same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
>=20
> SystemVm Templates:
> http://download.cloudstack.org/systemvm/4.10/RC3/
>=20
> PGP release keys (signed using CBB44821):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>=20
> Vote will be open for 72 hours.
>=20
> For sanity in tallying the vote, can PMC members please be
>=20
> sure
>=20
> to indicate
> "(binding)" with their vote?
>=20
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>=20
> Thanks,
> ~Rajani
> http://cloudplatform.accelerite.com/
>=20
> --
> Daan
>=20
> --
> Rafael Weing=C3=A4rtner