cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <shadow...@gmail.com>
Subject Re: [DISCUSS] 4.6 release management
Date Sat, 18 Apr 2015 06:36:31 GMT
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.

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