On Apr 20, 2015, at 4:12 PM, S. Brüseke - proIO GmbH <s.brues...@proio.com> wrote:
> 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! > Hi Swen, I will try. Currently we develop cloudstack in the master branch, and create a 'release' branch for major releases. Hence we have a 4.3 branch, a 4.4 branch etc…. We are currently on 4.5 , which means that what is master now will become our 4.5 release. The issue comes when stabilizing a release branch. A traditional approach would hand off the release branch to a QA team and let the QA team harden that branch over several months. This tends to make each release a somewhat different product of each other. It also creates a maintenance headache, as we have to abandon branches. We do not want anyone to feel abandoned on some dead branches, thus we maintain upgrade paths that can become complex, with fixes and features that can't be merged in various branches and regressions. Bottom line: headache, heartache, nightmares, no fun. This is not something specific to cloudstack and other projects face similar issues. I am of the opinion that for our community this is not a workable model, as we do not have a dedicated QA team. Even though some of us are paid to work on CloudStack. So we are talking about finding a better release management model, that would allow us to release faster and more stable software (not to say that it is unstable right now, just that things can be improved). One model among many, would be to treat master as our release branch and merge features/fixes into master once we know they are valid and do not break anything. This would increase our trust in master as production software and put us on a path of continuous deployment with an iterative/rolling upgrade mindset. Since all committers have write access to master, treating master as a release branch (for example), involves all of us reaching consensus and agreeing that a release manager will be the only one allowed to touch that branch (for instance). This also involves being able to release much faster (which we have to do official through manual votes for legal purposes), reducing scope of each release etc…. I hope that clarifies things a bit, -Sebastien > 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. > >
