> 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