Once scenario I'm worried about is when a less active module (say qtscript) has a regression test failure due to a change in an active module (qtbase) and it's only visible in the qt5.git integration (because nobody submits a change to qtscript).
We will see the failure still, but we will also be very very tempted to still cut a release from qt5.git because of schedules etc. , despite the failure. Currently we have a mechanism in place that makes it very hard to release in such a situation. We are removing this protection and am replacing an automated mechanism with a human gate keeper. I'm not against trying this, but we have to be very careful I think, more discipline will be required from the release side or else we will release with known regressions. Simon Fra: Gladhorn Frederik Sendt: 18:16 fredag 29. november 2013 Til: development@qt-project.org Emne: [Development] 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
