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

[joao.abecasis at nokia.com]

+1

I like this idea. It would allow you to both test a change before integrating and check if preventive changes (whenever possible) already applied in upstream modules are working as expected.

Since this would effectively offer another commonly requested feature (namely, a dry run of the CI) it would be best if there was also a way to test a change in a single module.

Perhaps these could work simply as non-integrating branches, with tighter control over staging, as you wouldn't want unrelated changes undermining yours; our this to be used/advocated for every single change.

My 50 øre.


João
On 27/01/2012 9:12 Hansen Kent (Nokia-MP/Oslo) 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?

Best regards,
Kent
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development