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:swel...@ena.com] Gesendet: Montag, 20. April 2015 15:24 An: dev@cloudstack.apache.org Betreff: Re: [DISCUSS] 4.6 release management >________________________________________ >From: Sebastien Goasguen <run...@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 <shadow...@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.hoogl...@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" <shadow...@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.hoogl...@gmail.com> >>> wrote: >>>> On Fri, Apr 17, 2015 at 2:43 AM, Sebastien Goasguen >>>> <run...@gmail.com> >>> wrote: >>>>> >>>>>> On Apr 17, 2015, at 12:49 AM, Pierre-Luc Dion >>>>>> <pd...@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.
