[Development] Integration of qt5.git

[Oswald Buddenhagen]

On Fri, Nov 29, 2013 at 09:50:31PM +0100, André Pönitz wrote:
> The scheme is fairly close to what Qt Creator's use of CI looks like
> (non-blocking, nag mails if things break, nothing stopping quick fixes),
> and it's a state that I am rather happy with.
>
i'm not.
(surprise surprise)

> Sure, things can break theoretically, and do in practice every now and
> then,
>
(surprise surprise)

> but a build breakage can be fixed in a minute -
>
what you are missing is that 95% of those "quick fixes" would have never
been necessary in the first place if creator actually had a real CI.
also, unlike the impression you are trying to create, most fixes are not
that urgent at all. but then, you are the guy who has probably the most
self-approved commits (without a +1) within the entire community.

> the latter part slightly in contrast to qt5.git.

> Since the main use of qt5.git is to _release_ stuff, its setup and
> policies should cater to exactly that need first.
> 
that's not at all what qt5.git was supposed to be about.
it was about having a snapshot of the latest known working combination
of all modules, so people would have an easy way to check things out and
have a stable basis for their work. that's exactly what the setup does,
pretty well.

anyway, it quickly became apparent that a) independent releases of
modules won't happen and b) using the supermodule for releases is kinda
obvious (though the first step was forking it into qtsdk ... argh).

now that it's clear that the modularization did not solve as many
problems as we hoped, it's about time to adjust the system "a bit":

introduce complete reverse dependency coverage. of course with a
backdoor: it should be possible to manually override the verdict of the
CI, to permit expected breakages through (when an incompatible change
requires followups), and to ignore known unstable tests.

obviously, the system needs to be a lot more performant to reasonably
suppport that - not by adding yet more machines, but by deploying
state-of-the-art technologies (caching for the build, call graphs to
determine which changed files justify running which tests, etc.).
at this point, the supermodule would not need any CI at all, but could
be updated as a side effect of the "regular" CI runs.

given the persisting realities of the current system it is of course
tempting to just turn off the tests in qt5.
we may do that to get the release out, but aiming for this being a
permanent state (for the forseeable future) is admitting defeat.