[Development] Use make before you push and stage

[Rohan McGovern]

Stephen Kelly said:
> I wonder if it's possible for the CI system to maintain and clone 
> a working master build which patches could be applied to and build 
> incrementally? (an un-clean build)
> 

Andreas said:
> How about investigating incremental builds? Could reduce compile time
> to just a few minutes per patch. We do that where I work, with hundreds
> of changes done to the repo every day, and every single patch is
> compiletested. Tests are also run per change, but we only run fast
> tests per change; slow tests are run in a separate cycle (on a best
> effort basis).
>
> The occasional breakage happens whenever changes are made to build
> files, like Makefiles or pro files, typically when moving code around.
> But it's rare and manageable, as long as it's possible to force a full
> rebuild on demand.

I don't think it is a good idea.
Having errors with incremental builds which go away when you do a clean
build is one thing, but there are also some issues which _should_
cause the build to fail, but don't if you only do incremental builds.

For example, if you make a change which causes some library or header to
be removed/renamed, and you forget to update all consumers of that
library/header, it can easily go unnoticed, because the old
library/header still exists in the build tree until you do a clean
build.

Another example is failing to declare the dependencies between projects,
which would typically be discovered by a clean build with high -j, but
missed in incremental builds (because the dependencies are probably
still there from the last build).

I can't comment exactly how rare or not that would be for Qt.
I guess it would happen more often during the most critical times and
cause frustration when everyone is trying to get their refactoring
integrated before some freeze.  Anyway, I am not really interested in
hitting the "do a clean build" button or attempting to
determine/communicate the heuristics for deciding to do that.

I would prefer us to move towards the state where, if the CI system
posts a failure report onto your change, then there is a very high
chance the failure is actually caused by your change.