Re: [Development] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1
Den 12. mars 2012 23:45, skrev ext Rohan McGovern: Richard Moore said: On 12 March 2012 17:56,kent.han...@nokia.com wrote: Besides flaky tests, we also have the general/recurring problem of changes going into qtbase that break qtdeclarative (and possibly/likely other modules). While I realize it's time-consuming for everyone to manually build and run the qtdeclarative tests (or entire qt5.git) when you're working on qtbase, please at least take the time to consider how your change might affect other modules. If you're unsure and/or would like someone else's opinion on the possible impact, feel free to send an email to this list, or ask on IRC. Thanks. Do you have any idea of how many of these were due to QtDeclarative making assumptions that aren't part of the defined API, vs how many were changes in expected behaviour? Here's the commits which were needed: Thanks for the overview, Rohan. http://codereview.qt-project.org/18909 - 16e29f3 Remove unneeded dependencies to QtWidgets and QtOpenGL - I don't think this one resolves any test failures. It does; by switching to using QGuiApplication for those tests, we effectively sidestep a change in QApplication font loading behavior due to http://codereview.qt-project.org/#change,18621, which broke a test on Mac. http://codereview.qt-project.org/19656 - c787809 Mark presumed unstable test as insignificant. - marks tst_qquickpixmapcache as insignificant, doesn't actually resolve the problem, so the real issue may not yet be understood Yep, it's still not understood. I added a comment to the change about the symptom, but I don't know how to reproduce it. http://codereview.qt-project.org/19552 - dda130f Fix MouseArea autotest. http://codereview.qt-project.org/19534 - 6cf36b2 Fix tst_qquicktextedit. http://codereview.qt-project.org/19427 - cb1ff7a Fix double click handler in QQuickItem. - all of these were failing due to changes in double-click semantics, apparently a bug fix: commit b371f3f943703840d0dfbe30505018bcca06e260 Author: Laszlo Agocslaszlo.p.ag...@nokia.com Date: Tue Mar 6 16:09:09 2012 +0200 Fix double click handling. Yes, the mouse event handling change was the most serious source of failures. In addition, there was a change in QtNetwork last week that I reverted because it caused qtdeclarative autotests to crash. That one is being reapplied again in http://codereview.qt-project.org/#change,19591, hopefully with the crashes gone. http://codereview.qt-project.org/19598 - cbb7f8b Skip test that accesses deleted QML engine - apparently the test reads invalid memory, but doesn't actually crash on most platforms. It might be that the qtbase changes, due to changing the layout of a few things in memory, caused it to start crashing on at least one platform. It turned out that valgrind was already complaining about this on platforms where it didn't crash. Would be good if there were a CI that ran the tests through valgrind, maybe once a week or so. In the qtbase/api_changes branch, there was a change in QString::mid() (the handling of a negative position argument) that caused tst_qquicktextinput::getText to fail. It's difficult to know which type of changes can break stuff in other modules, but things like - QtCore/Gui event/timer handling - Gui text/font changes - Network changes (declarative uses networking extensively) - Changing the semantics of input arguments of public functions might be worth validating against dependent modules. By doing so we can save a lot of time we otherwise have to spend on failed CI rounds and tracking down changes that broke other modules. Regarding flaky tests: This is a nightmare right now since it makes _any_ integration so darn unpredictable. The CI takes ~1.5 hours to build qtdeclarative and run tests on all platforms. Everything might look green and dandy on the seven first machines, but then the last one gets to 99% before failing some test. Then we need to investigate whether that failure is due to a new change in e.g. qtbase, or whether it's flaky, apply some fix (e.g. mark the test as insignificant), and do a whole new round of CI. So please, be careful when adding new tests that rely on timing/event loop specifics. Due to the very nature of QtQuick (interaction tests, networking), I guess it has a higher likelyhood of having flaky tests than other modules. Best regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1
Den 13. mars 2012 12:08, skrev ext Kent Hansen: It's difficult to know which type of changes can break stuff in other modules, but things like - QtCore/Gui event/timer handling - Gui text/font changes - Network changes (declarative uses networking extensively) - Changing the semantics of input arguments of public functions might be worth validating against dependent modules. Let me add - meta-type/QObject kernel changes to that list. Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1
Hi, qtdeclarative needs to be adapted to some recent changes in qtbase. While we try to get that done (http://codereview.qt-project.org/#change,18941), staging of unrelated changes to qtdeclarative has been blocked. Best regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1
Hi, After 4 CI rounds, the sucker finally got merged: qtdeclarative/master is tracking qtbase/master again. In the end we needed to stage eight changes at the same time to get it through, due to various flaky autotests and whatnot. Besides flaky tests, we also have the general/recurring problem of changes going into qtbase that break qtdeclarative (and possibly/likely other modules). While I realize it's time-consuming for everyone to manually build and run the qtdeclarative tests (or entire qt5.git) when you're working on qtbase, please at least take the time to consider how your change might affect other modules. If you're unsure and/or would like someone else's opinion on the possible impact, feel free to send an email to this list, or ask on IRC. Thanks. Best regards, Kent From: development-bounces+kent.hansen=nokia@qt-project.org [development-bounces+kent.hansen=nokia@qt-project.org] on behalf of Hansen Kent (Nokia-MP/Oslo) Sent: Monday, March 12, 2012 10:21 AM To: development@qt-project.org Subject: [Development] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1 Hi, qtdeclarative needs to be adapted to some recent changes in qtbase. While we try to get that done (http://codereview.qt-project.org/#change,18941), staging of unrelated changes to qtdeclarative has been blocked. Best regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1
On segunda-feira, 12 de março de 2012 17.56.14, kent.han...@nokia.com wrote: Hi, After 4 CI rounds, the sucker finally got merged: qtdeclarative/master is tracking qtbase/master again. In the end we needed to stage eight changes at the same time to get it through, due to various flaky autotests and whatnot. Besides flaky tests, we also have the general/recurring problem of changes going into qtbase that break qtdeclarative (and possibly/likely other modules). While I realize it's time-consuming for everyone to manually build and run the qtdeclarative tests (or entire qt5.git) when you're working on qtbase, please at least take the time to consider how your change might affect other modules. If you're unsure and/or would like someone else's opinion on the possible impact, feel free to send an email to this list, or ask on IRC. Thanks. Can you tell us which changes were necessary to fix the compilation? Knowing which areas have caused issues in the past might help targeting in the future. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1
On 12 March 2012 17:56, kent.han...@nokia.com wrote: Besides flaky tests, we also have the general/recurring problem of changes going into qtbase that break qtdeclarative (and possibly/likely other modules). While I realize it's time-consuming for everyone to manually build and run the qtdeclarative tests (or entire qt5.git) when you're working on qtbase, please at least take the time to consider how your change might affect other modules. If you're unsure and/or would like someone else's opinion on the possible impact, feel free to send an email to this list, or ask on IRC. Thanks. Do you have any idea of how many of these were due to QtDeclarative making assumptions that aren't part of the defined API, vs how many were changes in expected behaviour? If you have identified cases of the latter then we should be adding unit tests for them, if we have cases of the former then tbh that's a bug in QtDeclarative. Cheers Rich. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Staging of qtdeclarative changes has been blocked while we try to unpin the qtbase SHA1
Richard Moore said: On 12 March 2012 17:56, kent.han...@nokia.com wrote: Besides flaky tests, we also have the general/recurring problem of changes going into qtbase that break qtdeclarative (and possibly/likely other modules). While I realize it's time-consuming for everyone to manually build and run the qtdeclarative tests (or entire qt5.git) when you're working on qtbase, please at least take the time to consider how your change might affect other modules. If you're unsure and/or would like someone else's opinion on the possible impact, feel free to send an email to this list, or ask on IRC. Thanks. Do you have any idea of how many of these were due to QtDeclarative making assumptions that aren't part of the defined API, vs how many were changes in expected behaviour? Here's the commits which were needed: http://codereview.qt-project.org/18941 - 406f741 Remove pin of qtbase for qtdeclarative. - the one removing the pin, not actually resolving any test failures. http://codereview.qt-project.org/18909 - 16e29f3 Remove unneeded dependencies to QtWidgets and QtOpenGL - I don't think this one resolves any test failures. http://codereview.qt-project.org/19656 - c787809 Mark presumed unstable test as insignificant. - marks tst_qquickpixmapcache as insignificant, doesn't actually resolve the problem, so the real issue may not yet be understood http://codereview.qt-project.org/19552 - dda130f Fix MouseArea autotest. http://codereview.qt-project.org/19534 - 6cf36b2 Fix tst_qquicktextedit. http://codereview.qt-project.org/19427 - cb1ff7a Fix double click handler in QQuickItem. - all of these were failing due to changes in double-click semantics, apparently a bug fix: commit b371f3f943703840d0dfbe30505018bcca06e260 Author: Laszlo Agocs laszlo.p.ag...@nokia.com Date: Tue Mar 6 16:09:09 2012 +0200 Fix double click handling. Until now double clicking in Qt 5 resulted in the following sequence of mouse events: pressed, released, double clicked, released. This is wrong, the press belonging to the second button down is missing. In Qt 4 that pressed event is present. There were also some follow-up commits to this one, I am not sure exactly which one triggered the problems. Probably all of the failing tests were created or updated while qtbase had the buggy double-click behavior. Then they started to fail when the bug was fixed in qtbase. It's still unclear to me if the actual behavior matches what is documented, e.g. http://doc.qt.nokia.com/5.0-snapshot/qwidget.html says If the user double-clicks, the widget receives a mouse press event, a mouse release event and finally this event instead of a second mouse press event, vs Laszlo's comment in tst_qquickmousearea, press, release, (click), press, double click, release. http://codereview.qt-project.org/19598 - cbb7f8b Skip test that accesses deleted QML engine - apparently the test reads invalid memory, but doesn't actually crash on most platforms. It might be that the qtbase changes, due to changing the layout of a few things in memory, caused it to start crashing on at least one platform. http://codereview.qt-project.org/19636 - 2553575 Fix flakiness in qquicklistmodel autotest - the test was buggy, it had a race condition which may have been triggered by someone making some code faster, or perhaps reducing the amount of round trips through the event loop required for one tested condition to become true. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
