cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <>
Subject Re: [DISCUSS] 4.6 release management
Date Thu, 23 Apr 2015 22:21:04 GMT
Before I rough draft anything, I just wanted to ask if we had voted on
moving to git-workflow, and dropping the multiple release branch
design. This seems like a significant change, and while good in many
ways, it also seems that many users are seeking for point releases to
their pet version and I'm not sure how they'll take to a response that
they need to upgrade. Overall I think it will approve stability and
focus our efforts, but have we had a vote around this change?

On Sat, Apr 18, 2015 at 12:50 AM, Sebastien Goasguen <> wrote:
>> On Apr 18, 2015, at 8:36 AM, Marcus <> 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 <> 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" <>:
>>>> 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 <>
>>>> wrote:
>>>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen <>
>>>> wrote:
>>>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion <>
>>>> 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
>>>>>>>  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.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
>>>> 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
>>>>>>> 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
>>>> 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

View raw message