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? -- Alan Alpert Senior Engineer Nokia, Qt Development Frameworks _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development