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

Reply via email to