Re: [Development] New Wayland Plugin instructions (on the Wayland web site)
On Sunday, 29 de January de 2012 15.31.00, Mark Constable wrote: On 29/01/12 13:21, Rick Stockton wrote: ... http://wayland.freedesktop.org/qt5.html I'm trying out these notes too, on Archlinux x86_64, and only got as far as this error at the early qmake build stage... The Wayland functionality test failed any hints as to what system components might satisfy this test? Ensure you have a *very* recent Wayland installation (probably compiled from the Git repository) and that it can be found by pkgconfig --cflags --libs wayland-client And that the wayland-scanner binary is somewhere in your $PATH. It is required to compile some XML protocol definitions into code. I also talked to Tiago and he said he had a no make demos and examples build, so his instructions do not include the compilation of the wayland examples, which in turn require the wayland-server packages. Also, the above URL suggests pulling qtbase and there is also a very obvious qt5 repo. Could anyone verify which repo is the real qt5? Huh? -- 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] New Wayland Plugin instructions (on the Wayland web site)
On Sun, Jan 29, 2012 at 7:31 AM, Mark Constable ma...@renta.net wrote: Also, the above URL suggests pulling qtbase and there is also a very obvious qt5 repo. Could anyone verify which repo is the real qt5? There is no single 'Qt' repository anymore. That concept dies with 4.8. The 'qt5' repository is a stub containing pointers to all the submodules that consist of the bulk of the code, plus some helper scripts to clone them etc. The exact submodule you want depends on the code you want to work with, ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enabling -fPIE globally
I think feedback from KDAB and FrogLogic about this change would also be valuable, to discuss the changes required to their tools for automated testing of Qt applications. My understanding is that they now would need a code injector on Linux (like on Windows), instead of simply LD_PRELOADing their libs, right? -- .marius On 1/29/12 2:15 PM, ext Thiago Macieira thiago.macie...@intel.com wrote: Hello Olivier has just uploaded a change ( http://codereview.qt-project.org/14528 ) that enabled -fPIE in all application builds and I support him. He also added a static assertion check for ELF builds without position-independent code, so that people using other buildsystems are reminded to turn -fPIE on too. If you have a problem with this, speak up. Linux distributors, especially, let us know what you think. For more background, please read my blogs on the sorry state of libraries on Linux. But the summary is: function pointer comparison is broken with current versions of gcc and the -Bsymbolic-functions option we've made the default. See also: http://macieira.org/blog/2012/01/sorry-state-of-dynamic-libraries-on-linux / http://macieira.org/blog/2012/01/update-and-benchmark-on-the-dynamic-libra ry- proposals/ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520 http://sourceware.org/bugzilla/show_bug.cgi?id=13600 -- 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 ___ 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] New Wayland Plugin instructions (on the Wayland web site)
On 29/01/12 21:47, Thiago Macieira wrote: http://wayland.freedesktop.org/qt5.html Also, the above URL suggests pulling qtbase and there is also a very obvious qt5 repo. Could anyone verify which repo is the real qt5? Huh? https://qt.gitorious.org/qt/qtbase versus https://qt.gitorious.org/qt/qt5 I've tried building from both repos but so far the freedesktop instructions have worked the best for me. I have a wayland-scanner binary and just seem to be missing wayland-compositor. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enabling -fPIE globally
On Sunday, 29 de January de 2012 15.02.01, marius.storm-ol...@nokia.com wrote: I think feedback from KDAB and FrogLogic about this change would also be valuable, to discuss the changes required to their tools for automated testing of Qt applications. My understanding is that they now would need a code injector on Linux (like on Windows), instead of simply LD_PRELOADing their libs, right? Not exactly. In fact, without -Bsymbolic-functions, we don't add the -- dynamic-list option, which is what enables the symbol hijacking they need. The option is still there, so the hijacking will still work. And I've already asked Stephen to create a proper callback mechanism, instead of relying on hijacking (which I proved not to work in my blog). -- 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] Enabling -fPIE globally
On Sunday, January 29, 2012 16:47:43 Thiago Macieira wrote: On Sunday, 29 de January de 2012 15.02.01, marius.storm-ol...@nokia.com wrote: I think feedback from KDAB and FrogLogic about this change would also be valuable, to discuss the changes required to their tools for automated testing of Qt applications. My understanding is that they now would need a code injector on Linux (like on Windows), instead of simply LD_PRELOADing their libs, right? Not exactly. In fact, without -Bsymbolic-functions, we don't add the -- dynamic-list option, which is what enables the symbol hijacking they need. ... but unfortunately not with gold: http://sourceware.org/bugzilla/show_bug.cgi?id=13577 The option is still there, so the hijacking will still work. I can't seem to make my system behave sanely if I don't use gold. I'm building my Qt 5 with -no-reduce-relocations now. Anyone who wants to can try GammaRay with Qt5 already though. I ported it in early January (using some ifdefs): https://github.com/KDAB/GammaRay And I've already asked Stephen to create a proper callback mechanism, instead of relying on hijacking (which I proved not to work in my blog). The creation of a callback mechanism sounds like a good idea, but will require a lot of thought, coordination and work which is currently unscheduled. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions 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] Enabling -fPIE globally
On Sunday, January 29, 2012 14:15:43 Thiago Macieira wrote: Hello Olivier has just uploaded a change ( http://codereview.qt-project.org/14528 ) that enabled -fPIE in all application builds and I support him. He also added a static assertion check for ELF builds without position-independent code, so that people using other buildsystems are reminded to turn -fPIE on too. If qmake can tell us (at building-Qt-time) that this is needed, I'm sure we can add something to the Qt CMake files to make this easier. If you have a problem with this, speak up. Linux distributors, especially, let us know what you think. Are you sure they're on this mailing list? For more background, please read my blogs on the sorry state of libraries on Linux. But the summary is: function pointer comparison is broken with current versions of gcc and the -Bsymbolic-functions option we've made the default. I have to admit that I don't know what effect this change would have on preloading. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions 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] Enabling -fPIE globally
On Sunday, 29 de January de 2012 18.25.10, Stephen Kelly wrote: If qmake can tell us (at building-Qt-time) that this is needed, I'm sure we can add something to the Qt CMake files to make this easier. contains(QT_CONFIG, reduce_relocations):message(Use -fPIE) If you have a problem with this, speak up. Linux distributors, especially, let us know what you think. Are you sure they're on this mailing list? No. I expect we'll get more feedback after the alpha release. For more background, please read my blogs on the sorry state of libraries on Linux. But the summary is: function pointer comparison is broken with current versions of gcc and the -Bsymbolic-functions option we've made the default. I have to admit that I don't know what effect this change would have on preloading. None. This changes *applications*, not the libraries. -- 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
[Development] Tests, Shadow-Build and Cross-Compilation
Hi all, I finally got around to play with my personal jenkins[1] setup again, specially to learn (and be kind of an example on how a non Tier1 platform could ever become one). There are some issues and I would like to discuss how these can be solved in a way that doesn't look like an ad-hoc solution and that might scale. I will mumble about the Problems, the Ad-Hoc solutions and muse about a fix... Problems: Shadow builds: I always liked shadow builds as I could have several Qt configurations but a command/shared source directory (e.g. X11, QWS, for i386 and ARM). It is quite common for tests to break in shadow builds (the QA page in the wiki discourages this as well). Cross compilation: When cross compiling the machine that compiles the tests will not be the machine that ends up running them. Ad-hoc solutions: Shadow builds: The ad-hoc solution appears to change tests that refer to files in a way like this: VERIFY(file.open(testfile)); to: VERIFY(file.open(SRCDIR testfile)); and put DEFINES += SRCDIR=... into the pro file. Cross compilation: The attribute of cross-compilation and running the test on a different architecture is somehow attributed to both Windows-CE (and Symbian). This manifests in the xmlpatterns test by adding deployment targes, deploy files, change the sourcecode to access different directories. Musing: So somehow cross-compilation and shadow-builds suffer from the same problem that accessing files from the source directory with a relative path. One proposal would be to use something like 'QDir::addSearchPath(testdata, SRCDIR)' and have it set to the path of the .pro file, and access everything using the prefix. Danimo mentioned that this will fail for multimedia that might not use the Qt resource system. So we might want to have a method in the testlib to resolve a path like testdata:foo to a proper path? For cross compiling one could change the testdata prefix with a command line option or environment variable? The other part/wish would be to always have deployment targets for the testcases and generate a run script or such as part of the installation. comments holger [1] http://qt-jenkins.moiji-mobile.com/jenkins/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Tests, Shadow-Build and Cross-Compilation
On Sunday 29 January 2012 21:13:25 Holger Hans Peter Freyther wrote: Hi all, I finally got around to play with my personal jenkins[1] setup again, specially to learn (and be kind of an example on how a non Tier1 platform could ever become one). There are some issues and I would like to discuss how these can be solved in a way that doesn't look like an ad-hoc solution and that might scale. I will mumble about the Problems, the Ad-Hoc solutions and muse about a fix... Problems: Shadow builds: I always liked shadow builds as I could have several Qt configurations but a command/shared source directory (e.g. X11, QWS, for i386 and ARM). It is quite common for tests to break in shadow builds (the QA page in the wiki discourages this as well). Yes, the wiki recommands not to use shadowbuild because it often do not work. (I had the problem today again while trying to run qlibrary autotest) [...] Musing: So somehow cross-compilation and shadow-builds suffer from the same problem that accessing files from the source directory with a relative path. One proposal would be to use something like 'QDir::addSearchPath(testdata, SRCDIR)' and have it set to the path of the .pro file, and access everything using the prefix. Danimo mentioned that this will fail for multimedia that might not use the Qt resource system. So we might want to have a method in the testlib to resolve a path like testdata:foo to a proper path? For cross compiling one could change the testdata prefix with a command line option or environment variable? The other part/wish would be to always have deployment targets for the testcases and generate a run script or such as part of the installation. There is QFINDTESTDATA and QTest::qFindTestData that have been added recently, I think for this reason. Have you heard of them? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Wayland Plugin instructions (on the Wayland web site)
Hi, the wayland-compositor is nowadays called Weston and lives in the Wayland Repository. If you want to build wayland (which is a requirement to build qtwayland I think), be sure to fetch the correct SHA1 from the QtWayland Repo as this is the SHA1 used to verify that it is working correctly. This SHA1 can be found in a Readme file in the QtWayland Repo. Holger Ihrig Mobile Phones Middleware - Quality Engineering http://wikis.in.nokia.com/QtQualityEngineering From: development-bounces+holger.ihrig=nokia@qt-project.org [development-bounces+holger.ihrig=nokia@qt-project.org] on behalf of ext Mark Constable [ma...@renta.net] Sent: Sunday, January 29, 2012 4:31 PM To: development@qt-project.org Subject: Re: [Development] New Wayland Plugin instructions (on the Wayland web site) On 29/01/12 21:47, Thiago Macieira wrote: http://wayland.freedesktop.org/qt5.html Also, the above URL suggests pulling qtbase and there is also a very obvious qt5 repo. Could anyone verify which repo is the real qt5? Huh? https://qt.gitorious.org/qt/qtbase versus https://qt.gitorious.org/qt/qt5 I've tried building from both repos but so far the freedesktop instructions have worked the best for me. I have a wayland-scanner binary and just seem to be missing wayland-compositor. ___ 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] Tests, Shadow-Build and Cross-Compilation
Olivier Goffart said: On Sunday 29 January 2012 21:13:25 Holger Hans Peter Freyther wrote: Hi all, I finally got around to play with my personal jenkins[1] setup again, specially to learn (and be kind of an example on how a non Tier1 platform could ever become one). There are some issues and I would like to discuss how these can be solved in a way that doesn't look like an ad-hoc solution and that might scale. I will mumble about the Problems, the Ad-Hoc solutions and muse about a fix... Problems: Shadow builds: I always liked shadow builds as I could have several Qt configurations but a command/shared source directory (e.g. X11, QWS, for i386 and ARM). It is quite common for tests to break in shadow builds (the QA page in the wiki discourages this as well). Yes, the wiki recommands not to use shadowbuild because it often do not work. (I had the problem today again while trying to run qlibrary autotest) Hopefully this advice can be removed at some point. There are 1-2 people gradually working on fixing up all the tests to work for shadow builds, at which point it will be blocking in the codereview CI. About half the modules (the simpler ones) are already set up for shadow builds, they can be seen at http://wiki.qt-project.org/Public_Autotest_Infrastructure#linux-g.2B.2B_shadow-build_Ubuntu_11.10_x86 [...] Musing: So somehow cross-compilation and shadow-builds suffer from the same problem that accessing files from the source directory with a relative path. One proposal would be to use something like 'QDir::addSearchPath(testdata, SRCDIR)' and have it set to the path of the .pro file, and access everything using the prefix. Danimo mentioned that this will fail for multimedia that might not use the Qt resource system. So we might want to have a method in the testlib to resolve a path like testdata:foo to a proper path? For cross compiling one could change the testdata prefix with a command line option or environment variable? The other part/wish would be to always have deployment targets for the testcases and generate a run script or such as part of the installation. There is QFINDTESTDATA and QTest::qFindTestData that have been added recently, I think for this reason. Have you heard of them? Yes they were added exactly for this. There is also TESTDATA in .pro files to install test data files, but this is not really good enough to be documented other than a comment in testcase.prf. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Development Digest, Vol 4, Issue 94
Date: Sun, 29 Jan 2012 01:55:54 +1100 From: craig.sc...@csiro.au Subject: Re: [Development] Work on qDebug and friends To: development@qt-project.org Message-ID: 6219d4f4-6cd0-4c5f-9e82-3a4a722ed...@csiro.au Content-Type: text/plain; charset=us-ascii Sorry for the lack of context (dealing with digest emails while on leave :-P ). With the talk about logging in this thread, is it of interest / scope to also have the associated classes support capturing the standard C/C++ streams? By this, I mean capturing whatever gets logged via std::cout or things like printf()? I know this might not be of much interest to Qt purists, but it would be rather useful when you need to integrate with third party code and want to redirect all output. The trick is doing it on all platforms in a consistent way (Windows really muddies the waters with its separation of GUI and console apps). This would not be something for Qt 5.0, but might be worth keeping in mind from an API point of view in case someone wants to do this in a consistent way in future versions. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia Yes I think this should be in. The category QLog should be in default the standard output. If you define in your QLog config file an output file the QLog will write the logs into this output file otherwise it will be std out. Another point is that we want the QLog enabled and disabled without recompiling your code. For instead a customer reports a problem and the developer needs to have more information. The developer can send a QLog config file to the customer and ask the customer to send back the output file. If there is no QLog config file then no logging should be performed. -- Wolfgang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Development Digest, Vol 4, Issue 94
Sorry, forgot the Subject -Original Message- From: Beck Wolfgang (Nokia-MP/Brisbane) Sent: Monday, January 30, 2012 10:02 AM To: development@qt-project.org Cc: 'craig.sc...@csiro.au' Subject: RE: Development Digest, Vol 4, Issue 94 Date: Sun, 29 Jan 2012 01:55:54 +1100 From: craig.sc...@csiro.au Subject: Re: [Development] Work on qDebug and friends To: development@qt-project.org Message-ID: 6219d4f4-6cd0-4c5f-9e82-3a4a722ed...@csiro.au Content-Type: text/plain; charset=us-ascii Sorry for the lack of context (dealing with digest emails while on leave :-P ). With the talk about logging in this thread, is it of interest / scope to also have the associated classes support capturing the standard C/C++ streams? By this, I mean capturing whatever gets logged via std::cout or things like printf()? I know this might not be of much interest to Qt purists, but it would be rather useful when you need to integrate with third party code and want to redirect all output. The trick is doing it on all platforms in a consistent way (Windows really muddies the waters with its separation of GUI and console apps). This would not be something for Qt 5.0, but might be worth keeping in mind from an API point of view in case someone wants to do this in a consistent way in future versions. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia Yes I think this should be in. The category QLog should be in default the standard output. If you define in your QLog config file an output file the QLog will write the logs into this output file otherwise it will be std out. Another point is that we want the QLog enabled and disabled without recompiling your code. For instead a customer reports a problem and the developer needs to have more information. The developer can send a QLog config file to the customer and ask the customer to send back the output file. If there is no QLog config file then no logging should be performed. -- Wolfgang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use make before you push and stage
Jedrzej Nowacki said: You are assuming that we need to test every patchest which would be nice, but it is not necessary. A bot-tester would be sufficient, it might be added as a reviewer by human reviewer only if it makes sense. I like this idea and had been thinking along these lines for a while. Similar to how all changes at the moment automatically end up with Qt Sanity Bot as a reviewer, a developer could explicitly add other test bots as reviewers to their change. This could also include testing which takes too long to perform in the main CI. If anyone thinks this is _not_ a good idea then I would be interested to hear the reasons :) We do not need to test every platform, only the fastest one. The point of this system would be to reduce failures count because of simple mistakes; like broken compilation because missing function. It doesn't have to find problems related to differences in compilers. Another thing is, can it happen in parallel? Do we use 100% of test server capacity? Btw. I do not think that ccache is a hack, I was using it for a few months working on Qt and it was ok. Currently, there is no way to test properly difficult patches without staging them. Only CI knows how to test Qt correctly, which tests are flaky, which tests may be ignored, which may be run in parallel and which needs to be run without touching mouse/keyboard because of focus issues. Parsing output of make check is not funny too. Everything that improves that situation even slightly is awesome. I agree with the main point of this paragraph but would like to correct a couple of minor things: Only CI knows ... which tests may be ignored = mostly false, the build system knows this. CONFIG+=insignificant_test in a .pro file causes `make check' to ignore the exit code of a testcase, both in CI and when you run `make check' locally. The exception is that the CI system can be configured to ignore _all_ autotests for a particular configuration, and nothing in the tested repo tells you this. Only CI knows ... which may be run in parallel = none of them are run in parallel by CI. If you are thinking of CONFIG+=parallel_test: that was added for this utility http://labs.qt.nokia.com/2010/10/29/making-auto-testing-easier/ by Yoann Lopes, and as far as I know has never been used by any other tools. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use make before you push and stage
On 30 January 2012 03:51, Rohan McGovern rohan.mcgov...@nokia.com wrote: I don't think it is a good idea. Having errors with incremental builds which go away when you do a clean build is one thing, but there are also some issues which _should_ cause the build to fail, but don't if you only do incremental builds. Thinking out loud - mad idea. Does anyone have (or knows how to extract from gerrit) stats about how many stages are requested on average during the week? Would it be possible to do incremental builds when the one sub-repository is more active, and full builds otherwise (with patches that are merged in if and only if they pass the full build)? For instance, if qtbase is more active during CET working hours, one could think of having incremental builds from 8.00-12.00 and 15.00-18.00, with a full build at 12.00 (~3h, till 15.00) and other full builds starting at 18.00 and going on overnight? -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggestion for new CI: early warning for qt5.git
Olivier Goffart said: On Friday 27 January 2012 09:09:46 Kent Hansen wrote: [...] If there is no quick fix, the last resort is to pin one or more of the dependencies' to a particular SHA1 (e.g. from the qt5.git submodule) in the sync.profile until the issue has been resolved, then unpin it again later. Why is that the last resort? This seems totally normal and was the whole point of modularisation: Differents modules can be developped at different speed. When this was discussed back when CI was being established on modularized Qt, the consensus[1] was that the goal should be to keep the head of all modules working together as much as possible - that's why people have been discouraged from using anything other than the head of their dependencies in sync.profile. [1] which in this case really means the thing that someone said and no-one objected to :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use make before you push and stage
On 30 January 2012 04:18, Giuseppe D'Angelo dange...@gmail.com wrote: Does anyone have (or knows how to extract from gerrit) stats about how many stages are requested on average during the week? Sorry, I meant: on avarage _per hour_ during a week. -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggestion for new CI: early warning for qt5.git
On Fri, 27 Jan 2012 23:07:07 ext Olivier Goffart wrote: On Friday 27 January 2012 09:09:46 Kent Hansen wrote: [...] If there is no quick fix, the last resort is to pin one or more of the dependencies' to a particular SHA1 (e.g. from the qt5.git submodule) in the sync.profile until the issue has been resolved, then unpin it again later. Why is that the last resort? This seems totally normal and was the whole point of modularisation: Differents modules can be developped at different speed. It's the last resort because proper modularization isn't going to cause these sorts of problems. Proper modularization means that you aren't going to screw up dependent modules unless you make deliberately incompatible changes to your API, for which you normally will provide a smooth transition path (e.g. deprecate the old one and let them live side by side for a while). So these shouldn't happen, and your first step should be to fix your smooth transition path to be smooth enough for CI not to be blocked. Because CI blocking would mean that users of your module have just had their code broken by a module below. We don't like putting them in that situation. That said, stuff exists like QtDeclarative reaching deep into the private headers of QtCore, and depending on details of the metatype system. So we're largely suffering because we have not been able to modularize properly. If not, modularisation was just a waste of time and a way to make development more difficult. Arguably we have not successfully modularized if we still have such tight dependencies. But I'm optimistic enough to think it will settle down once 5.0.0 is out and we're vaguely respecting compatibility again :) . -- Alan Alpert Senior Engineer Nokia, Qt Development Frameworks ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggestion for new CI: early warning for qt5.git
Kent Hansen said: Hi, Sometimes there are changes to qtbase that the author and/or reviewers strongly suspect will break one or more modules on top of it (e.g. in qt5.git). For example, source-incompatible changes (removing QEventLoop::DeferredDeletion), or changes to the meta-type/QObject internals (which qtdeclarative is relying heavily on). When such a change goes into qtbase, you only get the failure for the dependent modules the next time you stage something (anything) in that other module; suddenly the module no longer builds, or tests seemingly unrelated to the developer's own change start failing. This means developers will be scratching their heads and spending time tracking down what was the actual cause of the failure (first in their own changes/module, then in the dependencies). It also means that the CI is wasting cycles on subsequent (failed) attempts to fix the failure, which is disruptive to everyone trying to stage new and unrelated changes. If there is no quick fix, the last resort is to pin one or more of the dependencies' to a particular SHA1 (e.g. from the qt5.git submodule) in the sync.profile until the issue has been resolved, then unpin it again later. An idea to avoid such disruption would be a CI where you can try to merge your change, and it will build all of qt5.git with it (_and_ run all the module's tests). This could be a separate button in Gerrit, for example. You then get a report in Gerrit with the status from the complete build tests run. Even if everything succeeds, the change will not actually be integrated; this would just be a tool for getting an indication of potential inter-module problems with your patch. If there are problems, the developer can then either fix the affected modules in advance if possible, or at least give a heads-up and/or prepare patches that will fix the upcoming breakage in the other modules. What do you think? As Joao mentioned, this relates to a dry run of the CI feature. I think that we need a method of requesting that some test procedure is run over your change in gerrit, without also testing some set of everyone else's changes at the same time, and without requesting that the change is actually merged into the repository at the end of the test. If we have that, then we can add all sorts of test procedures into that workflow. test all of qt5 on top of my change would be a natural test to provide. You mentioned a button in gerrit, but what do you think of soliciting machine reviewers instead, as you currently do for humans? e.g. 1. push change to gerrit 2. go to web UI, add reviewer named something like Test : qt5.git tester : compile/test all of qt5.git with your change 3. qt5.git tester immediately adds comment I'll start testing your change in (~ some time estimate) 4. qt5.git tester later adds pass or fail comment, with a link to a build/test log. 3 could be omitted if that's perceived as too noisy. You could add multiple testers with different goals this way, and they'd operate independent from each other. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Suggestion for new CI: early warning for qt5.git
Den 30. jan. 2012 06:03, skrev Rohan McGovern: As Joao mentioned, this relates to a dry run of the CI feature. I think that we need a method of requesting that some test procedure is run over your change in gerrit, without also testing some set of everyone else's changes at the same time, and without requesting that the change is actually merged into the repository at the end of the test. Definitely, being able to test a change in isolation would be required, I think; otherwise you lose the confidence in the test results again (was it me, or did that other change sneak in and break everything?). (That's not a problem specific to testing/dry runs, though; right now anyone could be the unlucky person that gets his/her change staged together with an unrelated change that breaks stuff. I don't have a good suggestion for reducing that problem; Jedrzej had the idea of limiting the number of unique commit authors per CI round to some constant N (3 or 4?).) You mentioned a button in gerrit, but what do you think of soliciting machine reviewers instead, as you currently do for humans? e.g. 1. push change to gerrit 2. go to web UI, add reviewer named something like Test : qt5.git tester : compile/test all of qt5.git with your change 3. qt5.git tester immediately adds comment I'll start testing your change in (~ some time estimate) 4. qt5.git tester later adds pass or fail comment, with a link to a build/test log. 3 could be omitted if that's perceived as too noisy. You could add multiple testers with different goals this way, and they'd operate independent from each other. That's a great idea! I'd start using it today. :-) Maybe the reviewer bots could be displayed as suggested reviewers or something to make their existence more known in the web UI. Regards, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
