cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <run...@gmail.com>
Subject Re: [DISCUSS] 4.6 release management
Date Sat, 18 Apr 2015 07:50:45 GMT

> On Apr 18, 2015, at 8:36 AM, Marcus <shadowsor@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.hoogland@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" <shadowsor@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.hoogland@gmail.com>
>>> wrote:
>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <runseb@gmail.com>
>>> wrote:
>>>>> 
>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <pdion@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
>>> 


Mime
View raw message