cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebgoa <>
Subject Re: [DISCUSS] 4.6 release management
Date Fri, 01 May 2015 07:35:35 GMT

On May 1, 2015, at 12:52 AM, Pierre-Luc Dion <> wrote:

> Hi,
> In my mind it was kind of making more sense to start by keeping 4.6 into a
> separate branch, enforce pull-requests and deploy the CI. smaller step but
> faster result, and from there, once we get stable with the CI

I hear you.

But we have waited for way too long for better CI. I see great efforts in that direction.
But I personally do not want to wait any longer to make a move.

We do open source, we should have fun, take risks, move fast, fail fast, recover etc….

so let's JFDI

> and git flow;
> move into master, do fastest releases cycle. If we consider we can do all
> that starting in 4.6, I'm all for it!

Is there really a difference between creating a 4.6 and doing what you say, and tagging master
(start) and doing it on master leading to 4.6 release ?

Assuming the QA does not improve, 4.6 would not be worse than 4.5. If we can improve a bit
on the QA then we win.
Plus I think a different commit model will help a lot in quality.

> Marcus: are you preparing a proposal on this? wiki page? I can help

We can do this proposal on email..and once we have consensus write it up for archive in the
If we move to the wiki now, this effort is going to die.

> Seb: doesn't the vote would confirm the consensus?

if we have consensus no need for vote.

> Raja:  do we have any documentation somewhere on how to use, contribute to
> the smoke test? that could be our start for the CI tests?
> Cheers
> On Thu, Apr 30, 2015 at 3:58 AM, Sebastien Goasguen <>
> wrote:
>>> On Apr 29, 2015, at 9:49 PM, Marcus <> wrote:
>>> After reviewing the history as mentioned by Daan, unless we propose
>>> and vote on a newer workflow model I think the best we can do is to
>>> simply be more strict about commits to master. They all need to be
>>> merges that have been tested against master before merge. This will in
>>> theory make master more stable, but doesn't really change the workflow
>>> we've already agreed upon and have been working under (although
>>> bugfixes sometimes were not coming in from branches, and cherry-picked
>>> bugfixes from branches will need to go into a branch first, tested
>>> against master, and merged to master). We can essentially set a date
>>> and do that any time, with some advance notice that direct commits
>>> will be reverted.
>> Yes +1.
>> -Set a date
>> -Tag master for reference
>> -Find a volunteer or two to RM master
>> -automatic revert on master if not from RM
>> -all commits to master come from PR, need clear review and green tests
>> -harden master (basic QA process), release 4.6 as a tag on master
>> -all features and fixes need to be made on branches or forks and onus is
>> on devs to rebase to master
>> -brings everyone onto 4.6 (make sure we have upgrade paths from 4.3, 4.4,
>> etc)
>> -from there forward only maintain a linear release through master
>> Feel free to add, tweak
>> PS: No need to vote if we have consensus. Taking a clue from ASF members,
>> votes should be avoided at all cost, they mean that we do not have clear
>> consensus.
>>> 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?
>>>>>>> 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
>> 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
>>>>>>>>>> - 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.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
>>>>>>>> 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
>>>>>>>> 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