On Wednesday 07 September 2016 08:37:01 Friedemann Kleint wrote: > ** After 5.7 is closed and sanity bot is upgraded (to handle > cherry-picking), go into cherrypicking mode for 5.6. Developer is > responsible for doing the cherrypicking > ** Cherry-picking technicalities need to be figured out: Let sanity bot > verify source ("cherrypicked from") the SHA1
I'm sorry, but this is nonsense. The source control system works by committing on the older branches and merging up. Cherry-picking from younger branches works against the source control system. We put up with cherry-picking for 4.8, because there we dealt with separate repositories, but that doesn't make is a good model. There's another aspect to this: I develop part of my patches on gt5.git/5.6 and the rest on qtbase.git/dev. I guess for most people with non-unlimited processing power it will be similar. For sure this is the only way if your development focus is on qtbase (and you can't just submit your changes to COIN manually). If I submit from the qt5.git/5.6 built, the changes have gone through testing in the stable branch. If I submit from there to younger branches, test coverage is not as good, but the point is that the stable branch receives the changes tested locally in-situ. If I change this to qt5.git/5.8 and cherry- pick changes back to 5.6, all local testing will have been done in-situ for 5.8, and when submitting to 5.6, no in-situ testing has happened locally. IOW: cherry-picking causes *more* risk to the stable branch than submitting there and merging up. I am not convinced that the perceived security of having a patch integrated into a younger branch and then submitting it to the older branch outweights the loss of test coverage. If the merging strain is too much, only merge 5.6 up once a fortnight/month. Currently, it feels like there's 5.6 -> 5.7 5.7 -> 5.8 5.8 -> dev 5.6 -> 5.7 with maximum speed. That's nice for developers who are splitting changes into a bugfix part for 5.6 and a feature part for 5.8/dev, but it hasn't been like that in the past and we survived, too. And the git history looked cleaner, too :) Thanks, Marc -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development