[Development] Integration of qt5.git

[André Pönitz]

On Fri, Nov 29, 2013 at 05:16:31PM +0000, Gladhorn Frederik wrote:
> Hello all,
> 
> I would like to get feedback about a change in the qt5.git integration
> that I have discussed with several people in Digia's Oslo office.
> 
> For those that don't know what I'm talking about: we have the meta
> repository qt5.git that has all other modules as git submodule. When you
> clone qt5 and run the init-repository script it checks out the submodules
> according to the current state of qt5.git.
> 
> Currently we have a bot doing merges and someone needs to approve them.
> Once a merge (this is per branch, release/stable/dev) is approved it gets
> run though CI, just like any other patch.  Then all modules are built and
> all tests run. When all tests pass we have the submodules updated and the
> game starts anew.
> 
> The good thing is that usually qt5.git is in a state where it works and
> it's tested.  One issue is that most people working on Qt have all
> branches checked out to release/stable/dev to a newer state and work on
> that.  But more importantly we need qt5.git to be updated for the
> release.  Usually updating qt5.git works, but sometimes it turns out to
> take a lot of time and is major work.  As you may have noticed it takes a
> long time to update the packages and this is one factor contributing to
> that.
> 
> I'd like to propose the following: Automate qt5.git integration
> completely (the bot updates the modules and instantly stages the update),
> this could happen around 3 times per day. This integration would not run
> any tests and should generally just succeed unless we break compilation
> of one modules by changing it's dependencies (happens very seldom).
> Failures send email to this mailing list.
> 
> Since we lose the test runs for all modules at the same time I'd like to
> have a second and new job in Jenkins that runs nightly and builds and
> runs all tests of all modules (according to qt5.git state). This job
> doesn't mean anything for the integration and doesn't block but simply
> sends mail to this list whenever any test fails.  I actually expect it to
> fail regularily since we have quite a few unstable unit tests that every
> once in a while fail. I hope that this approach gives actually more
> visibility to failing auto tests than what we currently have.
> 
> I hope all in all this lets us move faster and get releases out with less
> pain and stress since it's faster to include a patch or two in the
> release branch.  And it lessens the different experiences people have
> when checking out qt5.git.

I am very much in favour.

In an ideal world, this should not be needed, but the world does not appear
to be ideal...

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. Sure, things can break 
theoretically, and do in practice every now and then, but a build breakage
can be fixed in a minute - 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. If it works for other
use cases that's fine, but in no way essential.

Andre'