> On Apr 29, 2015, at 9:49 PM, Marcus <shadow...@gmail.com> wrote: > > 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.
Yes +1. -Set a date -Tag master for reference -Find a volunteer or two to RM master -automatic revert on master if not from RM -all commits to master come from PR, need clear review and green tests -harden master (basic QA process), release 4.6 as a tag on master -all features and fixes need to be made on branches or forks and onus is on devs to rebase to master -brings everyone onto 4.6 (make sure we have upgrade paths from 4.3, 4.4, etc) -from there forward only maintain a linear release through master Feel free to add, tweak PS: No need to vote if we have consensus. Taking a clue from ASF members, votes should be avoided at all cost, they mean that we do not have clear consensus. > > 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 >>>>> >>
