Hi Daan, So yeah.....it's complicated right now.
Essentially we discussed using master as the release branch[1]. Everyone (involved in that thread) seemed to agree that master was the right place to keep the release branch, until much later in the release cycle. This was echoed in several other threads. However, there is a disconnect. So over the weekend, I went through and began working on a list of commits I intended to revert from master. Some of these were new features or major redesigns that landed well after code freeze. Many of them are just commits that aren't focused on the Major, Critical, or Blocker bugs for the 4.5.0 release. But as the volume of those (both in count and origin) seemed to rise, I started thinking that perhaps that strategy doesn't line up with the will of the community, and I'd be usurping a lot of authority doing so in the process. I also don't see the heavy focus on 4.5.0 - and perhaps some of this is my fault, perhaps I need to start drawing attention to the release more regularly. I find it interesting that we have 6 blockers currently, 2 of which are new this week. 1/2 of those aren't assigned yet. I'll start harping on that soon. So - to answer your question - ideally, because we are in feature freeze and currently treating master as our release branch, you'd keep new features/functionality in a feature branch, until we branch 4.5. I don't know, given the reality that we are facing, if that answer will remain the same. --David [1] http://markmail.org/message/vz4lnpzabhhdjhby On Thu, Oct 2, 2014 at 6:31 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > H David, > > What are your plans in terms of branch and merging and releasing master for > new features? At Schuberg Philis we are looking forward to integrate our > re-factor work on the (Vpc)VirtualNetworkApplianceManagerImpl into the code > base. Phase two of the work has started, where we add redundancy to the vpc > version of the appliance. My inquiry is as we have to deal with conflicts > with other work on a regular basis. > > for those interested, we have a branch to review: [1] > > We want to stop rebasing and commits on (frozen) master are breaking the > smoke tests. > > [1] > https://github.com/schubergphilis/Cloudstack/tree/vpc-refactor-clean-for-PR > -- > Daan