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
