cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: CloudStack 4.2 Quality Question
Date Tue, 20 Aug 2013 17:10:43 GMT
On Tue, Aug 20, 2013 at 12:58 PM, Alex Huang <> wrote:
>> On the rapid influx of fixes, I don't think that we should tell people to 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 we
>> should branch 4.2 temporarily (perhaps call it 4.2-forward) stabilize the 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 means
>> 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 branch 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 not be easy.
 I wouldn't recommend for fixes to sit on master and wait for cherry-pick to 4.2.


View raw message