Thanks Will for initiating the discussion on 4.9 release management. As already mentioned, I along with Patrick will be helping out Will with the release process.
Having a reliable CI system is very important going forward. There are discussions already happening in the list related to it. I agree that CI should be the top priority for 4.9 release. The initial idea is to run the CI manually against each PR and publish the results in github itself. The details of the CI environment, test scenarios and configurations will be published as well. Simulator based tests are already running as part of Travis, if required some more tests scenarios can be added there. In the longer run, if more contributors/organizations come up with their own CI environment and help test PRs then it will be even better. -Koushik ________________________________________ From: Will Stevens <williamstev...@gmail.com> Sent: Wednesday, March 2, 2016 10:44 PM To: dev@cloudstack.apache.org Subject: 4.9 Release Management Hello Everyone, I have mentioned this in other related threads, but I wanted to make an official thread on the topic. I am nominating myself as the release manager for 4.9. Please feel free to discuss if you have comments or concerns. I will not be working alone, I will be assisted by Koushik Das and Patrick Dube. I will be running point, but all three of us will be working together as a unit for this release. Our main focus for this release is the integration of hardware Continuous Integration (CI) into the PR flow. Koushik and his team will be setting up a CI environment which will be used for testing PRs and I will also be setting up a CI environment for testing PRs. The details of the CI integration will be handled publicly, but we will likely have to work with a minimum viable implementation initially and move forward from there. Here are some of the key aspects of the CI which are top of mind for me. - Standardize a feedback mechanism to post the result of CI runs back to the relevant PR. I believe the best way to do this would be to post a summary of the CI run in the PR thread on Github. With the existing integration, this will then get pushed to the mailing list (since all comments on a PR are pushed to the mailing list). - Ideally, we will also make the CI logs available for the run. We are still working out the details of how we do this, but we will likely be pushing the logs to an object store with a cleanup window to remove the logs after a set period of time (probably a week). This should give people the opportunity to pull the logs if they are interested in the test results, but will reduce the need for ever growing storage. - In order to parallelize the CI operations, we will not be automatically kicking off a CI run for every PR for now. Instead, we will communicate between us and each run distinct PRs so we can maximize the utilization of our hardware. Some longer term goals of the CI in my mind are as follows: - I would like the core CI framework to be easily distributed and accessible to anyone who has hardware available. This would enable anyone to setup a CI on their hardware and it would automatically be hooked up to feedback the results to the Github PRs. I feel this is very important long term because every individual or organization depends on a different configuration and hardware setup, so it empowers them to validate their own use case while adding value back to the community. Additional details will follow, namely the release schedule etc. Please contribute your ideas and feedback. Cheers, Will 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.
