cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <run...@gmail.com>
Subject Re: 4.5.0 - status - looming dates
Date Thu, 18 Sep 2014 10:19:24 GMT

On Sep 18, 2014, at 5:08 AM, Daan Hoogland <daan.hoogland@gmail.com> 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.

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

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.

-sebastien

> 
> On Thu, Sep 18, 2014 at 4:32 AM, David Nalley <david@gnsa.us> 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


Mime
View raw message