Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: error (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <20CF38CB4385CE4D9D1558D52A0FC0580C187B@SJCPEX01CL03.citrite.net>
References: 
 <CACOnxCiwi1V31t=j5SjCuuzFxhx8LiudAVKxv+XJ6B=25CpTQQ@mail.gmail.com>
 <CE37D88D.26984%chiradeep.vittal@citrix.com>
 <C3637609BC1C0D40A2AC70F4760C7A2D0D0EE5@SJCPEX01CL02.citrite.net>
 <CACOnxCjOHfr1_hnNg2=q5o=QcK3tJaGn_xakizQwRKkpriv9Eg@mail.gmail.com>
 <CACOnxCh-4F_SB-0rAn0wuhmcV03+gp2NgWKks9rpjoYm5tLMRA@mail.gmail.com>
 <C3637609BC1C0D40A2AC70F4760C7A2D0D1EB3@SJCPEX01CL02.citrite.net>
 <CACOnxCgW0XHUGXePhU7x6jrrDQM23XaLZg2MLq-2Fdd7m6ay7Q@mail.gmail.com>
 <CAKprHVa8q=z4AzAbwNdvQ1DQotVyig6+hVUPxwjRhHuASQTviw@mail.gmail.com>
 <20CF38CB4385CE4D9D1558D52A0FC0580C187B@SJCPEX01CL03.citrite.net>
From: David Nalley <david@gnsa.us>
Date: Tue, 20 Aug 2013 13:10:43 -0400
Message-ID: 
 <CAKprHVYv1s7oXS-vMKyhaqWsgjVV3Eq9RzczjrSQsv0XYMcMzg@mail.gmail.com>
Subject: Re: CloudStack 4.2 Quality Question
To: dev@cloudstack.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 20, 2013 at 12:58 PM, Alex Huang <Alex.Huang@citrix.com> wrote:
>> On the rapid influx of fixes, I don't think that we should tell people t=
o stop
>> pushing fixes into 4.2, but we also want to minimize churn.
>> Animesh and I were discussing this in person yesterday and I wonder if w=
e
>> should branch 4.2 temporarily (perhaps call it 4.2-forward) stabilize th=
e 4.2
>> branch,  let folks push their non-blocker bugfixes into 4.2-forward and =
merge
>> 4.2-forward back into 4.2 after release.
>> The alternative is telling people to push fixes into master - which mean=
s
>> someone has to go back and cherry-pick, and know what needs to be cherry=
-
>> picked, and deal with inevitable conflict.
>>
>
> I've been pushing this with Animesh as well.  This is basically a staging=
 branch for 4.2.  Commits don't get cherry-pick over until the staging bran=
ch passed BVT.  At this stage, I'm not sure it has much value unless we see=
 that 4.2 release will stretch out much further.
>

Perhaps we should rethink how we lock down the release branch after
'code freeze' and do something more along this line. We wouldn't
necessarily slow down velocity, but it would still allow the RM to
cherry-pick fixes in.
I don't think we realistically know how long it will take. 3 days? 3
weeks? That said, we have people working on fixing bugs, things that
we'd probably like to see in 4.2.1 that need a place to live.

> Due to my changes on master, cherry-picking between master and 4.2 will n=
ot be easy.  I wouldn't recommend for fixes to sit on master and wait for c=
herry-pick to 4.2.
>

Agreed.