cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: [DISCUSS] 4.6 release management
Date Fri, 17 Apr 2015 15:44:04 GMT
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