cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Animesh Chaturvedi <animesh.chaturv...@citrix.com>
Subject RE: CloudStack 4.2 Quality Question
Date Tue, 20 Aug 2013 17:52:29 GMT


> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Tuesday, August 20, 2013 10:11 AM
> To: dev@cloudstack.apache.org
> Subject: Re: CloudStack 4.2 Quality Question
> 
> 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 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.

[Animesh>] Yes my preference would also be to keep this staging or 4.2-forward branch where
we can continue our bug fixes. Newer Issues can be tagged for fixVersion 4.2.1. I will continually
triage and pull over the ones we need for 4.2.



> 
> > 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.
> >
> 
> Agreed.

Mime
View raw message