Yeah, I totally agree that if fixes need to be made in 4.2, then we should be putting fixes into 4.2. My only concern was the lack of time between the branch "settling down" and it going into the field.
As long as we have a sufficient amount of time for me to perform some manual regression testing on the RC build, I'm OK with that. :) I just got a bit nervous last week when I pulled from upstream and noticed my feature was broken by two completely distinct checkins. :( I don't have any way to put decent regression tests in place in the codebase because of the need for a SolidFire SAN. If we're expecting a 4.2.1, then a 4.2-forward branch seems like a good idea (although, at this point, it might be too late for it). Going forward, though, it's probably a good idea because, as you say, otherwise we're having to cherry pick from master and back port what we need. Thanks, guys! On Tue, Aug 20, 2013 at 10:58 AM, Alex Huang <alex.hu...@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. > > 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. > > --Alex > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
