subject:"RE\: \[PROPOSE\] RM for 4.11"

Re: [PROPOSE] RM for 4.11

2017-12-01 Thread Rohit Yadav

Thanks everyone for your support (and statues :) ).


I look forward to working with everyone for the next best CloudStack release.


Regards.


From: Simon Weller <swel...@ena.com.INVALID>
Sent: Friday, December 1, 2017 1:12:21 AM
To: dev@cloudstack.apache.org
Subject: Re: [PROPOSE] RM for 4.11

Great Rohit! We'll provide as much support to you guys as we can.


From: Rohit Yadav <bhais...@apache.org>
Sent: Wednesday, November 29, 2017 4:14 AM
To: dev@cloudstack.apache.org
Subject: [PROPOSE] RM for 4.11

Hi All,

I’d like to put myself forward as release manager for 4.11. The 4.11
releases will be the next major version LTS release since 4.9 and will be
supported for 20 months per the LTS manifesto [2] until 1 July 2019.

Daan Hoogland and Paul Angus will assist during the process and all of us
will be the gatekeepers for reviewing/testing/merging the PRs, others will
be welcome to support as well.

As a community member, I will try to help get PRs reviewed, tested and
merged (as would everyone else I hope) but with an RM hat on I would like
to see if we can make that role less inherently life-consuming and put the
onus back on the community to get stuff done.

Here the plan:
1. As RM I put forward the freeze date of the 8th of January 2018, hoping
for community approval.
2. After the freeze date (8th Jan) until GA release, features will not be
allowed and fixes only as long as there are blocker issues outstanding.
Fixes for other issues will be individually judged on their merit and risk.
3. RM will triage/report critical and blocker bugs for 4.11 [4] and
encourage people to get them fixed.
4. RM will create RCs and start voting once blocker bugs are cleared and
baseline smoke test results are on par with previous 4.9.3.0/4.10.0.0 smoke
test results.
5. RM will allocate at least a week for branch stabilization and testing.
At the earliest, on 15th January, RM will put 4.11.0.0-rc1 for voting from
the 4.11 branch, and master will be open to accepting new features.
6. RM will repeat 3-5 as required. Voting/testing of -rc2, -rc3 and so on
will be created as required.
7. Once vote passes - RM will continue with the release procedures [1].

In conjunction with that, I also propose and put forward the date of 4.12
cut-off as 4 months [3] after GA release of 4.11 (so everyone knows when
the next one is coming hopefully giving peace of mind to those who have
features which would not make the proposed 4.11 cut off).

I’d like the community (including myself and colleagues) to:
- Up to 8th January, community members try to review, test and merge as
many fixes as possible, while super-diligent to not de-stabilize the master
branch.
- Engage with gatekeepers to get your PRs reviewed, tested and merged
(currently myself, Daan and Paul, others are welcome to engage as well). Do
not merge the PRs
- A pull request may be reverted where the author(s) are not responding and
authors may be asked to re-submit their changes after taking suitable
remedies.
- Find automated method to show (at a glance) statuses of PRs with respect
to:
  · Number of LGTMs
  · Smoke tests
  · Functional tests
  · Travis tests passing
  · Mergeability
- Perform a weekly run of a component-test matrix against the master branch
before Jan 8th cut off (based on current hypervisors including basic (KVM)
and advanced networking).
- Continue to fix broken tests.

