Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)
On 13 May 2014 14:17, Kurt Pattyn pattyn.k...@gmail.com wrote: On 13 May 2014, at 08:01, Knoll Lars lars.kn...@digia.com wrote: On 12/05/14 22:40, Thiago Macieira thiago.macie...@intel.com wrote: Em seg 12 maio 2014, às 19:35:24, Oswald Buddenhagen escreveu: On Mon, May 12, 2014 at 08:39:37AM -0700, Thiago Macieira wrote: Em seg 12 maio 2014, às 11:48:21, Ulf Hermann escreveu: The following changes create a debugsupport module with public API in qtbase: Please create a new module. This doesn't need to be in qtbase. given that the two quick implementations will depend on it, it makes little sense to split it out, given what else is in qtbase. Neither implementation is in qtbase, so I don't see the logic in that argument. Yes, it *can* be in qtbase, but I don't see why it *should* be. I want to hear a reason of why it should. Yes, let’s not make qtbase even bigger if we can avoid it. It’s hard enough to work with as it is. In that light: QtXml is there for historical reasons: there was code that needed it (including QtDBus). It can probably be moved out now. QtOpenGL and QtConcurrent are also historical and can probably be moved out too. Especially since those three aren't getting almost any updates, it makes sense to do it. QtDBus needs to stay because the XCB plugin needs it for some D-Bus protocols (notifications, the new systray protocol, etc.) The rest of the libraries in qtbase are really base stuff. Actually I was thinking about splitting a few more things out. In addition to the ones mentioned above, I believe we would benefit from splitting QtNetwork out into it’s own module. The reason is that QtNetwork is responsible for many of the failing CI runs due to the inherent instability on the network tests. Splitting out the module should help make many of the qtbase integrations go more smoothly. This makes sense. Maybe the WebSockets module can be integrated into the network module in that case? I would also propose to move some code into qtbase: e.g. the matrix classes that are now in QtGui. Cheers, Kurt The term module has multiple meanings in the discussion. 1) Qt module (e.g. Qt Core, Qt GUI, Qt WebSockets) 2) Git submodule (e.g. qtbase.git, qtwebsockets.git) There is a one-to-one relationship between Qt modules and compiled libraries: * Qt Core - Qt5Core.dll * Qt GUI - Qt5Gui.dll * Qt WebSockets - Qt5WebSockets.dll However, Git submodules can contain multiple Qt modules. For example, qtbase.git contains Qt Core, Qt GUI, etc. (so the matrix classes in Qt GUI are already in qtbase.git ;-) ) See http://qt-project.org/wiki/Qt_5_Structure for a full list -- it needs updating, but should be helpful. Note: There is no Qt module called Qt Base. When Thiago said Please create a new module, he meant Please create a new Git submodule. Qt modules can safely be moved between Git submodules, but classes cannot be moved between Qt modules because that will break binary compatibility. That means Qt WebSockets cannot be merged with Qt Network, and the matrix classes cannot be moved out of Qt GUI, until Qt 6. (If I remember correctly, QXmlStreamReader/Writer were successfully moved from Qt XML to Qt Core in Qt 4.4, but it was messy) To add to the confusion, there's also a third meaning for module in Qt: 3) QML module (e.g. QtQuick, QtQuick.Particles, QtAudioEngine) * The QtQuick QML module is associated with the Qt Quick Qt module * The QtQuick.Particles QML module is associated with the Qt Quick Qt module * The QtAudioEngine QML module is associated with the Qt Multimedia Qt module Note: There is no Qt module called Qt Audio Engine. Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)
On Thu, May 15, 2014 at 07:09:26PM +0800, Sze Howe Koh wrote: The term module has multiple meanings in the discussion. 1) Qt module (e.g. Qt Core, Qt GUI, Qt WebSockets) 2) Git submodule (e.g. qtbase.git, qtwebsockets.git) we refer to them as repositories (as implied by the wiki page you linked). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)
On 13/05/2014 16:47, Thiago Macieira wrote: Em ter 13 maio 2014, às 09:57:59, Knoll Lars escreveu: That won't help unless we also disable the revdep for QtQuick, as QtQuick depends on QtNetwork. That doesn’t mean we need to run the network tests as a revdep as well. Then the problem is simply of running the network tests. The CI could be smart and decide that it doesn't need to run tests/auto/network if src/network wasn't modified. I don't think that this is a good idea. Changes in QtCore which break something in network wouldn't cause a CI error and test failures would only surface as soon as a change to network is made. Isn't that one of the situations we want to avoid? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)
On Wednesday 14 of May 2014 08:01:33 Oliver Wolff wrote: On 13/05/2014 16:47, Thiago Macieira wrote: Em ter 13 maio 2014, às 09:57:59, Knoll Lars escreveu: That won't help unless we also disable the revdep for QtQuick, as QtQuick depends on QtNetwork. That doesn’t mean we need to run the network tests as a revdep as well. Then the problem is simply of running the network tests. The CI could be smart and decide that it doesn't need to run tests/auto/network if src/network wasn't modified. I don't think that this is a good idea. Changes in QtCore which break something in network wouldn't cause a CI error and test failures would only surface as soon as a change to network is made. Isn't that one of the situations we want to avoid? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Hi, As far I know the plan was to have a full Qt5 build and test cycle per day. So no, brokenness would be detected much earlier. Btw. the same argumentation could be used for every other module. In my opinion it is fine to break intermodule dependencies from time to time, assuming that we can detect and recover quickly. Cheers, Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Modules in qtbase (was: Re: new debugsupport module and API)
On 12/05/14 22:40, Thiago Macieira thiago.macie...@intel.com wrote: Em seg 12 maio 2014, às 19:35:24, Oswald Buddenhagen escreveu: On Mon, May 12, 2014 at 08:39:37AM -0700, Thiago Macieira wrote: Em seg 12 maio 2014, às 11:48:21, Ulf Hermann escreveu: The following changes create a debugsupport module with public API in qtbase: Please create a new module. This doesn't need to be in qtbase. given that the two quick implementations will depend on it, it makes little sense to split it out, given what else is in qtbase. Neither implementation is in qtbase, so I don't see the logic in that argument. Yes, it *can* be in qtbase, but I don't see why it *should* be. I want to hear a reason of why it should. Yes, let’s not make qtbase even bigger if we can avoid it. It’s hard enough to work with as it is. In that light: QtXml is there for historical reasons: there was code that needed it (including QtDBus). It can probably be moved out now. QtOpenGL and QtConcurrent are also historical and can probably be moved out too. Especially since those three aren't getting almost any updates, it makes sense to do it. QtDBus needs to stay because the XCB plugin needs it for some D-Bus protocols (notifications, the new systray protocol, etc.) The rest of the libraries in qtbase are really base stuff. Actually I was thinking about splitting a few more things out. In addition to the ones mentioned above, I believe we would benefit from splitting QtNetwork out into it’s own module. The reason is that QtNetwork is responsible for many of the failing CI runs due to the inherent instability on the network tests. Splitting out the module should help make many of the qtbase integrations go more smoothly. From what I can see nothing else in qtbase (apart from the bearer plugins) depends on qtnetwork, so a split should be possible. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)
On 13 May 2014, at 08:01, Knoll Lars lars.kn...@digia.com wrote: On 12/05/14 22:40, Thiago Macieira thiago.macie...@intel.com wrote: Em seg 12 maio 2014, às 19:35:24, Oswald Buddenhagen escreveu: On Mon, May 12, 2014 at 08:39:37AM -0700, Thiago Macieira wrote: Em seg 12 maio 2014, às 11:48:21, Ulf Hermann escreveu: The following changes create a debugsupport module with public API in qtbase: Please create a new module. This doesn't need to be in qtbase. given that the two quick implementations will depend on it, it makes little sense to split it out, given what else is in qtbase. Neither implementation is in qtbase, so I don't see the logic in that argument. Yes, it *can* be in qtbase, but I don't see why it *should* be. I want to hear a reason of why it should. Yes, let’s not make qtbase even bigger if we can avoid it. It’s hard enough to work with as it is. In that light: QtXml is there for historical reasons: there was code that needed it (including QtDBus). It can probably be moved out now. QtOpenGL and QtConcurrent are also historical and can probably be moved out too. Especially since those three aren't getting almost any updates, it makes sense to do it. QtDBus needs to stay because the XCB plugin needs it for some D-Bus protocols (notifications, the new systray protocol, etc.) The rest of the libraries in qtbase are really base stuff. Actually I was thinking about splitting a few more things out. In addition to the ones mentioned above, I believe we would benefit from splitting QtNetwork out into it’s own module. The reason is that QtNetwork is responsible for many of the failing CI runs due to the inherent instability on the network tests. Splitting out the module should help make many of the qtbase integrations go more smoothly. This makes sense. Maybe the WebSockets module can be integrated into the network module in that case? I would also propose to move some code into qtbase: e.g. the matrix classes that are now in QtGui. Cheers, Kurt From what I can see nothing else in qtbase (apart from the bearer plugins) depends on qtnetwork, so a split should be possible. 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
Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)
The rest of the libraries in qtbase are really base stuff. Actually I was thinking about splitting a few more things out. In addition to the ones mentioned above, I believe we would benefit from splitting QtNetwork out into it’s own module. The reason is that QtNetwork is responsible for many of the failing CI runs due to the inherent instability on the network tests. Splitting out the module should help make many of the qtbase integrations go more smoothly. From what I can see nothing else in qtbase (apart from the bearer plugins) depends on qtnetwork, so a split should be possible. What about modules depending on qtbase in general? We have had quite many case where a change in qtbase caused e.g. qtdeclarative to not work anymore and CI for those modules are blocked then. Unfortunately the delay until developers recognized that can easily cause 1-2 days of delay. Splitting qtbase might increase this case, either for qtnetwork integration misbehaving after changes in qtbase, but also for modules depending on qtnetwork. Comparing those two situations, do you think it's a better trade for moving network out? Maurice ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)
On 13/05/14 08:23, Kalinowski Maurice maurice.kalinow...@digia.com wrote: The rest of the libraries in qtbase are really base stuff. Actually I was thinking about splitting a few more things out. In addition to the ones mentioned above, I believe we would benefit from splitting QtNetwork out into it’s own module. The reason is that QtNetwork is responsible for many of the failing CI runs due to the inherent instability on the network tests. Splitting out the module should help make many of the qtbase integrations go more smoothly. From what I can see nothing else in qtbase (apart from the bearer plugins) depends on qtnetwork, so a split should be possible. What about modules depending on qtbase in general? We have had quite many case where a change in qtbase caused e.g. qtdeclarative to not work anymore and CI for those modules are blocked then. Unfortunately the delay until developers recognized that can easily cause 1-2 days of delay. Splitting qtbase might increase this case, either for qtnetwork integration misbehaving after changes in qtbase, but also for modules depending on qtnetwork. Comparing those two situations, do you think it's a better trade for moving network out? Yes, we had a few cases like that, esp. with declarative as it depends on some internals in QtCore/Gui. But these breakages have started to happen less often, so I’m less worried about them now than I used to be. IMO qtbase is a bit too large now as it is. We often have too many changes being staged at the same time, and CI runs failing because of this making it hard to get things into qtbase. So helping qtbase CI runs will IMO make things more productive overall. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)
Em ter 13 maio 2014, às 06:01:00, Knoll Lars escreveu: Actually I was thinking about splitting a few more things out. In addition to the ones mentioned above, I believe we would benefit from splitting QtNetwork out into it’s own module. The reason is that QtNetwork is responsible for many of the failing CI runs due to the inherent instability on the network tests. Splitting out the module should help make many of the qtbase integrations go more smoothly. From what I can see nothing else in qtbase (apart from the bearer plugins) depends on qtnetwork, so a split should be possible. That won't help unless we also disable the revdep for QtQuick, as QtQuick depends on QtNetwork. We definitely need the QtNetwork tests rerun every time a change in QIODevice is made (3 of the 6 classes deriving from it are in QtNetwork), but that could be managed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)
Actually the different the difference between qtdeclarative and qtbase is already producing enough overhead. For example bisect is hard to impossible which I need to do often to find out smart changes. What about to break the 1:1 relationship between CI modules and repositories. Why not have more than one CI module for qtbase? Best, Marco ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)
On 13/05/14 08:57, Thiago Macieira thiago.macie...@intel.com wrote: Em ter 13 maio 2014, às 06:01:00, Knoll Lars escreveu: Actually I was thinking about splitting a few more things out. In addition to the ones mentioned above, I believe we would benefit from splitting QtNetwork out into it’s own module. The reason is that QtNetwork is responsible for many of the failing CI runs due to the inherent instability on the network tests. Splitting out the module should help make many of the qtbase integrations go more smoothly. From what I can see nothing else in qtbase (apart from the bearer plugins) depends on qtnetwork, so a split should be possible. That won't help unless we also disable the revdep for QtQuick, as QtQuick depends on QtNetwork. That doesn’t mean we need to run the network tests as a revdep as well. We definitely need the QtNetwork tests rerun every time a change in QIODevice is made (3 of the 6 classes deriving from it are in QtNetwork), but that could be managed. I don’t see that as a big problem. How often do we change QIODevice in practice? It’s a couple of times per year. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)
On 13/05/14 11:49, Bubke Marco marco.bu...@digia.com wrote: Actually the different the difference between qtdeclarative and qtbase is already producing enough overhead. For example bisect is hard to impossible which I need to do often to find out smart changes. I very much disagree. The changes and refactorings we did to declarative over the last year would IMO have been a lot harder to do with a monolithic repository. Bisecting qtdeclarative works usually well on the latest qtbase, and bisecting qtbase can be done independent of qtdeclarative. It’s only in the relatively rare case that a qtbase change caused a break in declarative that this is an issue. I believe that’s worth the trade off. What about to break the 1:1 relationship between CI modules and repositories. Why not have more than one CI module for qtbase? How do you imagine that should that work in practice? Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)
On Tue, May 13, 2014 at 06:01:00AM +, Knoll Lars wrote: Actually I was thinking about splitting a few more things out. In addition to the ones mentioned above, I believe we would benefit from splitting QtNetwork out into it’s own module. The reason is that QtNetwork is responsible for many of the failing CI runs due to the inherent instability on the network tests. Splitting out the module should help make many of the qtbase integrations go more smoothly. well, who has not thought about it ... anyway, as others pointed out, cutting down the implicit revdeps resulting from the modules being lumped together will certainly increase the problems further down the line. the root cause of that is obviously our rather poor test coverage. in fact, when i was serving as the gerrit staging monkey a few weeks ago, i found that only a marginal number of fixes actually does come with an autotest. what's more, i observed that the external regulars are on average actually more careful about that than digians. whoopsie. i proposed a concept for addressing the integration unreliability months ago here, and it was accepted by the ci team. it just needs to be implemented ... until then, i suggest we keep the status quo to not risk messing things up even more. what's become of the new network test server, anyway? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)
On 05/13/2014 12:19 PM, Oswald Buddenhagen wrote: what's become of the new network test server, anyway? IIRC there is one test failure showing on the new image, but not on the old one (see my mail some months ago: https://www.mail-archive.com/development@qt-project.org/msg14730.html). Once that is fixed, we can try to deploy the new image and see whether it is more stable. But since I cannot reproduce the problem locally, it is hard to fix the issue from outside the Digia intranet; if there was a way for me to access that environment looking into the issue would be more promising... Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)
From: Knoll Lars On 13/05/14 11:49, Bubke Marco marco.bu...@digia.com wrote: Actually the different the difference between qtdeclarative and qtbase is already producing enough overhead. For example bisect is hard to impossible which I need to do often to find out smart changes. I very much disagree. The changes and refactorings we did to declarative over the last year would IMO have been a lot harder to do with a monolithic repository. I don't say that it is easier if you work in the modules. I do say that it is harder if you work outside. For example we use now in the designer Qml and the controls heavily and many bugs popping up. Normally I would use bisect to find out the change but because it is so time consuming I simply ignore them. Bisecting qtdeclarative works usually well on the latest qtbase, and bisecting qtbase can be done independent of qtdeclarative. It’s only in the relatively rare case that a qtbase change caused a break in declarative that this is an issue. I believe that’s worth the trade off. You see from your perspective it is easier from my it is harder. What about to break the 1:1 relationship between CI modules and repositories. Why not have more than one CI module for qtbase? How do you imagine that should that work in practice? If you change a file in a module you get through that CI system. You should add other CI modules if you think your change could triggering bugs there. E.g. you change network code. Then the network CI should run, maybe the CI for declarative-network and web-network too. So the CI modules should be smaller so less unaffected code would be tested. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)
Em ter 13 maio 2014, às 09:57:59, Knoll Lars escreveu: That won't help unless we also disable the revdep for QtQuick, as QtQuick depends on QtNetwork. That doesn’t mean we need to run the network tests as a revdep as well. Then the problem is simply of running the network tests. The CI could be smart and decide that it doesn't need to run tests/auto/network if src/network wasn't modified. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modules in qtbase (was: Re: new debugsupport module and API)
Tirsdag 13. mai 2014 06.23.46 skrev Kalinowski Maurice: The rest of the libraries in qtbase are really base stuff. Actually I was thinking about splitting a few more things out. In addition to the ones mentioned above, I believe we would benefit from splitting QtNetwork out into it’s own module. The reason is that QtNetwork is responsible for many of the failing CI runs due to the inherent instability on the network tests. Splitting out the module should help make many of the qtbase integrations go more smoothly. From what I can see nothing else in qtbase (apart from the bearer plugins) depends on qtnetwork, so a split should be possible. What about modules depending on qtbase in general? We have had quite many case where a change in qtbase caused e.g. qtdeclarative to not work anymore and CI for those modules are blocked then. Unfortunately the delay until developers recognized that can easily cause 1-2 days of delay. Splitting qtbase might increase this case, either for qtnetwork integration misbehaving after changes in qtbase, but also for modules depending on qtnetwork. Comparing those two situations, do you think it's a better trade for moving network out? I think the problem of dependent modules should be solved in a different way. I've been pushing for quite a while to have nightly builds of all modules in the CI so we'll get notified when something breaks. So imho the problem is that we don't build some of the modules until they get a patch or there's going to be a release. Hopefully this will be changed really soon now... the last blocker seems actually just the publishing of the results, everything else is in place. Cheers, Frederik Maurice ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Best regards, Frederik Gladhorn Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
