Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Rajani Karuturi]

We can do a release every month as long as we have enough people
actively participating in the release process.

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.

I would ask everyone to start testing releases/PRs and voting on
them actively.

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.

Whether we create a branch off RC or continue on master wont
change the current situation.

We, as community should commit to testing and releasing code.
principles and theory wont help.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On June 27, 2017 at 9:43 PM, Rafael Weingärtner
(rafaelweingart...@gmail.com) wrote:

+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?

[1]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up#ReleaseprinciplesforApacheCloudStack4.6andup-Preparingnewrelease:masterfrozen

On Tue, Jun 27, 2017 at 1:32 AM, Paul Angus

wrote:

Hi All,

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

People sliding new changes/bug fixes/enhancements in are not
making the
product better, they're stopping progress. As we can clearly see
here.

Kind regards,

Paul Angus

paul.an...@shapeblue.com
www.shapeblue.com ( http://www.shapeblue.com )
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue

-Original Message-
From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com]
Sent: 27 June 2017 01:25
To: dev@cloudstack.apache.org
Cc: Wido den Hollander 
Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

I tend to agree with you here, Daan. I know the downside we’ve
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).

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.

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).

What do people think?

On 6/13/17, 4:56 AM, "Daan Hoogland" 
wrote:

this is why i say we should branch on first RC, fix in release
branch
only and merge forward

On Tue, Jun 13, 2017 at 12:41 PM, Will Stevens <
williamstev...@gmail.com> wrote:

I know it is hard to justify not merging PRs that seem ready but
are

not

blockers in an RC, but it is a vicious circle which ultimately

results in a

longer RC process.

It is something i struggled with as a release manager as well.

On Jun 13, 2017 1:56 AM, "Rajani Karuturi" 

wrote:

Thanks Mike,

Will hold off next RC until we hear an update from you.

