After reviewing the history as mentioned by Daan, unless we propose and vote on a newer workflow model I think the best we can do is to simply be more strict about commits to master. They all need to be merges that have been tested against master before merge. This will in theory make master more stable, but doesn't really change the workflow we've already agreed upon and have been working under (although bugfixes sometimes were not coming in from branches, and cherry-picked bugfixes from branches will need to go into a branch first, tested against master, and merged to master). We can essentially set a date and do that any time, with some advance notice that direct commits will be reverted.
On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <run...@gmail.com> wrote: > >> 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 >>>> >
