[Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

[Simon Hausmann]

Hi,

I scheduled a test build in the CI against 5.8 (as dev continues to be broken). The results are public at


http://testresults.qt.io/coin/integration/playground/qtremoteobjects/tasks/web_playground_qtremoteobjects_1484293648911

There are few issues:

1) namespaced build doesn't work
2) license check fails
3) tests run qmake infinitely on Windows.
4) winrt / msvc 2013 build broken



Simon
________________________________
From: Simon Hausmann
Sent: Jan 13, 2017 08:38
To: Lars Knoll; Stottlemyer, Brett (B.S.)
Cc: Qt development mailing list
Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9

Hi,

From a CI perspective nothing needs to be done.

From the Gerrit side the UI needs to be changed from submit to merge to staging. Gerrit admins can do that.

The module itself needs to support "make install" and be able to run tests against the installed version of the module.

By default the module will be built against the dev branch of qt5.git. If you use for example a 5.8 branch in qtro, then we'll use qt5 5.8. (there are more options, but this is the gist :)

There are a few modules outside of qt/ that are also CI controlled, it's a rather common thing.

Simon


________________________________
From: Lars Knoll
Sent: Jan 13, 2017 08:25
To: Stottlemyer, Brett (B.S.)
Cc: Qt development mailing list
Subject: Re: [Development] Switch Qt Remote Objects to a Tech Preview for Qt 5.9


Hi Brett,


> On 13 Jan 2017, at 02:58, Stottlemyer, Brett (B.S.) <bstottle at ford.com> wrote:
>
> On 12 January 2017 at 08:39, Lars Knoll wrote:
>
>> From the discussion so far I didn't hear too many things that speak against a TP, the code duplication with moc is one of the issues that fall into the 'flagged and need to be resolved before moving out of TP' category for me. How about the other
>> points in the list above that haven't been discussed yet here?
>
> Moving the points to below instead of above.  My opinion is (obviously) biased.
>
>> * The module solves a problem our users have
>> - It either implements new and so far non existent functionality
>> - Or it solves an existing problem in a new and better way (and is intended to replace the old functionality over time)
>
> It seems like the two potentially competing current projects are Qt Service Framework and QtDBus.  I believe QtRO is
> different from both, with “better” being subjective.  At the risk of being flamed for why I prefer QtRO, I’d put it
> this way:
>
> The Qt Service Framework deals with OS Services/daemons, and only works inter-process, not inter-device.  If I can
> distinguish between a service and a Service, Service being a different class than a program (I.e., on windows, services
> run when no user is logged on).  If you need a Service, the Service Framework makes sense.  This isn’t the problem
> QtRO is trying to solve.
>
> QtDBus is more similar in intent to QtRO.  QtRO is peer-to-peer, while Dbus by default goes through a daemon.  Bus is
> common on Linux platforms, but has additional dependencies on other platforms (Windows, QNX, etc).  The key difference
> though, is that DBus is intended to translate between languages (java, C, python).  This is a disadvantage of QtRO
> in many cases, but when Qt is available for both client/server, it provides a much richer level of communication.  For
> instance, QtRO supports QAIM, including selection, across processes/devices.  It supports state (current PROPERTY
> values).  It supports any type Qt can (or can be made to) pass in Queued connections.  Without additional code.
>
> My view is that QtRO complements the other two options, providing strong benefits for the right use-cases.

Agreed.
>
>> * The module builds inside the Qt build system on all platforms
>>   - Compilation could be disabled on some platforms, but is not allowed to break any platform we support
>> * The module is CI controlled
>
> Umm, this feels like a chicken and egg problem to me.  The Qt Company controls the CI, and it doesn’t run against play-
> ground projects.  We have worked with KDAB and implemented CI on 4 platforms, targeting only Qt 5.6.2 currently.  Until
> Qt’s CI is applied to it, there isn’t a clear way to evaluate build issues.  I’ve manually built against 5.8.0rc1 but
> not on all platforms.  I feel like there needs to be a way to enable Qt’s CI against QtRO before deciding whether to
> accept it as a TP project.  Can the Qt Company CI team help with this?  It is a playground project already hosted on
> qt.io.  If not, what options are there?

It should be pretty straightforward to enable CI on the module. Pre-conditions are mainly that it’s structured like the other Qt modules. Frederik & Simon what would it take to enable CI on it?
>
>> * There is a decent set of automated tests covering the main functionality and most of the API of the module
>> - The tests pass on all platforms where the module is supported
>> * APIs have been reviewed, and we are reasonably satisfied with them (we've done larger changes to APIs after TPs before)
>> * Architecture makes sense
>> * It follows the Qt coding style and conventions
>> * Implementation has been checked for sanity
>> - It's ok to have parts that are flagged as needing further work (those have to be fixed before moving from TP to supported state)
>
> For all of the above, it seems like you need someone other than the maintainer to assess whether it meets your requirements.
> I believe it does.  In terms of coding style, it meets the standards for 5.6.2.  We still need to apply the C++11 standards
> for 5.7+.  Also, I’m hoping (if approved) for a recommendation on how keep the Gerrit review history and align with Qt branching.

Agree, it needs a bit of review and of course it’s subjective on how strict one wants to be on the criteria. I don’t see it as a problem that it’s still using C++98, although at least the API should be reviewed to be making use of C++11 before it moves out of TP. I’ll try to have a look at the module over the weekend, and will see if I can find someone else to help.

Cheers,
Lars

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20170113/3ce4c548/attachment.html>