cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From S. Brüseke - proIO GmbH <s.brues...@proio.com>
Subject AW: [DISCUSS] 4.6 release management
Date Mon, 20 Apr 2015 14:12:01 GMT
Hi all,

it is really hard for a newbie to follow all of your thought regarding this. Can somebody
please explain it a little bit more?
Thank you very much!

Mit freundlichen Grüßen / With kind regards,

Swen Brüseke

-----Ursprüngliche Nachricht-----
Von: Simon Weller [mailto:sweller@ena.com] 
Gesendet: Montag, 20. April 2015 15:24
An: dev@cloudstack.apache.org
Betreff: Re: [DISCUSS] 4.6 release management

>________________________________________
>From: Sebastien Goasguen <runseb@gmail.com>
>Sent: Saturday, April 18, 2015 2:50 AM
>To: dev@cloudstack.apache.org
>Subject: Re: [DISCUSS] 4.6 release management

> 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.

+1 on this.

Ultimately this will be painful to start with, but it will pay dividends in the future with
a much more stable (and tested) master, and hence future releases will be of higher quality.

With stable (and frequent iterative) releases, there will be much less pressure to back port
fixes/features, because the community will see taking a new release as low risk.

- Si

>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
>>>



- proIO GmbH -
Geschäftsführer: Swen Brüseke
Sitz der Gesellschaft: Frankfurt am Main

USt-IdNr. DE 267 075 918
Registergericht: Frankfurt am Main - HRB 86239

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, 
informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. 
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. 

This e-mail may contain confidential and/or privileged information. 
If you are not the intended recipient (or have received this e-mail in error) please notify

the sender immediately and destroy this e-mail.  
Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly
forbidden. 



Mime
View raw message