04.10.2016, 14:04, "Edward Welbourne" <[email protected]>: > 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.
This can be easily fixed by using tools like clang-tidy (modernize* checks) > >> 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
