Re: [PROPOSE] RM for 4.11

[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: Issue with Opensaml and Self-Signed Certificates

[Harika Punna]

Rohit,

I have tried the same thing on latest master, even on that I could the same 
dependencies.

Are you using opensaml of version 2.6.4? Have you faced this issue when working 
with self-signed certificates.

I would appreciate any help on this.



Thanks,
Harika.

From: Rohit Yadav 
Date: Wednesday, 29 November 2017 at 1:09 PM
To: "dev@cloudstack.apache.org" , Harika Punna 

Subject: Re: Issue with Opensaml and Self-Signed Certificates

Harika, Can you test the latest master and see if you can reproduce the error?
Get Outlook for Android


rohit.ya...@shapeblue.com
www.shapeblue.com
@shapeblue





From: Harika Punna 
Sent: Wednesday, November 29, 2017 10:57:53 AM
To: Rohit Yadav; dev@cloudstack.apache.org
Subject: Re: Issue with Opensaml and Self-Signed Certificates

Rohit,

I was trying to configure ACS with ADFS using saml plugin.

I find the not-yet-commons-ssl.jar in the opensaml-2.6.4 dependency of 
plugins/user-authentication/saml2/pom.xml

The dependency tree of not-yet-commons-ssl is as follows-
opensaml-2.6.4 > openws-1.5.4 > xmltooling-1.4.4 > not-yet-commons-ssl-0.3.9

May I know which version of opensaml are you using?


Thanks,
Harika.


From: Rohit Yadav 
Date: Tuesday, 28 November 2017 at 6:56 PM
To: Harika Punna , "dev@cloudstack.apache.org" 

Subject: Re: Issue with Opensaml and Self-Signed Certificates


Harika,



Can you share what exactly are you doing, perhaps you can submit a PR and ask 
for review?

I did not find any usage of a KeyStoreBuilder class in current master, nor 
we've a not-yet-commons-ssl dependency in current codebase.



Regard.

rohit.ya...@shapeblue.com
www.shapeblue.com
@shapeblue





From: Harika Punna 
Sent: Tuesday, November 28, 2017 2:13:33 PM
To: dev@cloudstack.apache.org; Rohit Yadav
Subject: Re: Issue with Opensaml and Self-Signed Certificates

Hi Rohit,

Could you please help me on this?

-Harika.



On 27/11/17, 4:26 PM, "Harika Punna"  wrote:

Hi,


When I use Opensaml on 4.10 with the self-signed certificates I get the 
following error, though the configuration for the opensaml and ssl is proper. 
It works fine if I debug and supply the password of the keystore in 
KeyStoreBuilder class, which is in not-yet-commons-ssl.jar.


Has anyone faced this issue, I tried with different versions of opensaml 
but nothing worked. Found similar issue on SO at [1], but none of them helped.



java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.

at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)

at sun.security.util.DerValue.init(DerValue.java:365)

at sun.security.util.DerValue.(DerValue.java:320)

at sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:1914)

at java.security.KeyStore.load(KeyStore.java:1445)

at org.apache.commons.ssl.KeyStoreBuilder.tryJKS(KeyStoreBuilder.java:450)

at org.apache.commons.ssl.KeyStoreBuilder.parse(KeyStoreBuilder.java:416)

at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:207)

at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:160)

at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:165)

at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:170)

at org.apache.commons.ssl.TrustMaterial.(TrustMaterial.java:83)

at 
org.opensaml.xml.security.x509.X509Util.decodeCertificate(X509Util.java:359)

at 
org.opensaml.xml.security.keyinfo.KeyInfoHelper.getCertificate(KeyInfoHelper.java:201)

at 
org.opensaml.xml.security.keyinfo.KeyInfoHelper.getCertificates(KeyInfoHelper.java:176)

at 
org.opensaml.xml.security.keyinfo.KeyInfoHelper.getCertificates(KeyInfoHelper.java:150)

at 
org.apache.cloudstack.saml.SAML2AuthManagerImpl.addIdpToMap(SAML2AuthManagerImpl.java:293)

at 
org.apache.cloudstack.saml.SAML2AuthManagerImpl.discoverAndAddIdp(SAML2AuthManagerImpl.java:323)

at 
org.apache.cloudstack.saml.SAML2AuthManagerImpl.access$200(SAML2AuthManagerImpl.java:92)

at 
org.apache.cloudstack.saml.SAML2AuthManagerImpl$MetadataRefreshTask.run(SAML2AuthManagerImpl.java:349)

at java.util.TimerThread.mainLoop(Timer.java:555)

at java.util.TimerThread.run(Timer.java:505)

java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big.

at sun.security.util.DerInputStream.getLength(DerInputStream.java:561)

at sun.security.util.DerValue.init(DerValue.java:365)

at sun.security.util.DerValue.(DerValue.java:320)

at sun.security.pkcs12.PKCS12KeyStore.engineLoad(PKCS12KeyStore.java:1914)

at java.security.KeyStore.load(KeyStore.java:1445)

at 

Re: [PROPOSE] RM for 4.11

[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

[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

[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

[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

[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

[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

[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

[PROPOSE] RM for 4.11

[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