> On Apr 18, 2015, at 8:36 AM, Marcus <shadow...@gmail.com> wrote: > > Have they diverged that much? Due to cherry-picking, I guess. > Otherwise you should be able to do it cleanly. > > There's a good opportunity to do this next release. Instead of > creating a release branch, we freeze master and start creating dev > branches.
+1 This just amounts to treating master now like a release branch. Getting back to PL suggestion, that means that any commit to master would be through a PR or MERGE request on the ML. Anything else will be reverted by the RM. Marcus, do you feel like writing down a little process for this and some dates that we can target. It would be nice to do this for 4.6. > > On Fri, Apr 17, 2015 at 10:46 PM, Daan Hoogland <daan.hoogl...@gmail.com> > wrote: >> We heavily invested in code now on master. Not looking forward to >> backporting that. >> >> mobile dev with bilingual spelling checker used (read at your own risk) >> Op 17 apr. 2015 21:02 schreef "Marcus" <shadow...@gmail.com>: >> >>> Well, would we just swap the last release branch with master? Master >>> is the dev branch, and the last release is really what we have as a >>> stable branch. >>> >>> On Fri, Apr 17, 2015 at 8:44 AM, Daan Hoogland <daan.hoogl...@gmail.com> >>> wrote: >>>> 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 >>>
