> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <pd...@cloudops.com> wrote: > > Today during the CloudStackdays we did a round table about Release > management targeting the next 4.6 releases. > > > Quick bullet point discussions: > > ideas to change release planning > > - Plugin contribution is complicated because often a new plugin involve > change on the core: > - ex: storage plugin involve changes on Hypervisor code > - There is an idea of going on a 2 weeks release model which could > introduce issue the database schema. > - Database schema version should be different then the application > version. > - There is a will to enforce git workflow in 4.6 and trigger simulator > job on PullRequest. > - Some people (I'm part of them) are concerned on our current way of > supporting and back porting fixes to multiple release (4.3.x, 4.4.x, > 4.5.x). But the current level of confidence against latest release is low, > so that need to be improved. > > > So, the main messages is that w'd like to improve the release velocity, and > release branch stability. so we would like to propose few change in the > way we would add code to the 4.6 branch as follow: > > - All new contribution to 4.6 would be thru Pull Request or merge request, > which would trigger a simulator job, ideally only if that pass the PR would > be accepted and automatically merged. At this time, I think we pretty much > have everything in place to do that. At a first step we would use > simulator+marvin jobs then improve tests coverage from there.
+1 We do need to realize what this means and be all fine with it. It means that if someone who is not RM directly commits to the release branch, the commit will be reverted. And that from the beginning of the branching… IMHO, I think this would be a good step but I don’t think it goes far enough. This still uses a paradigm where a release is made from a release branch that was started from an unstable development branch. Hence you still need *extensive* QA. If we truly want to release faster, we need to release from the same QA’d branch time after time….a release needs to be based on a previous release Basically, we need a rolling release cycle. That will have the added benefit to not leave releases behind and have to focus on backporting. > > Please comments :-)
