[Development] Notes on "Managing Qt's branches" session @ QCS 2016

[Konstantin Tokarev]

04.10.2016, 14:04, "Edward Welbourne" <edward.welbourne at qt.io>:
> 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
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin