This topic has never been formally closed. Since the discussion died down and the topic has been agreed upon by consensus, we'd like to move forward testing this scheme for a release and see if it works for Qt or not.
The people making the releases who mostly suffer under qt5.git not integrating asked again about the status and I'd like to conclude this by assuming consensus. As a first step we'll start having a nightly run of qt5.git testing without new changes. Once that runs reasonably well we can start to update qt5.git without the full test run. Greetings, Frederik ________________________________ From: Gladhorn Frederik Sent: Friday, November 29, 2013 6:16 PM To: development@qt-project.org Subject: Integration of qt5.git Hello all, I would like to get feedback about a change in the qt5.git integration that I have discussed with several people in Digia's Oslo office. For those that don't know what I'm talking about: we have the meta repository qt5.git that has all other modules as git submodule. When you clone qt5 and run the init-repository script it checks out the submodules according to the current state of qt5.git. Currently we have a bot doing merges and someone needs to approve them. Once a merge (this is per branch, release/stable/dev) is approved it gets run though CI, just like any other patch. Then all modules are built and all tests run. When all tests pass we have the submodules updated and the game starts anew. The good thing is that usually qt5.git is in a state where it works and it's tested. One issue is that most people working on Qt have all branches checked out to release/stable/dev to a newer state and work on that. But more importantly we need qt5.git to be updated for the release. Usually updating qt5.git works, but sometimes it turns out to take a lot of time and is major work. As you may have noticed it takes a long time to update the packages and this is one factor contributing to that. I'd like to propose the following: Automate qt5.git integration completely (the bot updates the modules and instantly stages the update), this could happen around 3 times per day. This integration would not run any tests and should generally just succeed unless we break compilation of one modules by changing it's dependencies (happens very seldom). Failures send email to this mailing list. Since we lose the test runs for all modules at the same time I'd like to have a second and new job in Jenkins that runs nightly and builds and runs all tests of all modules (according to qt5.git state). This job doesn't mean anything for the integration and doesn't block but simply sends mail to this list whenever any test fails. I actually expect it to fail regularily since we have quite a few unstable unit tests that every once in a while fail. I hope that this approach gives actually more visibility to failing auto tests than what we currently have. I hope all in all this lets us move faster and get releases out with less pain and stress since it's faster to include a patch or two in the release branch. And it lessens the different experiences people have when checking out qt5.git. Cheers Frederik
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
