[Development] Solutions for ensuring that changes in upstream modules are tested with downstream modules before merging

[Mitch Curtis]

From: Development <development-bounces at qt-project.org> On Behalf Of Shawn Rutledge
Sent: Tuesday, 15 June 2021 10:57 PM
To: development at qt-project.org
Subject: Re: [Development] Solutions for ensuring that changes in upstream modules are tested with downstream modules before merging


On 2021 Jun 7, at 15:30, Mitch Curtis <mitch.curtis at qt.io<mailto:mitch.curtis at qt.io>> wrote:

Some I can think of:

- Slower git operations.
- Slower build times for qtdeclarative devs. You can use e.g. ninja targets, but you would have to do this every time you build. Ideally we’d add a configure option for this, like -no-gui in qtbase, so that they don’t need to build qtquickcontrols2.

FWIW, I’m routinely building all of Qt together (the modules that I have anyway) with cmake and ninja.  (It’s around 15k steps, building all autotests but not examples.  A Zen3 processor and ccache make it bearable.  Before that, I was using icecc.)  So the cases where I have broken something in controls by making a change in qtdeclarative are usually only test failures (behavior changes), not build failures, right?  (Or at least not build failures that I didn’t know about.)  I never run all autotests in all modules locally, because it takes too long.  Even running all tests in qtdeclarative takes too long, except when the change is so invasive that I know I really need to.  If I’m worried about a specific change breaking controls, I run those tests.  (The script to run tests in xephyr is handy, so I can keep using the computer while they are running.)

“only” test failures, yes. :D Build failures would be preferable because they’re more obvious and easily fixed.

I rarely run all tests for a module when making a change. I’d never get any work done if I did.

- Creator would probably be quite a bit slower to work with having both of these in one project.

Qtdeclarative is already a rather big module.  And Creator is slow, for sure.  It’s been a couple of years since I could use it at all on my older laptops without enough memory.


This why I like the idea of just running qtquickcontrols2 tests for each qtdeclarative change: it doesn’t waste developer time (and again, CI integrations don’t count since they shouldn’t be wasting developer time).

Hopefully that will work, yeah.


Though then you do lose the ability to use controls in examples, which does seem like a huge loss.

It depends whether we care about being able to automatically test examples without building controls first, right?  Otherwise I thought the existing advice lately is to go ahead and use controls in examples?

I’m not sure to be honest. I know the consensus is that we should use controls in examples but I don’t know how that’s supposed to work in terms of module dependencies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20210616/45aa7639/attachment.html>