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

[Mitch Curtis]

> -----Original Message-----
> From: Volker Hilsheimer <volker.hilsheimer at qt.io>
> Sent: Friday, 4 June 2021 2:45 PM
> To: Mitch Curtis <mitch.curtis at qt.io>
> Cc: development at qt-project.org
> Subject: Re: [Development] Solutions for ensuring that changes in upstream
> modules are tested with downstream modules before merging
> 
> > On 4 Jun 2021, at 13:56, Mitch Curtis <mitch.curtis at qt.io> wrote:
> >
> > Hi.
> >
> > A common problem I see is that a change in say qtbase or qtdeclarative can
> cause test failures in modules that depend on them after that change is
> merged. As a result, dependency updates for the downstream modules can
> be blocked, requiring the module maintainer to look into the failure, only to
> discover that it is caused by an upstream module. This causes a lot of time
> and effort to be diverted away from regular work. Both upstream and
> downstream developers would benefit from having more immediate CI
> feedback on these kinds of changes.
> >
> > https://bugreports.qt.io/browse/QTBUG-79454 was created to track this
> problem. So far the ideas suggested have been:
> >
> > - Run tests of dependent modules when testing a change, in addition to
> the regular tests for that module
> > - Merge repositories of more tightly coupled modules (e.g. move
> qtquickcontrols2 into qtdeclarative)
> >
> > It would be beneficial to discuss the advantages and disadvantages of
> these and other solutions so that we can address this problem.
> >
> > Cheers.
> 
> 
> Excellent topic for the upcoming Qt Contributors Summit, Mitch, great if you
> can add it to the list of topics:
> 
> https://wiki.qt.io/Qt_Contributors_Summit_2021_-_Program
> 
> Which doesn’t mean that we shouldn't start the discussion on the list, and
> maybe we can then conclude it at the summit.
> 
> 
> Cheers,
> Volker

OK, added it to the list.