Marc Mutz said: > I just came to realise another reason against cherry-picking: > > Qt 5.6 is C++98-only while 5.7+ is C++11. That means patches that will > be developed against 5.7+ will very likely have C++11 constructs in > them that won't work in Qt 5.6.
Conversely, code developed in 5.6 shall avoid C++11 constructs; when we merge to 5.7, we need to review to find C++11 usage we can apply, which tends to get missed after merges. > That means that in order to backport, the code needs to be > de-C++11-ified, which in turn means the usual reasoning for > cherry-picking as a stability feature (it's been integrated already > once successfully) falls flat on its face, because the code submitted > against 5.7+ must needs be changed (forgive my Victorian) in the > process of cherry-picking to 5.6, invalidating any test coverage it > may have had as part of the younger branch. Back-porting doesn't *entirely* invalidate the stability evidence gained in a later branch, any more than conflict resolutions in forward-merging invalidate stability evidence gained in an older branch. Of course, you need to test after back-porting, just as you do after forward-merging, but the existing test coverage is still valuable. > To avoid the guaranteed merge conflicts from > cherry-picked-and-changed, commits, Not sure what you're referring to here. Just to be clear, once we switch to cherry-picking back to 5.6, we shall stop merging forward from 5.6, so there shall be no merge conflicts from those changes being merged up into 5.7 again. That would be dumb. > you'd need to ban any non-cherry-pick changes to 5.6, which > effectively means that no developer does any work on 5.6 anymore. That did seem to be the intent of those who proposed this, yes. Of course, there shall be *some* work on 5.6, but it shall be limited to back-porting already-tested fixes and investigating bugs that are only evident in 5.6. That would be the point of LTS, IIUC. > Everyone will rely on the CI, and the CI only. Again, not sure what you mean here; and those doing back-ports shall of course be doing local testing before they push, so not relying only on the CI - where, in contrast, after a merge we *are* relying on the CI and only the CI, except for the (relatively few) conflicts in each merge, which do get review. > OTOH, with very few exceptions such a Q_FOREACH, code that > successfully integrated into 5.6 will successfully integrate in 5.7+. ... but will, as noted above, contain pre-C++11 code in need of C++1-ifying, after we've done sweeps through the code-base catching such code and modernising most of what's in 5.7 and beyond; so we would need to pay attention to each change flowing up from 5.6, to see what needs such attention. The advantage of cherry-picking is precisely that each one shall need to be done attentively and reviewed, while merging only gets review of its conflicts and happens quietly in the background, with few paying attention to it. > In light of this I continue to vote for keeping the "no-cherry-picks > allowed" policy that has served us well over the Qt 5 years. I remain unconvinced, see above, Eddy. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development