Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of kelven.yang@citrix.com
 designates 66.165.176.63 as permitted sender)
From: Kelven Yang <kelven.yang@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Tue, 29 Jan 2013 10:25:36 -0800
Subject: Re: [ACS41] Where to merge features?
Thread-Topic: [ACS41] Where to merge features?
Thread-Index: Ac3+TgpDIFSHmTnmQn2T7to2VQwKTA==
Message-ID: <CD2D53CA.2CBD2%kelven.yang@citrix.com>
In-Reply-To: 
 <CA+96GG4GQe+A-nW9gpJvTfKxVt6V8yErVZ3Sa00J3qrbwupQJA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.2.3.120616
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 1/29/13 9:13 AM, "Chip Childers" <chip.childers@sungard.com> wrote:

>Hi all,
>
>As discussed in the Javelin MERGE proposal thread, one of my biggest
>concerns was around when and how features will merge into the repo for
>4.1.0.  We have a number of features in development, going through IP
>clearance and sitting as pending reviewboard submissions that are all
>based on master.  That number seems to be much higher than the number
>of features that are based on javelin, so it's only fair to let the
>features get into master before javelin's changes hit.
>
>Here's the proposed plan that Alex and I discussed.  If you disagree,
>now's the time to say so.
>
>* For features that are based off of master, your merge (or
>reviewboard request) should be against master.
>
>* For features that are based off of javelin, your merge (or
>reviewboard request) should be against the javelin branch.
>
>* The last day for merging new features and improvements into either
>master or javelin would be 1/31 (Thursday).
>
>* On Friday, Alex (and others) will rebase javelin against master,
>test the resulting merge, make any required modifications, and then
>finally merge javelin into master.
>
>* Once that javelin to master merge is complete, I'll cut the release
>branch (4.1).
>
>This adjusts our schedule a little bit, and also assumes that the work
>to re-base javelin against master (yet again) will go smoothly and
>quickly.  If the Javelin branch isn't able to get to a stable state
>quickly, we will need to consider not merging it in for 4.1.0.
>
>Again, shout if you have any concerns with this plan.


+1. This sounds like a fair plan.


>
>-chip