On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <run...@gmail.com> wrote: > >> 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… I agree and we can even go as far as reverting fixes that are cherry-picked in favour of merged forward.
> > IMHO, I think this would be a good step but I don’t think it goes far enough. Agreed here as well but let's take the step while discussing further steps and not implement to much process as well > > 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. The problem here is that there is no stable point to fork from at the moment. We will get there and we shouldn't stop taking steps in that direction. > > 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 :-) > -- Daan
