cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samir Agarwal <>
Subject RE: 4.9 Release Management
Date Wed, 02 Mar 2016 19:43:22 GMT
Kudos Will!

I had received many private notes wondering if Accelerite will continue to play a strong role
in contributions to the community; here is your proof!

We wanted to take on the biggest pain points in the community, and see how we can make positive
contributions. Koushik Das will work alongside Will and Patrick to address both of these problem
areas. I believe that this will put the community on a path to more manageable releases going




-----Original Message-----
From: Will Stevens [] 
Sent: Wednesday, March 02, 2016 9:15 AM
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.



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.
View raw message