Next Gen CI Will Be Moving to Production Shortly: Upcoming Changes

[René J.V. Bertin]

On Saturday May 06 2017 22:01:58 Ben Cooksley wrote:
>On Sat, May 6, 2017 at 9:58 PM, René J.V. Bertin <rjvbertin at gmail.com> wrote:
>> On Saturday May 06 2017 21:37:51 Ben Cooksley wrote:
>>
>>>'Platforms' on which they build. At the moment we have three Platforms
>>>available: Ubuntu Xenial Qt 5.7, Windows Qt 5.7 and FreeBSD Qt 5.7.
>>>Adding additional Platforms to this mix is fairly easy, as long as the
>>>code can be built there. Qt will now be considered as part of the base
>>>system, and is something we will no longer build ourselves.
>>
>> One remark about this: Qt 5.7 is not the most issue-free version but I understand why the 5.6 LTS version was not preferred instead. However, there is 1 thing with using stock Qt that's potentially problematic on a CI. It lacks a QtDBus patch that Qt cannot at the moment incorporate but that everyone should be using because it prevents crashing on exit under certain conditions.
>
>It'll be up to the system distributor in that case to include the
>patch. We shouldn't be including patches the system distributor isn't
>in any case, as that will lead to a different environment compared to
>our users.

That works both ways. It's Qt's intention that distributions and "home builders" include the patch, so you can also adopt the position that a CI intended to find issues with KDE software shouldn't be vulnerable to issues in KDE dependencies that are not supposed to be present on user systems.
Note that I myself wouldn't really know which position to adopt... but I would probably avoid ambiguity and provide the dependencies with all known issues either explicitly fixed or explicitly NOT fixed (the latter being the easy solution). Depending on the decisions of a single "system distributor" chosen among the myriad of distributors (for Linux at least) seems ... problematic in this aspect.

>Note that for Windows and Mac we shouldn't be doing D-Bus anyway as
>they're alien to that platform

This is not exactly true and IMHO not a decision to be imposed by something like a CI. The DBus daemon includes support for both platforms and should be seen as a cross-platform desktop IPC solution which is also the only IPC interface Qt provides to my knowledge. Interdicting DBus use on Mac and MS Windows would make those platforms inaccessible to projects like KDEPIM. I don't think they'd appreciate that.
In fact, any application using KWallet will probably run into issues.

>(and the CI Tooling won't launch D-Bus
>as part of it's test environment setup there as a result)

The QtDBus issue itself does *not* depend on whether a DBus daemon is running or not, it's purely internal to Qt.

R.