[Development] Suggestion for new CI: "early warning" for qt5.git

Alan Alpert alan.alpert at nokia.com
Fri Jan 27 09:20:53 CET 2012


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



More information about the Development mailing list