Thoughts, feedback, comments?

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
Release Procedure - Apache Cloudstack - Apache Software 
...<https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure>
cwiki.apache.org
This page describes the steps that a release manager needs to take to perform a 
release of Apache CloudStack. (Thanks to the couchdb project for a great 
template to ...



[2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
LTS - Apache Cloudstack - Apache Software 
Foundation<https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS>
cwiki.apache.org
The project plans to produce the following types of releases: Regular: 
Introduce new features and enhancements. These releases are targeted for users 
who require the ...



[3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
Releases - Apache Cloudstack - Apache Software 
Foundation<https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases>
cwiki.apache.org
Overview. All available releases can be found on the Apache CloudStack 
project's website, on the Downloads page. The release-specific child pages in 
this wiki are not ...



[4] The current list of blocker and critical bugs currently stands as per
the following list:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CLOUDSTACK%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20priority%20in%20(Blocker%2C%20Critical)%20AND%20affectedVersion%20i

Re: [PROPOSE] RM for 4.11

2017-11-30 Thread Simon Weller

Great Rohit! We'll provide as much support to you guys as we can.

From: Rohit Yadav 
Sent: Wednesday, November 29, 2017 4:14 AM
To: dev@cloudstack.apache.org
Subject: [PROPOSE] RM for 4.11

Hi All,

I’d like to put myself forward as release manager for 4.11. The 4.11
releases will be the next major version LTS release since 4.9 and will be
supported for 20 months per the LTS manifesto [2] until 1 July 2019.

Daan Hoogland and Paul Angus will assist during the process and all of us
will be the gatekeepers for reviewing/testing/merging the PRs, others will
be welcome to support as well.

As a community member, I will try to help get PRs reviewed, tested and
merged (as would everyone else I hope) but with an RM hat on I would like
to see if we can make that role less inherently life-consuming and put the
onus back on the community to get stuff done.

Here the plan:
1. As RM I put forward the freeze date of the 8th of January 2018, hoping
for community approval.
2. After the freeze date (8th Jan) until GA release, features will not be
allowed and fixes only as long as there are blocker issues outstanding.
Fixes for other issues will be individually judged on their merit and risk.
3. RM will triage/report critical and blocker bugs for 4.11 [4] and
encourage people to get them fixed.
4. RM will create RCs and start voting once blocker bugs are cleared and
baseline smoke test results are on par with previous 4.9.3.0/4.10.0.0 smoke
test results.
5. RM will allocate at least a week for branch stabilization and testing.
At the earliest, on 15th January, RM will put 4.11.0.0-rc1 for voting from
the 4.11 branch, and master will be open to accepting new features.
6. RM will repeat 3-5 as required. Voting/testing of -rc2, -rc3 and so on
will be created as required.
7. Once vote passes - RM will continue with the release procedures [1].

In conjunction with that, I also propose and put forward the date of 4.12
cut-off as 4 months [3] after GA release of 4.11 (so everyone knows when
the next one is coming hopefully giving peace of mind to those who have
features which would not make the proposed 4.11 cut off).

I’d like the community (including myself and colleagues) to:
- Up to 8th January, community members try to review, test and merge as
many fixes as possible, while super-diligent to not de-stabilize the master
branch.
- Engage with gatekeepers to get your PRs reviewed, tested and merged
(currently myself, Daan and Paul, others are welcome to engage as well). Do
not merge the PRs
- A pull request may be reverted where the author(s) are not responding and
authors may be asked to re-submit their changes after taking suitable
remedies.
- Find automated method to show (at a glance) statuses of PRs with respect
to:
  · Number of LGTMs
  · Smoke tests
  · Functional tests
  · Travis tests passing
  · Mergeability
- Perform a weekly run of a component-test matrix against the master branch
before Jan 8th cut off (based on current hypervisors including basic (KVM)
and advanced networking).
- Continue to fix broken tests.

Thoughts, feedback, comments?

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
Release Procedure - Apache Cloudstack - Apache Software 
...
cwiki.apache.org
This page describes the steps that a release manager needs to take to perform a 
release of Apache CloudStack. (Thanks to the couchdb project for a great 
template to ...

[2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
LTS - Apache Cloudstack - Apache Software 
Foundation
cwiki.apache.org
The project plans to produce the following types of releases: Regular: 
Introduce new features and enhancements. These releases are targeted for users 
who require the ...

[3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
Releases - Apache Cloudstack - Apache Software 
Foundation
cwiki.apache.org
Overview. All available releases can be found on the Apache CloudStack 
project's website, on the Downloads page. The release-specific child pages in 
this wiki are not ...

[4] The current list of blocker and critical bugs currently stands as per
the following list:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CLOUDSTACK%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20priority%20in%20(Blocker%2C%20Critical)%20AND%20affectedVersion%20in%20(4.10.0.0%2C%204.10.1.0%2C%204.11.0.0%2C%20Future)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

Regards,
Rohit Yadav

Re: [PROPOSE] RM for 4.11

2017-11-30 Thread Milamber

Looks good to me Rohit. Thank you and good luck

On 29/11/2017 10:14, Rohit Yadav wrote:

Hi All,

I’d like to put myself forward as release manager for 4.11. The 4.11
releases will be the next major version LTS release since 4.9 and will be
supported for 20 months per the LTS manifesto [2] until 1 July 2019.

Daan Hoogland and Paul Angus will assist during the process and all of us
will be the gatekeepers for reviewing/testing/merging the PRs, others will
be welcome to support as well.

As a community member, I will try to help get PRs reviewed, tested and
merged (as would everyone else I hope) but with an RM hat on I would like
to see if we can make that role less inherently life-consuming and put the
onus back on the community to get stuff done.

Here the plan:
1. As RM I put forward the freeze date of the 8th of January 2018, hoping
for community approval.
2. After the freeze date (8th Jan) until GA release, features will not be
allowed and fixes only as long as there are blocker issues outstanding.
Fixes for other issues will be individually judged on their merit and risk.
3. RM will triage/report critical and blocker bugs for 4.11 [4] and
encourage people to get them fixed.
4. RM will create RCs and start voting once blocker bugs are cleared and
baseline smoke test results are on par with previous 4.9.3.0/4.10.0.0 smoke
test results.
5. RM will allocate at least a week for branch stabilization and testing.
At the earliest, on 15th January, RM will put 4.11.0.0-rc1 for voting from
the 4.11 branch, and master will be open to accepting new features.
6. RM will repeat 3-5 as required. Voting/testing of -rc2, -rc3 and so on
will be created as required.
7. Once vote passes - RM will continue with the release procedures [1].

In conjunction with that, I also propose and put forward the date of 4.12
cut-off as 4 months [3] after GA release of 4.11 (so everyone knows when
the next one is coming hopefully giving peace of mind to those who have
features which would not make the proposed 4.11 cut off).

I’d like the community (including myself and colleagues) to:
- Up to 8th January, community members try to review, test and merge as
many fixes as possible, while super-diligent to not de-stabilize the master
branch.
- Engage with gatekeepers to get your PRs reviewed, tested and merged
(currently myself, Daan and Paul, others are welcome to engage as well). Do
not merge the PRs
- A pull request may be reverted where the author(s) are not responding and
authors may be asked to re-submit their changes after taking suitable
remedies.
- Find automated method to show (at a glance) statuses of PRs with respect
to:
· Number of LGTMs
· Smoke tests
· Functional tests
· Travis tests passing
· Mergeability
- Perform a weekly run of a component-test matrix against the master branch
before Jan 8th cut off (based on current hypervisors including basic (KVM)
and advanced networking).
- Continue to fix broken tests.

Thoughts, feedback, comments?

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
[2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
[3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
[4] The current list of blocker and critical bugs currently stands as per
the following list:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CLOUDSTACK%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20priority%20in%20(Blocker%2C%20Critical)%20AND%20affectedVersion%20in%20(4.10.0.0%2C%204.10.1.0%2C%204.11.0.0%2C%20Future)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

Regards,
Rohit Yadav

Re: [PROPOSE] RM for 4.11

2017-11-30 Thread Nux!

Hehe, good job.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Giles Sirett" <giles.sir...@shapeblue.com>
> To: "dev" <dev@cloudstack.apache.org>
> Sent: Thursday, 30 November, 2017 11:29:18
> Subject: RE: [PROPOSE] RM for 4.11

> We built said statue at collab in Miami this year..
> https://twitter.com/shapeblue/status/936194768589254656
> 
> 
> Kind regards
> Giles
> 
> giles.sir...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>  
> 
> 
> 
> -Original Message-
> From: Nux! [mailto:n...@li.nux.ro]
> Sent: 29 November 2017 16:25
> To: dev <dev@cloudstack.apache.org>
> Subject: Re: [PROPOSE] RM for 4.11
> 
> That's great, Rohit!
> 
> I'm in talks with some folks to build you a statue. ;-) (Hope it'll turn out
> better than Ronaldo's..)
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
>> From: "Rohit Yadav" <bhais...@apache.org>
>> To: "dev" <dev@cloudstack.apache.org>
>> Sent: Wednesday, 29 November, 2017 10:14:54
>> Subject: [PROPOSE] RM for 4.11
> 
>> Hi All,
>> 
>> I’d like to put myself forward as release manager for 4.11. The 4.11
>> releases will be the next major version LTS release since 4.9 and will
>> be supported for 20 months per the LTS manifesto [2] until 1 July 2019.
>> 
>> Daan Hoogland and Paul Angus will assist during the process and all of
>> us will be the gatekeepers for reviewing/testing/merging the PRs,
>> others will be welcome to support as well.
>> 
>> As a community member, I will try to help get PRs reviewed, tested and
>> merged (as would everyone else I hope) but with an RM hat on I would
>> like to see if we can make that role less inherently life-consuming
>> and put the onus back on the community to get stuff done.
>> 
>> Here the plan:
>> 1. As RM I put forward the freeze date of the 8th of January 2018,
>> hoping for community approval.
>> 2. After the freeze date (8th Jan) until GA release, features will not
>> be allowed and fixes only as long as there are blocker issues outstanding.
>> Fixes for other issues will be individually judged on their merit and risk.
>> 3. RM will triage/report critical and blocker bugs for 4.11 [4] and
>> encourage people to get them fixed.
>> 4. RM will create RCs and start voting once blocker bugs are cleared
>> and baseline smoke test results are on par with previous
>> 4.9.3.0/4.10.0.0 smoke test results.
>> 5. RM will allocate at least a week for branch stabilization and testing.
>> At the earliest, on 15th January, RM will put 4.11.0.0-rc1 for voting
>> from the 4.11 branch, and master will be open to accepting new features.
>> 6. RM will repeat 3-5 as required. Voting/testing of -rc2, -rc3 and so
>> on will be created as required.
>> 7. Once vote passes - RM will continue with the release procedures [1].
>> 
>> In conjunction with that, I also propose and put forward the date of
>> 4.12 cut-off as 4 months [3] after GA release of 4.11 (so everyone
>> knows when the next one is coming hopefully giving peace of mind to
>> those who have features which would not make the proposed 4.11 cut off).
>> 
>> I’d like the community (including myself and colleagues) to:
>> - Up to 8th January, community members try to review, test and merge
>> as many fixes as possible, while super-diligent to not de-stabilize
>> the master branch.
>> - Engage with gatekeepers to get your PRs reviewed, tested and merged
>> (currently myself, Daan and Paul, others are welcome to engage as
>> well). Do not merge the PRs
>> - A pull request may be reverted where the author(s) are not
>> responding and authors may be asked to re-submit their changes after
>> taking suitable remedies.
>> - Find automated method to show (at a glance) statuses of PRs with
>> respect
>> to:
>>  · Number of LGTMs
>>  · Smoke tests
>>  · Functional tests
>>  · Travis tests passing
>>  · Mergeability
>> - Perform a weekly run of a component-test matrix against the master
>> branch before Jan 8th cut off (based on current hypervisors including
>> basic (KVM) and advanced networking).
>> - Continue to fix broken tests.
>> 
>> Thoughts, feedback, comments?
>> 
>> [1]
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedu
>> re [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
>> [3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
>> [4] The current list of blocker and critical bugs currently stands as
>> per the following list:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CLOUDSTACK%
>> 20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Open%2C%20%22In%2
>> 0Progress%22%2C%20Reopened)%20AND%20priority%20in%20(Blocker%2C%20Crit
>> ical)%20AND%20affectedVersion%20in%20(4.10.0.0%2C%204.10.1.0%2C%204.11
>> .0.0%2C%20Future)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>> 
>> Regards,
> > Rohit Yadav

RE: [PROPOSE] RM for 4.11

2017-11-30 Thread Giles Sirett

We built said statue at collab in Miami this year..
https://twitter.com/shapeblue/status/936194768589254656


Kind regards
Giles

giles.sir...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Nux! [mailto:n...@li.nux.ro] 
Sent: 29 November 2017 16:25
To: dev <dev@cloudstack.apache.org>
Subject: Re: [PROPOSE] RM for 4.11

That's great, Rohit!

I'm in talks with some folks to build you a statue. ;-) (Hope it'll turn out 
better than Ronaldo's..)

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Rohit Yadav" <bhais...@apache.org>
> To: "dev" <dev@cloudstack.apache.org>
> Sent: Wednesday, 29 November, 2017 10:14:54
> Subject: [PROPOSE] RM for 4.11

> Hi All,
> 
> I’d like to put myself forward as release manager for 4.11. The 4.11 
> releases will be the next major version LTS release since 4.9 and will 
> be supported for 20 months per the LTS manifesto [2] until 1 July 2019.
> 
> Daan Hoogland and Paul Angus will assist during the process and all of 
> us will be the gatekeepers for reviewing/testing/merging the PRs, 
> others will be welcome to support as well.
> 
> As a community member, I will try to help get PRs reviewed, tested and 
> merged (as would everyone else I hope) but with an RM hat on I would 
> like to see if we can make that role less inherently life-consuming 
> and put the onus back on the community to get stuff done.
> 
> Here the plan:
> 1. As RM I put forward the freeze date of the 8th of January 2018, 
> hoping for community approval.
> 2. After the freeze date (8th Jan) until GA release, features will not 
> be allowed and fixes only as long as there are blocker issues outstanding.
> Fixes for other issues will be individually judged on their merit and risk.
> 3. RM will triage/report critical and blocker bugs for 4.11 [4] and 
> encourage people to get them fixed.
> 4. RM will create RCs and start voting once blocker bugs are cleared 
> and baseline smoke test results are on par with previous 
> 4.9.3.0/4.10.0.0 smoke test results.
> 5. RM will allocate at least a week for branch stabilization and testing.
> At the earliest, on 15th January, RM will put 4.11.0.0-rc1 for voting 
> from the 4.11 branch, and master will be open to accepting new features.
> 6. RM will repeat 3-5 as required. Voting/testing of -rc2, -rc3 and so 
> on will be created as required.
> 7. Once vote passes - RM will continue with the release procedures [1].
> 
> In conjunction with that, I also propose and put forward the date of 
> 4.12 cut-off as 4 months [3] after GA release of 4.11 (so everyone 
> knows when the next one is coming hopefully giving peace of mind to 
> those who have features which would not make the proposed 4.11 cut off).
> 
> I’d like the community (including myself and colleagues) to:
> - Up to 8th January, community members try to review, test and merge 
> as many fixes as possible, while super-diligent to not de-stabilize 
> the master branch.
> - Engage with gatekeepers to get your PRs reviewed, tested and merged 
> (currently myself, Daan and Paul, others are welcome to engage as 
> well). Do not merge the PRs
> - A pull request may be reverted where the author(s) are not 
> responding and authors may be asked to re-submit their changes after 
> taking suitable remedies.
> - Find automated method to show (at a glance) statuses of PRs with 
> respect
> to:
>  · Number of LGTMs
>  · Smoke tests
>  · Functional tests
>  · Travis tests passing
>  · Mergeability
> - Perform a weekly run of a component-test matrix against the master 
> branch before Jan 8th cut off (based on current hypervisors including 
> basic (KVM) and advanced networking).
> - Continue to fix broken tests.
> 
> Thoughts, feedback, comments?
> 
> [1] 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedu
> re [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> [3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
> [4] The current list of blocker and critical bugs currently stands as 
> per the following list:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CLOUDSTACK%
> 20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Open%2C%20%22In%2
> 0Progress%22%2C%20Reopened)%20AND%20priority%20in%20(Blocker%2C%20Crit
> ical)%20AND%20affectedVersion%20in%20(4.10.0.0%2C%204.10.1.0%2C%204.11
> .0.0%2C%20Future)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> 
> Regards,
> Rohit Yadav

Re: [PROPOSE] RM for 4.11

2017-11-29 Thread Marc-Aurèle Brothier - Exoscale

Great Rohit!

I see you started to tag the PR with the milestone 4.11 on github,
that's great! I wish we use more of the little features on github to
help organize the releases and reviews.

Marc-Aurèle

On Wed, 2017-11-29 at 15:44 +0530, Rohit Yadav wrote:
> Hi All,
> 
> I’d like to put myself forward as release manager for 4.11. The 4.11
> releases will be the next major version LTS release since 4.9 and
> will be
> supported for 20 months per the LTS manifesto [2] until 1 July 2019.
> 
> Daan Hoogland and Paul Angus will assist during the process and all
> of us
> will be the gatekeepers for reviewing/testing/merging the PRs, others
> will
> be welcome to support as well.
> 
> As a community member, I will try to help get PRs reviewed, tested
> and
> merged (as would everyone else I hope) but with an RM hat on I would
> like
> to see if we can make that role less inherently life-consuming and
> put the
> onus back on the community to get stuff done.
> 
> Here the plan:
> 1. As RM I put forward the freeze date of the 8th of January 2018,
> hoping
> for community approval.
> 2. After the freeze date (8th Jan) until GA release, features will
> not be
> allowed and fixes only as long as there are blocker issues
> outstanding.
> Fixes for other issues will be individually judged on their merit and
> risk.
> 3. RM will triage/report critical and blocker bugs for 4.11 [4] and
> encourage people to get them fixed.
> 4. RM will create RCs and start voting once blocker bugs are cleared
> and
> baseline smoke test results are on par with previous 4.9.3.0/4.10.0.0
> smoke
> test results.
> 5. RM will allocate at least a week for branch stabilization and
> testing.
> At the earliest, on 15th January, RM will put 4.11.0.0-rc1 for voting
> from
> the 4.11 branch, and master will be open to accepting new features.
> 6. RM will repeat 3-5 as required. Voting/testing of -rc2, -rc3 and
> so on
> will be created as required.
> 7. Once vote passes - RM will continue with the release procedures
> [1].
> 
> In conjunction with that, I also propose and put forward the date of
> 4.12
> cut-off as 4 months [3] after GA release of 4.11 (so everyone knows
> when
> the next one is coming hopefully giving peace of mind to those who
> have
> features which would not make the proposed 4.11 cut off).
> 
> I’d like the community (including myself and colleagues) to:
> - Up to 8th January, community members try to review, test and merge
> as
> many fixes as possible, while super-diligent to not de-stabilize the
> master
> branch.
> - Engage with gatekeepers to get your PRs reviewed, tested and merged
> (currently myself, Daan and Paul, others are welcome to engage as
> well). Do
> not merge the PRs
> - A pull request may be reverted where the author(s) are not
> responding and
> authors may be asked to re-submit their changes after taking suitable
> remedies.
> - Find automated method to show (at a glance) statuses of PRs with
> respect
> to:
>   · Number of LGTMs
>   · Smoke tests
>   · Functional tests
>   · Travis tests passing
>   · Mergeability
> - Perform a weekly run of a component-test matrix against the master
> branch
> before Jan 8th cut off (based on current hypervisors including basic
> (KVM)
> and advanced networking).
> - Continue to fix broken tests.
> 
> Thoughts, feedback, comments?
> 
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Pr
> ocedure
> [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> [3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
> [4] The current list of blocker and critical bugs currently stands as
> per
> the following list:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CLOUDSTACK
> %20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Open%2C%20%22In
> %20Progress%22%2C%20Reopened)%20AND%20priority%20in%20(Blocker%2C%20C
> ritical)%20AND%20affectedVersion%20in%20(4.10.0.0%2C%204.10.1.0%2C%20
> 4.11.0.0%2C%20Future)%20ORDER%20BY%20priority%20DESC%2C%20updated%20D
> ESC
> 
> Regards,
> Rohit Yadav

Re: [PROPOSE] RM for 4.11

2017-11-29 Thread Jayapal Uradi

+1
Thanks Rohit!

> On Nov 30, 2017, at 4:43 AM, Nicolas Vazquez  
> wrote:
> 
> +1
> 
> 
> Thanks Rohit!
> 
> 
> From: Rohit Yadav 
> Sent: Wednesday, November 29, 2017 7:14:54 AM
> To: dev@cloudstack.apache.org
> Subject: [PROPOSE] RM for 4.11
> 
> Hi All,
> 
> I’d like to put myself forward as release manager for 4.11. The 4.11
> releases will be the next major version LTS release since 4.9 and will be
> supported for 20 months per the LTS manifesto [2] until 1 July 2019.
> 
> Daan Hoogland and Paul Angus will assist during the process and all of us
> will be the gatekeepers for reviewing/testing/merging the PRs, others will
> be welcome to support as well.
> 
> As a community member, I will try to help get PRs reviewed, tested and
> merged (as would everyone else I hope) but with an RM hat on I would like
> to see if we can make that role less inherently life-consuming and put the
> onus back on the community to get stuff done.
> 
> Here the plan:
> 1. As RM I put forward the freeze date of the 8th of January 2018, hoping
> for community approval.
> 2. After the freeze date (8th Jan) until GA release, features will not be
> allowed and fixes only as long as there are blocker issues outstanding.
> Fixes for other issues will be individually judged on their merit and risk.
> 3. RM will triage/report critical and blocker bugs for 4.11 [4] and
> encourage people to get them fixed.
> 4. RM will create RCs and start voting once blocker bugs are cleared and
> baseline smoke test results are on par with previous 4.9.3.0/4.10.0.0 smoke
> test results.
> 5. RM will allocate at least a week for branch stabilization and testing.
> At the earliest, on 15th January, RM will put 4.11.0.0-rc1 for voting from
> the 4.11 branch, and master will be open to accepting new features.
> 6. RM will repeat 3-5 as required. Voting/testing of -rc2, -rc3 and so on
> will be created as required.
> 7. Once vote passes - RM will continue with the release procedures [1].
> 
> In conjunction with that, I also propose and put forward the date of 4.12
> cut-off as 4 months [3] after GA release of 4.11 (so everyone knows when
> the next one is coming hopefully giving peace of mind to those who have
> features which would not make the proposed 4.11 cut off).
> 
> I’d like the community (including myself and colleagues) to:
> - Up to 8th January, community members try to review, test and merge as
> many fixes as possible, while super-diligent to not de-stabilize the master
> branch.
> - Engage with gatekeepers to get your PRs reviewed, tested and merged
> (currently myself, Daan and Paul, others are welcome to engage as well). Do
> not merge the PRs
> - A pull request may be reverted where the author(s) are not responding and
> authors may be asked to re-submit their changes after taking suitable
> remedies.
> - Find automated method to show (at a glance) statuses of PRs with respect
> to:
>  · Number of LGTMs
>  · Smoke tests
>  · Functional tests
>  · Travis tests passing
>  · Mergeability
> - Perform a weekly run of a component-test matrix against the master branch
> before Jan 8th cut off (based on current hypervisors including basic (KVM)
> and advanced networking).
> - Continue to fix broken tests.
> 
> Thoughts, feedback, comments?
> 
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
> [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> [3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
> [4] The current list of blocker and critical bugs currently stands as per
> the following list:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CLOUDSTACK%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20priority%20in%20(Blocker%2C%20Critical)%20AND%20affectedVersion%20in%20(4.10.0.0%2C%204.10.1.0%2C%204.11.0.0%2C%20Future)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> 
> Regards,
> Rohit Yadav
> 
> nicolas.vazq...@shapeblue.com 
> www.shapeblue.com
> ,   
> @shapeblue
> 
> 
> 

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: [PROPOSE] RM for 4.11

2017-11-29 Thread Nicolas Vazquez

+1

Thanks Rohit!

From: Rohit Yadav 
Sent: Wednesday, November 29, 2017 7:14:54 AM
To: dev@cloudstack.apache.org
Subject: [PROPOSE] RM for 4.11

Hi All,

I’d like to put myself forward as release manager for 4.11. The 4.11
releases will be the next major version LTS release since 4.9 and will be
supported for 20 months per the LTS manifesto [2] until 1 July 2019.

Daan Hoogland and Paul Angus will assist during the process and all of us
will be the gatekeepers for reviewing/testing/merging the PRs, others will
be welcome to support as well.

As a community member, I will try to help get PRs reviewed, tested and
merged (as would everyone else I hope) but with an RM hat on I would like
to see if we can make that role less inherently life-consuming and put the
onus back on the community to get stuff done.

Here the plan:
1. As RM I put forward the freeze date of the 8th of January 2018, hoping
for community approval.
2. After the freeze date (8th Jan) until GA release, features will not be
allowed and fixes only as long as there are blocker issues outstanding.
Fixes for other issues will be individually judged on their merit and risk.
3. RM will triage/report critical and blocker bugs for 4.11 [4] and
encourage people to get them fixed.
4. RM will create RCs and start voting once blocker bugs are cleared and
baseline smoke test results are on par with previous 4.9.3.0/4.10.0.0 smoke
test results.
5. RM will allocate at least a week for branch stabilization and testing.
At the earliest, on 15th January, RM will put 4.11.0.0-rc1 for voting from
the 4.11 branch, and master will be open to accepting new features.
6. RM will repeat 3-5 as required. Voting/testing of -rc2, -rc3 and so on
will be created as required.
7. Once vote passes - RM will continue with the release procedures [1].

In conjunction with that, I also propose and put forward the date of 4.12
cut-off as 4 months [3] after GA release of 4.11 (so everyone knows when
the next one is coming hopefully giving peace of mind to those who have
features which would not make the proposed 4.11 cut off).

I’d like the community (including myself and colleagues) to:
- Up to 8th January, community members try to review, test and merge as
many fixes as possible, while super-diligent to not de-stabilize the master
branch.
- Engage with gatekeepers to get your PRs reviewed, tested and merged
(currently myself, Daan and Paul, others are welcome to engage as well). Do
not merge the PRs
- A pull request may be reverted where the author(s) are not responding and
authors may be asked to re-submit their changes after taking suitable
remedies.
- Find automated method to show (at a glance) statuses of PRs with respect
to:
  · Number of LGTMs
  · Smoke tests
  · Functional tests
  · Travis tests passing
  · Mergeability
- Perform a weekly run of a component-test matrix against the master branch
before Jan 8th cut off (based on current hypervisors including basic (KVM)
and advanced networking).
- Continue to fix broken tests.

Thoughts, feedback, comments?

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
[2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
[3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
[4] The current list of blocker and critical bugs currently stands as per
the following list:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CLOUDSTACK%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20priority%20in%20(Blocker%2C%20Critical)%20AND%20affectedVersion%20in%20(4.10.0.0%2C%204.10.1.0%2C%204.11.0.0%2C%20Future)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

Regards,
Rohit Yadav

nicolas.vazq...@shapeblue.com 
www.shapeblue.com
,   
@shapeblue

Re: [PROPOSE] RM for 4.11

2017-11-29 Thread Nux!

That's great, Rohit!

I'm in talks with some folks to build you a statue. ;-)
(Hope it'll turn out better than Ronaldo's..)

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Rohit Yadav" 
> To: "dev" 
> Sent: Wednesday, 29 November, 2017 10:14:54
> Subject: [PROPOSE] RM for 4.11

> Hi All,
> 
> I’d like to put myself forward as release manager for 4.11. The 4.11
> releases will be the next major version LTS release since 4.9 and will be
> supported for 20 months per the LTS manifesto [2] until 1 July 2019.
> 
> Daan Hoogland and Paul Angus will assist during the process and all of us
> will be the gatekeepers for reviewing/testing/merging the PRs, others will
> be welcome to support as well.
> 
> As a community member, I will try to help get PRs reviewed, tested and
> merged (as would everyone else I hope) but with an RM hat on I would like
> to see if we can make that role less inherently life-consuming and put the
> onus back on the community to get stuff done.
> 
> Here the plan:
> 1. As RM I put forward the freeze date of the 8th of January 2018, hoping
> for community approval.
> 2. After the freeze date (8th Jan) until GA release, features will not be
> allowed and fixes only as long as there are blocker issues outstanding.
> Fixes for other issues will be individually judged on their merit and risk.
> 3. RM will triage/report critical and blocker bugs for 4.11 [4] and
> encourage people to get them fixed.
> 4. RM will create RCs and start voting once blocker bugs are cleared and
> baseline smoke test results are on par with previous 4.9.3.0/4.10.0.0 smoke
> test results.
> 5. RM will allocate at least a week for branch stabilization and testing.
> At the earliest, on 15th January, RM will put 4.11.0.0-rc1 for voting from
> the 4.11 branch, and master will be open to accepting new features.
> 6. RM will repeat 3-5 as required. Voting/testing of -rc2, -rc3 and so on
> will be created as required.
> 7. Once vote passes - RM will continue with the release procedures [1].
> 
> In conjunction with that, I also propose and put forward the date of 4.12
> cut-off as 4 months [3] after GA release of 4.11 (so everyone knows when
> the next one is coming hopefully giving peace of mind to those who have
> features which would not make the proposed 4.11 cut off).
> 
> I’d like the community (including myself and colleagues) to:
> - Up to 8th January, community members try to review, test and merge as
> many fixes as possible, while super-diligent to not de-stabilize the master
> branch.
> - Engage with gatekeepers to get your PRs reviewed, tested and merged
> (currently myself, Daan and Paul, others are welcome to engage as well). Do
> not merge the PRs
> - A pull request may be reverted where the author(s) are not responding and
> authors may be asked to re-submit their changes after taking suitable
> remedies.
> - Find automated method to show (at a glance) statuses of PRs with respect
> to:
>  · Number of LGTMs
>  · Smoke tests
>  · Functional tests
>  · Travis tests passing
>  · Mergeability
> - Perform a weekly run of a component-test matrix against the master branch
> before Jan 8th cut off (based on current hypervisors including basic (KVM)
> and advanced networking).
> - Continue to fix broken tests.
> 
> Thoughts, feedback, comments?
> 
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
> [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> [3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
> [4] The current list of blocker and critical bugs currently stands as per
> the following list:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CLOUDSTACK%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20priority%20in%20(Blocker%2C%20Critical)%20AND%20affectedVersion%20in%20(4.10.0.0%2C%204.10.1.0%2C%204.11.0.0%2C%20Future)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> 
> Regards,
> Rohit Yadav

Re: [PROPOSE] RM for 4.11

2017-11-29 Thread Rene Moser

Perfect. Thanks Rohit, Daan and Paul!

On 11/29/2017 11:14 AM, Rohit Yadav wrote:
> Hi All,
> 
> I’d like to put myself forward as release manager for 4.11. The 4.11
> releases will be the next major version LTS release since 4.9 and will be
> supported for 20 months per the LTS manifesto [2] until 1 July 2019.
> 
> Daan Hoogland and Paul Angus will assist during the process and all of us
> will be the gatekeepers for reviewing/testing/merging the PRs, others will
> be welcome to support as well.
> 
> As a community member, I will try to help get PRs reviewed, tested and
> merged (as would everyone else I hope) but with an RM hat on I would like
> to see if we can make that role less inherently life-consuming and put the
> onus back on the community to get stuff done.
> 
> Here the plan:
> 1. As RM I put forward the freeze date of the 8th of January 2018, hoping
> for community approval.
> 2. After the freeze date (8th Jan) until GA release, features will not be
> allowed and fixes only as long as there are blocker issues outstanding.
> Fixes for other issues will be individually judged on their merit and risk.
> 3. RM will triage/report critical and blocker bugs for 4.11 [4] and
> encourage people to get them fixed.
> 4. RM will create RCs and start voting once blocker bugs are cleared and
> baseline smoke test results are on par with previous 4.9.3.0/4.10.0.0 smoke
> test results.
> 5. RM will allocate at least a week for branch stabilization and testing.
> At the earliest, on 15th January, RM will put 4.11.0.0-rc1 for voting from
> the 4.11 branch, and master will be open to accepting new features.
> 6. RM will repeat 3-5 as required. Voting/testing of -rc2, -rc3 and so on
> will be created as required.
> 7. Once vote passes - RM will continue with the release procedures [1].
> 
> In conjunction with that, I also propose and put forward the date of 4.12
> cut-off as 4 months [3] after GA release of 4.11 (so everyone knows when
> the next one is coming hopefully giving peace of mind to those who have
> features which would not make the proposed 4.11 cut off).
> 
> I’d like the community (including myself and colleagues) to:
> - Up to 8th January, community members try to review, test and merge as
> many fixes as possible, while super-diligent to not de-stabilize the master
> branch.
> - Engage with gatekeepers to get your PRs reviewed, tested and merged
> (currently myself, Daan and Paul, others are welcome to engage as well). Do
> not merge the PRs
> - A pull request may be reverted where the author(s) are not responding and
> authors may be asked to re-submit their changes after taking suitable
> remedies.
> - Find automated method to show (at a glance) statuses of PRs with respect
> to:
>   · Number of LGTMs
>   · Smoke tests
>   · Functional tests
>   · Travis tests passing
>   · Mergeability
> - Perform a weekly run of a component-test matrix against the master branch
> before Jan 8th cut off (based on current hypervisors including basic (KVM)
> and advanced networking).
> - Continue to fix broken tests.
> 
> Thoughts, feedback, comments?
> 
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
> [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> [3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
> [4] The current list of blocker and critical bugs currently stands as per
> the following list:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CLOUDSTACK%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20priority%20in%20(Blocker%2C%20Critical)%20AND%20affectedVersion%20in%20(4.10.0.0%2C%204.10.1.0%2C%204.11.0.0%2C%20Future)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> 
> Regards,
> Rohit Yadav
>

Re: [PROPOSE] RM for 4.11

2017-11-29 Thread Gabriel Beims Bräscher

The plan looks great!
Thanks for the hard work Rohit.

Cheers,
Gabriel.

2017-11-29 11:21 GMT-02:00 Wei ZHOU :

> Amazing Rohit !
> You did and will do nice job on the community. Thanks for all your work.
>
> -Wei
>
>
> 2017-11-29 11:14 GMT+01:00 Rohit Yadav :
>
> > Hi All,
> >
> > I’d like to put myself forward as release manager for 4.11. The 4.11
> > releases will be the next major version LTS release since 4.9 and will be
> > supported for 20 months per the LTS manifesto [2] until 1 July 2019.
> >
> > Daan Hoogland and Paul Angus will assist during the process and all of us
> > will be the gatekeepers for reviewing/testing/merging the PRs, others
> will
> > be welcome to support as well.
> >
> > As a community member, I will try to help get PRs reviewed, tested and
> > merged (as would everyone else I hope) but with an RM hat on I would like
> > to see if we can make that role less inherently life-consuming and put
> the
> > onus back on the community to get stuff done.
> >
> > Here the plan:
> > 1. As RM I put forward the freeze date of the 8th of January 2018, hoping
> > for community approval.
> > 2. After the freeze date (8th Jan) until GA release, features will not be
> > allowed and fixes only as long as there are blocker issues outstanding.
> > Fixes for other issues will be individually judged on their merit and
> risk.
> > 3. RM will triage/report critical and blocker bugs for 4.11 [4] and
> > encourage people to get them fixed.
> > 4. RM will create RCs and start voting once blocker bugs are cleared and
> > baseline smoke test results are on par with previous 4.9.3.0/4.10.0.0
> > smoke
> > test results.
> > 5. RM will allocate at least a week for branch stabilization and testing.
> > At the earliest, on 15th January, RM will put 4.11.0.0-rc1 for voting
> from
> > the 4.11 branch, and master will be open to accepting new features.
> > 6. RM will repeat 3-5 as required. Voting/testing of -rc2, -rc3 and so on
> > will be created as required.
> > 7. Once vote passes - RM will continue with the release procedures [1].
> >
> > In conjunction with that, I also propose and put forward the date of 4.12
> > cut-off as 4 months [3] after GA release of 4.11 (so everyone knows when
> > the next one is coming hopefully giving peace of mind to those who have
> > features which would not make the proposed 4.11 cut off).
> >
> > I’d like the community (including myself and colleagues) to:
> > - Up to 8th January, community members try to review, test and merge as
> > many fixes as possible, while super-diligent to not de-stabilize the
> master
> > branch.
> > - Engage with gatekeepers to get your PRs reviewed, tested and merged
> > (currently myself, Daan and Paul, others are welcome to engage as well).
> Do
> > not merge the PRs
> > - A pull request may be reverted where the author(s) are not responding
> and
> > authors may be asked to re-submit their changes after taking suitable
> > remedies.
> > - Find automated method to show (at a glance) statuses of PRs with
> respect
> > to:
> >   · Number of LGTMs
> >   · Smoke tests
> >   · Functional tests
> >   · Travis tests passing
> >   · Mergeability
> > - Perform a weekly run of a component-test matrix against the master
> branch
> > before Jan 8th cut off (based on current hypervisors including basic
> (KVM)
> > and advanced networking).
> > - Continue to fix broken tests.
> >
> > Thoughts, feedback, comments?
> >
> > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/
> > Release+Procedure
> > [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> > [3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
> > [4] The current list of blocker and critical bugs currently stands as per
> > the following list:
> > https://issues.apache.org/jira/issues/?jql=project%20%
> > 3D%20CLOUDSTACK%20AND%20issuetype%20%3D%20Bug%20AND%
> > 20status%20in%20(Open%2C%20%22In%20Progress%22%2C%
> > 20Reopened)%20AND%20priority%20in%20(Blocker%2C%20Critical)
> > %20AND%20affectedVersion%20in%20(4.10.0.0%2C%204.10.1.0%2C%
> > 204.11.0.0%2C%20Future)%20ORDER%20BY%20priority%
> 20DESC%2C%20updated%20DESC
> >
> > Regards,
> > Rohit Yadav
> >
>

Re: [PROPOSE] RM for 4.11

2017-11-29 Thread Wei ZHOU

Amazing Rohit !
You did and will do nice job on the community. Thanks for all your work.

-Wei


2017-11-29 11:14 GMT+01:00 Rohit Yadav :

> Hi All,
>
> I’d like to put myself forward as release manager for 4.11. The 4.11
> releases will be the next major version LTS release since 4.9 and will be
> supported for 20 months per the LTS manifesto [2] until 1 July 2019.
>
> Daan Hoogland and Paul Angus will assist during the process and all of us
> will be the gatekeepers for reviewing/testing/merging the PRs, others will
> be welcome to support as well.
>
> As a community member, I will try to help get PRs reviewed, tested and
> merged (as would everyone else I hope) but with an RM hat on I would like
> to see if we can make that role less inherently life-consuming and put the
> onus back on the community to get stuff done.
>
> Here the plan:
> 1. As RM I put forward the freeze date of the 8th of January 2018, hoping
> for community approval.
> 2. After the freeze date (8th Jan) until GA release, features will not be
> allowed and fixes only as long as there are blocker issues outstanding.
> Fixes for other issues will be individually judged on their merit and risk.
> 3. RM will triage/report critical and blocker bugs for 4.11 [4] and
> encourage people to get them fixed.
> 4. RM will create RCs and start voting once blocker bugs are cleared and
> baseline smoke test results are on par with previous 4.9.3.0/4.10.0.0
> smoke
> test results.
> 5. RM will allocate at least a week for branch stabilization and testing.
> At the earliest, on 15th January, RM will put 4.11.0.0-rc1 for voting from
> the 4.11 branch, and master will be open to accepting new features.
> 6. RM will repeat 3-5 as required. Voting/testing of -rc2, -rc3 and so on
> will be created as required.
> 7. Once vote passes - RM will continue with the release procedures [1].
>
> In conjunction with that, I also propose and put forward the date of 4.12
> cut-off as 4 months [3] after GA release of 4.11 (so everyone knows when
> the next one is coming hopefully giving peace of mind to those who have
> features which would not make the proposed 4.11 cut off).
>
> I’d like the community (including myself and colleagues) to:
> - Up to 8th January, community members try to review, test and merge as
> many fixes as possible, while super-diligent to not de-stabilize the master
> branch.
> - Engage with gatekeepers to get your PRs reviewed, tested and merged
> (currently myself, Daan and Paul, others are welcome to engage as well). Do
> not merge the PRs
> - A pull request may be reverted where the author(s) are not responding and
> authors may be asked to re-submit their changes after taking suitable
> remedies.
> - Find automated method to show (at a glance) statuses of PRs with respect
> to:
>   · Number of LGTMs
>   · Smoke tests
>   · Functional tests
>   · Travis tests passing
>   · Mergeability
> - Perform a weekly run of a component-test matrix against the master branch
> before Jan 8th cut off (based on current hypervisors including basic (KVM)
> and advanced networking).
> - Continue to fix broken tests.
>
> Thoughts, feedback, comments?
>
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/
> Release+Procedure
> [2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> [3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
> [4] The current list of blocker and critical bugs currently stands as per
> the following list:
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20CLOUDSTACK%20AND%20issuetype%20%3D%20Bug%20AND%
> 20status%20in%20(Open%2C%20%22In%20Progress%22%2C%
> 20Reopened)%20AND%20priority%20in%20(Blocker%2C%20Critical)
> %20AND%20affectedVersion%20in%20(4.10.0.0%2C%204.10.1.0%2C%
> 204.11.0.0%2C%20Future)%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> Regards,
> Rohit Yadav
>

Re: [PROPOSE] RM for 4.11

2017-11-29 Thread Will Stevens

You have my support as RM Rohit. Thanks for stepping up.

Everything in this email looks pretty good.

Cheers,

Will

On Nov 29, 2017 5:15 AM, "Rohit Yadav"  wrote:

Hi All,

I’d like to put myself forward as release manager for 4.11. The 4.11
releases will be the next major version LTS release since 4.9 and will be
supported for 20 months per the LTS manifesto [2] until 1 July 2019.

Daan Hoogland and Paul Angus will assist during the process and all of us
will be the gatekeepers for reviewing/testing/merging the PRs, others will
be welcome to support as well.

As a community member, I will try to help get PRs reviewed, tested and
merged (as would everyone else I hope) but with an RM hat on I would like
to see if we can make that role less inherently life-consuming and put the
onus back on the community to get stuff done.

Here the plan:
1. As RM I put forward the freeze date of the 8th of January 2018, hoping
for community approval.
2. After the freeze date (8th Jan) until GA release, features will not be
allowed and fixes only as long as there are blocker issues outstanding.
Fixes for other issues will be individually judged on their merit and risk.
3. RM will triage/report critical and blocker bugs for 4.11 [4] and
encourage people to get them fixed.
4. RM will create RCs and start voting once blocker bugs are cleared and
baseline smoke test results are on par with previous 4.9.3.0/4.10.0.0 smoke
test results.
5. RM will allocate at least a week for branch stabilization and testing.
At the earliest, on 15th January, RM will put 4.11.0.0-rc1 for voting from
the 4.11 branch, and master will be open to accepting new features.
6. RM will repeat 3-5 as required. Voting/testing of -rc2, -rc3 and so on
will be created as required.
7. Once vote passes - RM will continue with the release procedures [1].

In conjunction with that, I also propose and put forward the date of 4.12
cut-off as 4 months [3] after GA release of 4.11 (so everyone knows when
the next one is coming hopefully giving peace of mind to those who have
features which would not make the proposed 4.11 cut off).

I’d like the community (including myself and colleagues) to:
- Up to 8th January, community members try to review, test and merge as
many fixes as possible, while super-diligent to not de-stabilize the master
branch.
- Engage with gatekeepers to get your PRs reviewed, tested and merged
(currently myself, Daan and Paul, others are welcome to engage as well). Do
not merge the PRs
- A pull request may be reverted where the author(s) are not responding and
authors may be asked to re-submit their changes after taking suitable
remedies.
- Find automated method to show (at a glance) statuses of PRs with respect
to:
  · Number of LGTMs
  · Smoke tests
  · Functional tests
  · Travis tests passing
  · Mergeability
- Perform a weekly run of a component-test matrix against the master branch
before Jan 8th cut off (based on current hypervisors including basic (KVM)
and advanced networking).
- Continue to fix broken tests.

Thoughts, feedback, comments?

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
[2] https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
[3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases
[4] The current list of blocker and critical bugs currently stands as per
the following list:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CLOUDSTACK%20AND%
20issuetype%20%3D%20Bug%20AND%20status%20in%20(Open%2C%20%
22In%20Progress%22%2C%20Reopened)%20AND%20priority%
20in%20(Blocker%2C%20Critical)%20AND%20affectedVersion%20in%
20(4.10.0.0%2C%204.10.1.0%2C%204.11.0.0%2C%20Future)%
20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

Regards,
Rohit Yadav

Re: [PROPOSE] RM for 4.11

Re: [PROPOSE] RM for 4.11

Re: [PROPOSE] RM for 4.11

Re: [PROPOSE] RM for 4.11

RE: [PROPOSE] RM for 4.11

Re: [PROPOSE] RM for 4.11

Re: [PROPOSE] RM for 4.11

Re: [PROPOSE] RM for 4.11

Re: [PROPOSE] RM for 4.11

Re: [PROPOSE] RM for 4.11

Re: [PROPOSE] RM for 4.11

Re: [PROPOSE] RM for 4.11

Re: [PROPOSE] RM for 4.11

13 matches

Site Navigation

Mail list logo

Footer information