Regarding merging non-blockers, unfortunately, its a side-effect
of taking more than three months in the RC phase :(

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On June 13, 2017 at 10:10 AM, Tutkowski, Mike
(mike.tutkow...@netapp.com) wrote:

Hi everyone,

I had a little time this evening and re-ran some VMware-related
tests around managed storage. I noticed a problem that I’d like
to investigate before we spin up the next RC. Let’s hold off on
the next RC until I can find out more (I should know more within
24 hours).

Thanks!
Mike

On 6/12/17, 2:40 AM, "Wido den Hollander" 
wrote:

Op 10 juni 2017 om 21:18 schreef "Tutkowski, Mike"

:

Hi,

I opened a PR against the most recent RC:

https://github.com/apache/cloudstack/pull/2141

I ran all managed-storage 

Re: [VOTE] Apache CloudStack 4.10.0.0 RC6

[Rajani Karuturi]

Hi Kris,

Can you please apply 2162 locally and see if you are OK with the
changes? We shouldn't be spending one RC cycle for one issue.

Ideally, we should have more CIs running on PRs from different
usage perspectives(like managed storage, nuage, basic network,
local storage, etc.). That would help uncover issues before they
are merged.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On June 27, 2017 at 8:14 PM, Kris Sterckx
(kris.ster...@nuagenetworks.net) wrote:

Hi all,

I 'm sorry for voting -1 again.

Issue : https://issues.apache.org/jira/browse/CLOUDSTACK-9980

Caused by : https://github.com/apache/cloudstack/pull/2089

Fixed by : https://github.com/apache/cloudstack/pull/2162

Kris

- Nuage Networks

On 26 June 2017 at 18:58, Tutkowski, Mike
 wrote:

+1 (binding)

I am not concerned about the code changes that went into this RC
since the
previous RC, so I am still happy with the amount of automated
and manual
testing that I performed on a previous RC.

On 6/25/17, 11:07 PM, "Rajani Karuturi" 
wrote:

Hi All,

I've created 4.10.0.0 release with the following artifacts up
for a
vote:

Git Branch and Commit SH:
https://github.com/apache/cloudstack/commit/
0272d1da0ed11ce6c884b05d630e9f46674c58ff
Commit:0272d1da0ed11ce6c884b05d630e9f46674c58ff
Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-
RC20170626T1011

Source release (checksums and signatures are available at the
same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

SystemVm Templates:
http://download.cloudstack.org/systemvm/4.10/RC6/

PRs merged since RC4: #2150 and #2089
PRs merged since RC5: revert of #2084

PGP release keys (signed using CBB44821):
https://dist.apache.org/repos/dist/release/cloudstack/KEYS

Vote will be open for 72 hours.

For sanity in tallying the vote, can PMC members please be sure
to
indicate
"(binding)" with their vote?

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Thanks,
~Rajani
http://cloudplatform.accelerite.com/

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Tutkowski, Mike]

I'm glad you guys (Paul and Rafael) agree with me. We should cut a branch once 
the first RC is built. Then we should only allow blockers in to fix RC issues.

This should speed up our releases in the future.

> On Jun 27, 2017, at 10:14 AM, Rafael Weingärtner 
>  wrote:
> 
> +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?
> 
> [1]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up#ReleaseprinciplesforApacheCloudStack4.6andup-Preparingnewrelease:masterfrozen
> 
> On Tue, Jun 27, 2017 at 1:32 AM, Paul Angus 
> wrote:
> 
>> Hi All,
>> 
>> 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.
>> 
>> People sliding new changes/bug fixes/enhancements in are not making the
>> product better, they're stopping progress.  As we can clearly see here.
>> 
>> 
>> Kind regards,
>> 
>> Paul Angus
>> 
>> paul.an...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
>> 
>> 
>> 
>> 
>> -Original Message-
>> From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com]
>> Sent: 27 June 2017 01:25
>> To: dev@cloudstack.apache.org
>> Cc: Wido den Hollander 
>> Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3
>> 
>> I tend to agree with you here, Daan. I know the downside we’ve 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).
>> 
>> 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.
>> 
>> 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).
>> 
>> What do people think?
>> 
>> On 6/13/17, 4:56 AM, "Daan Hoogland"  wrote:
>> 
>>this is why i say we should branch on first RC, fix in release branch
>>only and merge forward
>> 
>>On Tue, Jun 13, 2017 at 12:41 PM, Will Stevens <
>> williamstev...@gmail.com> wrote:
>>> I know it is hard to justify not merging PRs that seem ready but are
>> not
>>> blockers in an RC, but it is a vicious circle which ultimately
>> results in a
>>> longer RC process.
>>> 
>>> It is something i struggled with as a release manager as well.
>>> 
>>> On Jun 13, 2017 1:56 AM, "Rajani Karuturi" 
>> wrote:
>>> 
>>> Thanks Mike,
>>> 
>>> Will hold off next RC until we hear an update from you.
>>> 
>>> Regarding merging non-blockers, unfortunately, its a side-effect
>>> of taking more than three months in the RC phase :(
>>> 
>>> Thanks,
>>> 
>>> ~ Rajani
>>> 
>>> http://cloudplatform.accelerite.com/
>>> 
>>> On June 13, 2017 at 10:10 AM, Tutkowski, Mike
>>> (mike.tutkow...@netapp.com) wrote:
>>> 
>>> Hi everyone,
>>> 
>>> I had a little time this evening and re-ran some VMware-related
>>> tests around managed storage. I noticed a problem that I’d like
>>> to investigate before we spin up the next RC. Let’s hold off on
>>> the next RC until I can find out more (I should know more within
>>> 24 hours).
>>> 
>>> Thanks!
>>> Mike
>>> 
>>> On 6/12/17, 2:40 AM, "Wido den Hollander" 
>>> wrote:
>>> 
 Op 10 juni 2017 om 21:18 schreef "Tutkowski, Mike"
>>> :
 
 
 Hi,
 
 I opened a PR against the most recent RC:
>>> https://github.com/apache/cloudstack/pull/2141
 
 I ran all managed-storage regression tests against it and they
>>> pass (as noted in detail in the PR).
 
 If someone wants to take this code and create a new RC from
>>> it, I’m +1 on the new RC as long as this is the only commit added
>>> to it since the current RC.
>>> 
>>> Thanks Mike!
>>> 
>>> If this PR is good we should 

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Rafael Weingärtner]

+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?

[1]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up#ReleaseprinciplesforApacheCloudStack4.6andup-Preparingnewrelease:masterfrozen

On Tue, Jun 27, 2017 at 1:32 AM, Paul Angus 
wrote:

