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, 24 Apr 2015 09:05:44 GMT
Marcus, I think we decided to take small steps in the direction of
something resambling git-workflow instead of adopting it as a
standard. merging branches for fixes and features was one of those
steps. We had a pre-vote discussion on git-flow and it was rejected as
such. That shouldn't stop us from implementing parts of it that aren't
objected against.

On Fri, Apr 24, 2015 at 12:21 AM, Marcus <shadowsor@gmail.com> wrote:
> 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 <runseb@gmail.com> wrote:
>>
>>> 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
>>>>>
>>



-- 
Daan

Mime
View raw message