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

[Kent Hansen]

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