> Hi All,
>
> 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.
>
> People sliding new changes/bug fixes/enhancements in are not making the
> product better, they're stopping progress.  As we can clearly see here.
>
>
> Kind regards,
>
> Paul Angus
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>
> -Original Message-
> From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com]
> Sent: 27 June 2017 01:25
> To: dev@cloudstack.apache.org
> Cc: Wido den Hollander 
> Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3
>
> I tend to agree with you here, Daan. I know the downside we’ve 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).
>
> 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.
>
> 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).
>
> What do people think?
>
> On 6/13/17, 4:56 AM, "Daan Hoogland"  wrote:
>
> this is why i say we should branch on first RC, fix in release branch
> only and merge forward
>
> On Tue, Jun 13, 2017 at 12:41 PM, Will Stevens <
> williamstev...@gmail.com> wrote:
> > I know it is hard to justify not merging PRs that seem ready but are
> not
> > blockers in an RC, but it is a vicious circle which ultimately
> results in a
> > longer RC process.
> >
> > It is something i struggled with as a release manager as well.
> >
> > On Jun 13, 2017 1:56 AM, "Rajani Karuturi" 
> wrote:
> >
> > Thanks Mike,
> >
> > Will hold off next RC until we hear an update from you.
> >
> > Regarding merging non-blockers, unfortunately, its a side-effect
> > of taking more than three months in the RC phase :(
> >
> > Thanks,
> >
> > ~ Rajani
> >
> > http://cloudplatform.accelerite.com/
> >
> > On June 13, 2017 at 10:10 AM, Tutkowski, Mike
> > (mike.tutkow...@netapp.com) wrote:
> >
> > Hi everyone,
> >
> > I had a little time this evening and re-ran some VMware-related
> > tests around managed storage. I noticed a problem that I’d like
> > to investigate before we spin up the next RC. Let’s hold off on
> > the next RC until I can find out more (I should know more within
> > 24 hours).
> >
> > Thanks!
> > Mike
> >
> > On 6/12/17, 2:40 AM, "Wido den Hollander" 
> > wrote:
> >
> >> Op 10 juni 2017 om 21:18 schreef "Tutkowski, Mike"
> > :
> >>
> >>
> >> Hi,
> >>
> >> I opened a PR against the most recent RC:
> > https://github.com/apache/cloudstack/pull/2141
> >>
> >> I ran all managed-storage regression tests against it and they
> > pass (as noted in detail in the PR).
> >>
> >> If someone wants to take this code and create a new RC from
> > it, I’m +1 on the new RC as long as this is the only commit added
> > to it since the current RC.
> >
> > Thanks Mike!
> >
> > If this PR is good we should probably merge it asap and go for
> > RC5.
> >
> > 4.10 should really be released by now.
> >
> > Wido
> >
> >>
> >> Thanks!
> >> Mike
> >>
> >> On 6/9/17, 

Re: [VOTE] Apache CloudStack 4.10.0.0 RC6

[Kris Sterckx]

Hi all,

I 'm sorry for voting -1 again.

Issue : https://issues.apache.org/jira/browse/CLOUDSTACK-9980

Caused by : https://github.com/apache/cloudstack/pull/2089

Fixed by : https://github.com/apache/cloudstack/pull/2162


Kris

- Nuage Networks

On 26 June 2017 at 18:58, Tutkowski, Mike  wrote:

> +1 (binding)
>
> I am not concerned about the code changes that went into this RC since the
> previous RC, so I am still happy with the amount of automated and manual
> testing that I performed on a previous RC.
>
> On 6/25/17, 11:07 PM, "Rajani Karuturi"  wrote:
>
> Hi All,
>
> I've created 4.10.0.0 release with the following artifacts up for a
> vote:
>
> Git Branch and Commit SH:
> https://github.com/apache/cloudstack/commit/
> 0272d1da0ed11ce6c884b05d630e9f46674c58ff
> Commit:0272d1da0ed11ce6c884b05d630e9f46674c58ff
> Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-
> RC20170626T1011
>
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
>
> SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC6/
>
> PRs merged since RC4: #2150 and #2089
> PRs merged since RC5: revert of #2084
>
> PGP release keys (signed using CBB44821):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> Vote will be open for 72 hours.
>
> For sanity in tallying the vote, can PMC members please be sure to
> indicate
> "(binding)" with their vote?
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Thanks,
> ~Rajani
> http://cloudplatform.accelerite.com/
>
>
>

Re: ***Cloudstack EUUG - CFP***

[Marc-Aurèle Brothier]

Hi Giles,

I could give a talk on live migration with KVM that we have since one year
here. That might help to get the feature fixed and merged for CS. Let me
know.
https://github.com/apache/cloudstack/pull/1709

Marc-Aurèle

On Thu, Jun 22, 2017 at 1:41 PM, Wido den Hollander  wrote:

> Hi,
>
> Registered and arranged travel!
>
> I can give a short IPv6 talk (again?). Aug 17th we should be running the
> 4.10 code in production so I can share some details en demos?
>
> Wido
>
> > Op 22 juni 2017 om 11:42 schreef Giles Sirett <
> giles.sir...@shapeblue.com>:
> >
> >
> > All
> > The next Cloudstack European User Group will be in 17 August in London
> > I'm just putting the agenda together at the moment. If anybodys got a
> cloudstack-related talk they'd like to present then ping me.
> >
> > For those that don't fancy speaking, it would be great to see as many of
> you there as possible
> >
> > https://www.eventbrite.co.uk/e/cloudstack-european-user-
> group-tickets-35565783215?aff=es2
> >
> >
> > Kind regards
> > Giles
> >
> >
> > giles.sir...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
>