Den 27. jan. 2012 09:20, skrev Alan Alpert: > On Fri, 27 Jan 2012 18:09:46 ext Kent Hansen wrote: >> 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? > How does this compare to our current best alternative, that of your building > Qt 5 and running make check yourself? Do you need to have the tests run on all > the platforms? Is building Qt5 + make check on your own platform too slow or > difficult to be a viable alternative? >
Gerrit: Click a button Me: Check out qt5.git, apply my patch, build and run make check. Yes, it's slow, and a bunch of tests pop up windows that grab focus. I suppose not all platforms are needed. But Windows would be nice because apparently the latest MSVC has c++0x on by default, something we don't test with the Linux CI afaik. Kent _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
