On Tue, Aug 20, 2013 at 12:58 PM, 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. >
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. > Agreed.
