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.) <bstot...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
