cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: 4.5.0 - status - looming dates
Date Fri, 19 Sep 2014 03:29:58 GMT
On Thu, Sep 18, 2014 at 6:19 AM, Sebastien Goasguen <> wrote:
> On Sep 18, 2014, at 5:08 AM, Daan Hoogland <> wrote:
>> David,
>> What do you plan to do after branching in terms of merge-back and or
>> cherry-picking. We are discussing here (Schuberg-Philis + Rohit + Ian +
>> Wido (+ Sebastien)) that we would like to branch after getting master
>> stable and then when the real release work is underway branching of 4.5.
>> All new feature development in the meanwhile would have to go in its
>> respective branches until master is released again.
>> thoughts, my dear RM?
> Yes, about we consider master the release branch and don't create a 4.5 branch.
> We declare feature freeze and we only take in bug fixes that need to come in through
bugfix/hotfix branches that you merge.

I think considering master the release branch will work for 4.5.0 - I
am not sure if it would have worked with previous releases or not.
It's not the effect on master that worries me; I think the effect will
actually be good. It's that the perpetuation of silos of code and
keeping those silos mergeable can become a lot of work. In short; long
term we need a dev branch somewhere.Our QA cycles are so long right
now that we'll end up with one of two conditions - n feature branches
that won't merge cleanly, and need n developers to spend copious
amounts of time on keeping their silos updated OR feature developers
will learn that it does little good to develop early, so they'll wait
till the last possible moment to push a feature.  The problem is worse
for non-committers - getting their feature committed to a feature
branch and then being unable to maintain it.

> Folks developing features can do so on their own branch (that they can rebase on master
right now), and they pull in the same bugfix/hotfix.
> This has the benefit of stabilizing master and getting it into a releasable state. Then
when 4.5 is released, the features can be merged back and we can create a clean 4.6.
> Currently master is never releasable, and the effort going into our release branches
don't all make it back to master. Hence all our releases are based on unstable work. As a
community we don't currently have what it takes to run a QA effort to stabilize a release
> We can switch that around, make our releases based on an already stable (released) branch
and develop future features based on that released product.
> To re-iterate:
> *To make that switch we can delay 4.5, stabilize master (as if it where 4.5) with clean
merging of bug fixes branches. Devs can bring in those same changes on their own branch to
stay in sync with the stabilization process.
> *Once master is stable, we pretty much have our 4.5 but all other branches should have
benefited from it.
> *We can then start creating 4.6 by merging the features that are ready
> *We then adopt a gitflow'esque model for patching master/4.5 and trickling all that down
to all branches.
> *When 4.6 is ready we merge back into master….
> *We get closer to a linear development model with the same confidence in each release.

So this requires some non-trivial investment by folks into keeping
feature branches up to date. The divergence possible in 1-3 months of
our QA cycle is not trivial just from bug fixes is not trivial. That
said; I think that this is a step in the right direction; but I think
long term it will need to be coupled with lots of automation and
testing, and strict behavior around enforcing quality. This likely
means that we'll need a small army of quality fascists who take a
serious interest in quality, and are liberal with vetoes and reverts
until we get something that automates gating on quality.


> -sebastien
>> On Thu, Sep 18, 2014 at 4:32 AM, David Nalley <> wrote:
>>> Hi folks,
>>> 4.3.1 is out the door now, so I am trying to get things lined up around
>>> 4.5.0.
>>> Please consider us in feature freeze right now - and my plan is to
>>> branch 4.5.0  this coming weekend. I'd like to see us hit code freeze
>>> by end of October. Right now, we have 4 blocker bugs and 63 critical
>>> bugs for the 4.5.0 release, so we have plenty to fix.
>>> If any of these elements cause you concern, please say so.
>>> --David
>> --
>> Daan

View raw message