Hi, Our aim was to get new platforms in immediately after the previous platforms branched away from dev branch. Meaning, when 5.7 branch was created and it branched away from dev branch, all new platforms aiming for 5.8 should have been put into dev branch. However, in practice it didn't quite go as expected. Not to blame anyone, but all focus was to get 5.6.x and 5.7.x out. Meaning, dev branch was left broken for several months. The individual submodules did pass in the CI, but the last time Qt5 has passed is 4 months ago.
To tackle this we agreed that we can start inserting new platforms submodule by submodule, but right after that we froze Coin setup so that we don't break 5.7.x by accident. And by having several branches, with alphas, betas, release candidates and releases themselves we have a lot of these freezes, which means that the time window, where we can put in any new platform, is very short. And if the submodule in dev don't happen to have everything merged from earlier branches and finally work, an insertion won't happen. This is why we've not been successful in bringing openSUSE 42.1, Ubuntu 16.04, RHEL 7.2, OS X 10.11 in into dev branch albeit trying to do that for months. So back to this day. Currently we can't put anything new in, since Coin setup is frozen. We have holidays coming up and we have a skeleton crew working the entire summer. Right as we get back to work, we have 5.8 branch coming up and feature freeze right after that. When did you expect us to push in these new platforms? According to process, we shouldn't put them into 5.8 after FF. If we bend this rule (as we usually do), we might get them in there as people focus on fixing issues there, or the same thing happens as happened with 5.7: the new platforms simply never passed autotests so that they could be brought in (we actually did try to get them into 5.7 early on, but not lately due to release being too close). Ok...perhaps I should propose something. Let's postpone branching 5.8. As much as I like the motto of Blizzard Entertainment "done when it's done" , I've found that people like time schedules as well. Alas, I have to suggest that we postpone it as much as possible. I think that we can fix the things we want to fix in 5.8 in dev branch as well. When we get a more mature dev branch that actually works, we can generate the alpha package for 5.8 much faster after the branch, as 5.8 already worked right of the bat (because dev worked). Also, we'll get a working dev branch as well simultaneously. Also, we've noticed that often when people fix problems found in autotests, being it a bug in the autotest itself or as it actually more often is, a problem in Qt sources themselves, people push the fix to the most mature branch available. In this case, when we report that we can't get openSUSE 42.1 in, because this and that fails, the fix is pushed into 5.6 as it already appears there but haven't been found or studied before. Then we have to sit down and in worst case wait for a 5.6.1 -> 5.6 -> 5.7 -> dev merge. With all the general flakiness in the system, that usually takes a fortnight at least. So by fixing dev, we can skip doing merges from 5.8 -> dev when we eventually find the problems for these new platforms. With regards, -Tony PS: The list with new platforms actually increases yet with OS X...ehm macOS Sierra (10.12) beta coming up, tvOS etc... From: Development [mailto:[email protected]] On Behalf Of Maurice Kalinowski Sent: 15. kesäkuuta 2016 16:51 To: Tuukka Turunen <[email protected]>; Jake Petroules <[email protected]>; Mike Krus <[email protected]> Cc: [email protected] Subject: Re: [Development] Qt 5.8 branching & Feature Freeze Hi, Another option might be to do it the same way like we do for UWP currently due to limited resources on the CI system. There we have at least a compile check every time qt5.git integration is supposed to happen. This is bare minimum, but at least guarantees that compilation will work for release. The rest still needs to be manually tested and/or is covered by Windows 8.1 WinRT test coverage (which isn't too high either). BR, Maurice Von: Development [mailto:[email protected]] Im Auftrag von Tuukka Turunen Gesendet: Wednesday, June 15, 2016 11:59 AM An: Jake Petroules <[email protected]>; Mike Krus <[email protected]> Cc: [email protected] Betreff: Re: [Development] Qt 5.8 branching & Feature Freeze Hi, Perhaps we could do without CI for tvOS for Qt 5.8 and fix issues when breakages happen. We are still quite stretched with the CI and adding tvOS increases the load of the CI and also risk of breakages for everyone. That of course is the role of CI, but since tvOS is not at the moment so critical, perhaps it is better to monitor it and fix afterwards when breakages do occur. Yours, Tuukka From: Jake Petroules Sent: keskiviikkona 15. kesäkuuta 2016 12.01 To: Mike Krus <[email protected]<mailto:[email protected]>> Cc: Tuukka Turunen <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [Development] Qt 5.8 branching & Feature Freeze +1. I requested this earlier as well. On Jun 15, 2016, at 1:51 AM, Mike Krus <[email protected]<mailto:[email protected]>> wrote: Hi would it be possible to have CI for tvOS in time for this too? Cheers, Mike On 15 Jun 2016, at 08:15, Tuukka Turunen <[email protected]<mailto:[email protected]>> wrote: Hi, I would also like to have all new modules (if any) of Qt 5.8 as well as implement all (feasible) platform and compiler versions well before the feature freeze. Is it possible to agree that latest by 1.8. all these are completed? Preferably earlier, if possible. Yours, Tuukka From: Development [mailto:[email protected]] On Behalf Of Jani Heikkinen Sent: keskiviikkona 15. kesäkuuta 2016 9.27 To: [email protected]<mailto:[email protected]> Subject: [Development] Qt 5.8 branching & Feature Freeze Hi all, It was agreed in yesterday's release team meeting to propose following schedule for Qt 5.8 branching and Feature Freeze: - Start branching '5.8' from 'dev': 2.8.2016 - Feature Freeze (and finalize branching): 9.8.2016 With that schedule we should be able to release Qt 5.8.0 before Christmas. Delaying these would cause Qt 5.8.0 release to be delayed to the beginning of next year. Any objections? br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland [email protected]<mailto:[email protected]> +358 50 4873735 http://qt.io<http://qt.io/> [Image removed by sender.]<http://qt.io/> [Image removed by sender.]<http://www.facebook.com/Qt> [Image removed by sender.]<http://www.twitter.com/qtproject> [Image removed by sender.]<https://www.linkedin.com/company/the-qt-company/> [Image removed by sender.]<https://plus.google.com/104580575722059274792> [Image removed by sender.]<https://www.youtube.com/QtStudios> _______________________________________________ Development mailing list [email protected]<mailto:[email protected]> http://lists.qt-project.org/mailman/listinfo/development -- Mike Krus | [email protected]<mailto:[email protected]> | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK +44-1625-809908 Mobile: +44 7833 491941 KDAB - The Qt Experts _______________________________________________ Development mailing list [email protected]<mailto:[email protected]> http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - [email protected]<mailto:[email protected]> Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io<http://qbs.io>
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
