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

Best

Samir

        


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

Reply via email to