From jani.heikkinen at qt.io Mon Oct 1 12:06:07 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 1 Oct 2018 10:06:07 +0000 Subject: [Development] Maintainers, your action needed: Please check if 3rd party components needs to be updated for Qt 5.9.7 release In-Reply-To: References: Message-ID: Hi all, And here is task to track the progress: https://bugreports.qt.io/browse/QTBUG-70851 Please pick your own subtask, do needed actions and close the task when all done br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Friday, September 28, 2018 7:19 AM To: development at qt-project.org Subject: [Development] Maintainers, your action needed: Please check if 3rd party components needs to be updated for Qt 5.9.7 release Hi! Please check if some 3rd party component needs to be updated for Qt 5.9.7 release. And of course do needed updates now... List of 3rd party components here: http://doc.qt.io/qt-5.9/licenses-used-in-qt.html br, Jani Heikkinen Release Manager _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Mon Oct 1 14:09:16 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 1 Oct 2018 12:09:16 +0000 Subject: [Development] Maintainers, your action needed: Please check if 3rd party components needs to be updated for Qt 5.9.7 release In-Reply-To: References: , Message-ID: Hi, There seems to be some unclarity and internal discussion ongoing related to this; maybe the wording is a bit misleading in tasks. For the future releases I'll create new template for these requests and try to do better description :D But the target is that every maintainer checks if some 3rd party module has some critical updates and so on needs to be updated for the release. Of course we shouldn't do blind update & risk the release just because there is newer version; At this point of release we should just do the update if there is something really critical fixed in newer version. So it is maintainers responsibility to do the check and make the decision. And that is tracked with https://bugreports.qt.io/browse/QTBUG-70851. So please remember to close the task when checked and needed updates are done; tasks are in release blocker list so we need to close those before we can proceed with release br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Monday, October 1, 2018 1:06 PM To: development at qt-project.org Subject: Re: [Development] Maintainers, your action needed: Please check if 3rd party components needs to be updated for Qt 5.9.7 release Hi all, And here is task to track the progress: https://bugreports.qt.io/browse/QTBUG-70851 Please pick your own subtask, do needed actions and close the task when all done br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Friday, September 28, 2018 7:19 AM To: development at qt-project.org Subject: [Development] Maintainers, your action needed: Please check if 3rd party components needs to be updated for Qt 5.9.7 release Hi! Please check if some 3rd party component needs to be updated for Qt 5.9.7 release. And of course do needed updates now... List of 3rd party components here: http://doc.qt.io/qt-5.9/licenses-used-in-qt.html br, Jani Heikkinen Release Manager _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From tuukka.turunen at qt.io Mon Oct 1 15:20:08 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Mon, 1 Oct 2018 13:20:08 +0000 Subject: [Development] [Qt-creator] Requesting repos for Connected Creator plugin and telemetry library In-Reply-To: <6190021538145200@sas1-d856b3d759c7.qloud-c.yandex.net> References: <528931535643614@sas2-9bd6ba081e5d.qloud-c.yandex.net> <12314971.sNREKuh6E9@frederik-thinkcentre-m93p> <2599883.AIrgZEfeeU@frederik-thinkcentre-m93p> <6190021538145200@sas1-d856b3d759c7.qloud-c.yandex.net> Message-ID: <7F5643C4-F289-46C0-95A6-1CAAB938C6B5@qt.io> Thanks, Aleksey. Posting this to development mailing list as well. Yours, Tuukka On 28/09/2018, 16.33, "Qt-creator on behalf of Aleksey Kontsevich" wrote: Thanks all for the repos. Now initial library and plugin commits are on review for both projects: - https://codereview.qt-project.org/#/c/240347/ - https://codereview.qt-project.org/#/c/240361/ It is good if someone wants to review and approve those cause we need to move things forward and try to include our project into coming QtC 4.8 release. Thanks all again for participation! -- Best regards, Aleksey Linked in https://www.linkedin.com/in/alekseykontsevich 04.09.2018, 12:24, "Frederik Gladhorn" : > With much joy I created two repositories. > > qt-creator/plugin-telemetry > playground/telemetry > > They still need concise descriptions as the other repos have, please send them > to me. > > Cheers, > Frederik > > On fredag 31. august 2018 13.02.46 CEST Frederik Gladhorn wrote: >> On torsdag 30. august 2018 17.40.14 CEST Aleksey Kontsevich wrote: >> > You need 2 repos - clones of following: >> > https://github.com/akontsevich/ConnectedCreatorPlugin - the QtC plugin >> > https://github.com/akontsevich/QTelemetry - the library - QTelemetry name >> >> I'm not sure I want to clone the repos directly, how will reviews happen? >> Should there be a merge request? Is anyone interested in reviewing the whole >> stuff and how? >> >> Then most files I peaked into were lacking the license header and in the >> root directory I only found a LGPL license (I may be wrong, I didn't spend >> very long looking), so that's also not compatible with Qt license policy. >> >> So the question stands, how should the import/review happen? >> >> Cheers, >> Frederik >> >> > > On torsdag 30. august 2018 12.55.17 CEST Lars Knoll wrote: >> > >> Agreed. Frederik, could you help with creating the required repos? >> > > >> > > I can create the repos. How do you imagine importing the existing code, >> > > assuming that's the idea? >> > > Should this be a clone of the existing stuff or fresh repos where we >> > > start >> > > with a review of the existing code bases? >> > > >> > >> Connected Creator plugin: qt-cresator/plugin-connectedcreator >> > > >> > > I'd suggest: qt-creator/plugin-telemetry >> > > >> > >> Telemetry library: playground/telemetry >> > > >> > > If this is supposed to become an official Qt library at some point, it >> > > should probably be something like qttelemetry, but starting in >> > > playground >> > > would means it needs moving and renaming eventually in any case. The >> > > closer we can get to the final location, the better. >> > > >> > > Cheers, >> > > Frederik >> > > >> > >> Thanks, >> > >> Lars >> > >> >> > >> On 30 Aug 2018, at 12:50, Tuukka Turunen wrote: >> > >> >> > >> Hi, >> > >> >> > >> There were no objection to this, request. However, perhaps due to the >> > >> summertime the repos were not created. >> > >> Let’s make those now and move this code under the Qt project. >> > >> >> > >> Yours, >> > >> >> > >> Tuukka >> > >> >> > >> From: Qt-creator >> > >> >> > >> on behalf of >> > >> Tino Pyssysalo Date: Monday, 16 July 2018 at >> > >> 10.17 >> > >> >> > >> To: "qt-creator at qt-project.org" >> > >> Subject: [Qt-creator] Requesting repos for Connected Creator plugin >> > >> and >> > >> telemetry library >> > >> Hi all, >> > >> >> > >> In March this year, I requested a repo for an open source telemetry >> > >> >> > >> plugin >> > >> >> > >> for Qt Creator. Now, the plugin has been implemented and I’d like to >> > >> request two repos: · A repo for a Connected Creator plugin >> > >> · A playground repo for a telemetry library >> > >> >> > >> Description: The Qt Company wants to collect usage data from Qt >> > >> >> > >> development tools. For that purpose, we have developed a >> > >> general-purpose >> > >> telemetry library and a Qt Creator -specific plugin, using the >> > >> telemetry >> > >> library. The reason to collect the data from our users is to learn, how >> > >> developers use Qt Creator and other tools, how usage patterns change, >> > >> how quickly new features and versions are started to be used, which >> > >> tools are mostly used? This information is one data source, helping us >> > >> to make decisions, how to further develop our products. In the short >> > >> run, we believe we will get valuable information, how to improve the >> > >> user experience of our products. The connected creator plugin >> > >> implements >> > >> the frontend for tracking the data from different data sources in Qt >> > >> Creator. The frontend consists of a simple UI to enable/disable the >> > >> plugin, to set logs expiration period, and to view the data to be >> > >> transmitted or previously transmitted data (logs). Currently, the >> > >> plugin >> > >> tracks Qt Quick Designer usage only: launch count and usage time. >> > >> General platform data is collected by the telemetry library. This data >> > >> currently includes compiler details, locale, OpenGL type and version, >> > >> Qt >> > >> version, screen details, Qt Creator version, license type (evaluation, >> > >> commercial, no license), and unique id (generated with QUuid). >> > >> >> > >> All collected data is anonymous. No personal data such as project >> > >> names, >> > >> project locations and paths, IP or MAC addresses, email addresses or >> > >> Qt >> > >> Account details are collected. >> > >> The data is stored in the backend server, owned by The Qt Company. The >> > >> backend is complexly separated from the telemetry frontend and the >> > >> code >> > >> will be provided in The Qt Company >> > >> private repo: https://github.com/TheQtCompany/qt-telemetry-backend. >> > >> The collected data is cached into a settings file before the >> > >> >> > >> transmission. >> > >> >> > >> This allows the user to check, what data is going to be transmitted >> > >> and >> > >> even disable the plugin before any data is actually transmitted. In >> > >> addition, data caching allows calculating key values in the frontend >> > >> instead of sending each user event to the server separately. This >> > >> >> > >> reduces >> > >> >> > >> the network traffic significantly. By default, the cached data is >> > >> transmitted to the server once per week. It is possible to log the >> > >> transmitted data into the files to verify all the data transmitted to >> > >> >> > >> the >> > >> >> > >> server. >> > >> The plugin is planned to be completely opt-in. The online installer >> > >> will >> > >> >> > >> ask the user, if he/she wants to install the plugin. There is no >> > >> default >> > >> selection for the installation, but user must explicitly choose either >> > >> to install or not install the plugin. If the user decides to install >> > >> the >> > >> plugin, it can be disabled in Qt Creator settings. The user is able to >> > >> see the cached data and before the first transmission, the user can >> > >> disable the plugin, even though it has been installed. >> > >> >> > >> More implementation details can be found in Jira >> > >> ticket: https://bugreports.qt.io/browse/QTCREATORBUG-20250 >> > >> Existing repos: >> > >> Connected Creator >> > >> plugin: https://github.com/akontsevich/ConnectedCreatorPlugin >> > >> Telemetry >> > >> library: https://github.com/akontsevich/QTelemetry >> > >> >> > >> Responsible: Tino Pyssysalo >> > >> >> > >> Requested repos: >> > >> Connected Creator plugin: qt-cresator/plugin-connectedcreator >> > >> Telemetry library: playground/telemetry >> > >> >> > >> --- >> > >> Tino Pyssysalo >> > >> Senior Manager >> > >> Product Management >> > >> >> > >> The Qt Company >> > >> tino.pyssysalo at qt.io >> > >> http://qt.io >> > >> >> > >> The future is Written with Qt >> > >> --- >> > > >> > > _______________________________________________ >> > > Qt-creator mailing list >> > > Qt-creator at qt-project.org >> > > http://lists.qt-project.org/mailman/listinfo/qt-creator >> > >> > , >> > >> > _______________________________________________ >> > Qt-creator mailing list >> > Qt-creator at qt-project.org >> > http://lists.qt-project.org/mailman/listinfo/qt-creator >> > >> > -------- Конец пересылаемого сообщения -------- >> >> _______________________________________________ >> Qt-creator mailing list >> Qt-creator at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/qt-creator > > _______________________________________________ > Qt-creator mailing list > Qt-creator at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator _______________________________________________ Qt-creator mailing list Qt-creator at qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator From aha_1980 at gmx.de Tue Oct 2 10:37:24 2018 From: aha_1980 at gmx.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Tue, 2 Oct 2018 10:37:24 +0200 Subject: [Development] Requesting a wip/qt6 branch for QtSerialBus Message-ID: Hi all, I allready have some ideas for QCanBusDevice which requires binary-incompatible changes and therefore needs to be done for Qt6 [1]. To be able to already start the work, I'm hereby requesting a wip branch that could be merged when the "real" Qt6 development begins. The advantage would be, that others could already pick up that changes and test them, which hopefully will improve the code quality. Regards, André [1] https://bugreports.qt.io/browse/QTBUG-64145 From Oswald.Buddenhagen at qt.io Tue Oct 2 13:08:44 2018 From: Oswald.Buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 2 Oct 2018 11:08:44 +0000 Subject: [Development] Requesting a wip/qt6 branch for QtSerialBus In-Reply-To: References: Message-ID: <20181002110841.GC29262@troll08> On Tue, Oct 02, 2018 at 10:37:24AM +0200, André Hartmann wrote: > I allready have some ideas for QCanBusDevice which requires > binary-incompatible changes and therefore needs to be done for Qt6 [1]. > > To be able to already start the work, I'm hereby requesting a wip branch > that could be merged when the "real" Qt6 development begins. > > The advantage would be, that others could already pick up that changes > and test them, which hopefully will improve the code quality. > the more pragmatic approach is to "hide" the qt6 variant behind ifdefs. in fact, the introduction of a respective configure feature (so you would #if QT_CONFIG(qt6)) has been on the table for quite a while already, but nobody pushed for it yet, presumably because we haven't officially started qt6 yet. note that the qt(core) code is already full of QT_VERSION_CHECK(6,0,0) which does effectively the same, but to activate it you would need to change .qmake.conf instead of just calling configure -qt6. From jani.heikkinen at qt.io Tue Oct 2 13:42:26 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 2 Oct 2018 11:42:26 +0000 Subject: [Development] HEADS-UP: Branching from '5.9' to '5.9.7' complete In-Reply-To: References: Message-ID: Hi! Branching from '5.9' -> '5.9.7' is now ready. From now on all changes targeted to Qt 5.9.7 release must be done in '5.9.7' and '5.9' is for Qt 5.9.8. And as usual no any nice-to-have's in '5.9.7' anymore! br, Jani ________________________________________ From: Jani Heikkinen Sent: Monday, September 24, 2018 4:37 PM To: development at qt-project.org Cc: releasing at qt-project.org Subject: HEADS-UP: Branching from '5.9' to '5.9.7' started Hi all, We have soft branched '5.9.7' from '5.9' today. Final downmerge from '5.9' to '5.9.7' will happen Mon 1.10.2018. So there should be enough time to finalize ongoing changes in '5.9' and start using '5.9.7' for new changes targeted to Qt 5.9.7 release. Our target is to get Qt 5.9.7 release out as soon as possible. Hoping that can happen during week 41. br, Jani From bunjee at omega.gg Tue Oct 2 14:36:42 2018 From: bunjee at omega.gg (bunjee at omega.gg) Date: Tue, 02 Oct 2018 14:36:42 +0200 Subject: [Development] Windows, OpenGL ES and large textures Message-ID: Greeting Qt enthusiasts and ex-trolls, I'm building multimedia software on Windows with Qt + libVLC and recently switched to the OpenGL ES backend (setAttribute(Qt::AA_UseOpenGLES)). Coming from the Desktop OpenGL I immediately noticed how smooth it was at resizing windows, and it felt like the proper way to go. Unfortunately when playing a 1440p / 60fps video the CPU usage increases and the rendering gets slower, like way slower than classic OpenGL. Is there a flag or some configuration to alter OpenGL ES behavior with larger textures that update frequently ? Maybe I'm doing my texturing "wrongly", you can review my shader for blending images here: https://github.com/omega-gg/Sky/blob/master/src/SkMedia/src/media/WBackendVlc.cpp#L371 Many thanks, -- Benjamin Arnaud From alexander.blasche at qt.io Tue Oct 2 14:47:42 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Tue, 2 Oct 2018 12:47:42 +0000 Subject: [Development] MSVC 2017 32bit pre-built binaries for Qt 5.12 (replacing MSVC2015 32bit) Message-ID: Hi, We had this discussion for Qt 5.11 already but it is time to decide for Qt 5.12. The discussion details can be found under https://bugreports.qt.io/browse/QTBUG-63708 Based on download figures and dropped MSVC2015 support for webengine we plan to change MSVC2015 32bit binaries over to MSVC2017 32bit. I realize this will not be happy news for everybody but considering the LTS implications of Qt 5.12 it makes sense. Nevertheless if you believe you have strong counter arguments please comment on the issue in Jira. Thank you. -- Alex P.S. This does *not* mean that we drop 32bit for MSVC2015 support. We merely drop the pre-built binary offering in our installer. From svenn-arne.dragly at qt.io Tue Oct 2 17:01:06 2018 From: svenn-arne.dragly at qt.io (Svenn-Arne Dragly) Date: Tue, 2 Oct 2018 15:01:06 +0000 Subject: [Development] Qt 3D Maintainership In-Reply-To: References: <9055E382-6663-4E2E-8270-F89F397404B1@qt.io> Message-ID: Hi all, I'd also like to say a big thank you for all the work you have put into Qt 3D. It is a great graphics API and is getting better with each release. I would be more than happy to be a co-maintainer of Qt 3D Render and will also help out with Qt 3D Core and the other modules. I agree with Laszlo that it is a good idea to sync up on the future of Qt 3D and the Qt graphics stack. We need a clear vision of what the scope of Qt 3D should be and how we should handle existing and new features that fall both inside and outside of this scope. As we add support for more backends, we also need to decide on how much of the underlying graphics API, such as OpenGL flags, should be abstracted away. The transition to Qt 6 is a good opportunity to make some changes in this area. It will be great to have a unified 2D-3D engine that can run on top of the different graphics backends and be a flexible foundation for both Qt Quick's Scene Graph, Qt 3D Studio, and other modules like Qt Charts and Qt Data Visualization. Cheers, Svenn-Arne On 14. sep. 2018 15:52, Laszlo Agocs wrote: > Hi guys, > > Thanks, Qt 3D is almost certainly going to be an important piece in Qt 6. Once the dust settles and we have a clear view of the new maintainership structure, we should definitely sync up on the state of things and plan a bit ahead since there's plenty to be done and think about, especially with Qt 6 and its potentially unified 2D-3D engines in mind. (renderer optimizations, graphics API abstractions (RHI), shader graphs, some new features of course, ...., fun times ahead :) ) > > Cheers, > Laszlo > > -----Original Message----- > From: Development On Behalf Of Lars Knoll > Sent: fredag 14. september 2018 14.50 > To: Tuukka Turunen > Cc: Qt development mailing list ; Sean Harmer > Subject: Re: [Development] Qt 3D Maintainership > > Hi Sean, > > First of all thank you for all the great work on Qt 3D over the last years. Qt 3D has become a very important part of Qt, and I believe that parts of it will get a much more central role in our graphics stack when we move towards Qt 6. > > I’ve been discussing a bit with the graphics team in Oslo, and I think the idea of having Laszlo as a co-maintainer is good. I would also like to propose that we have Svenn-Arne as the co-maintainer for the renderer component. He’s been doing a lot of good work in that area over the last year. > > We’re also trying to find candidates to help with some of the other modules, and I hope we’ll at least one more person we can nominate there next week. > > Cheers, > Lars > > >> On 14 Sep 2018, at 12:47, Tuukka Turunen wrote: >> >> >> Hi Sean, >> >> Yes, Qt 3D certainly growing both in size and importance. Happily also the number of people working on it has been growing nicely. >> >> In addition to you and Paul, I believe we should be able to find 1-2 additional from developers of The Qt Company working on Qt 3D. >> >> Would it be possible to have someone from KDAB to maintain Qt 3D Extras? That is an area we have not touched that much. >> >> Yours, >> >> Tuukka >> >> On 14/09/2018, 13.29, "Development on behalf of Sean Harmer via Development" wrote: >> >> Hi All, >> >> my time available for Qt 3D outside of work, has as of late, been >> reduced due to increased family commitments - the good kind, but time >> consuming nonetheless. >> >> Given how Qt 3D has grown from our simple experiments in making 3D >> possible with Qt to the highly-configurable, multi-module, data >> processing monster it is today I feel it is no longer possible, nor >> wise, for me to maintain alone. Additionally, it looks as if Qt 3D will >> form an important piece of the graphics stack for Qt 6. >> >> As such I would like to propose that we split the maintainership and I >> would propose that Laszlo Agocs becomes co-maintainer. I am still happy >> to co-maintain and I have plenty of ideas about improvements we can make >> both within the Qt5 and Qt 6 time frames. We have learned a lot whilst >> developing Qt 3D and I think we can make it even better for Qt 6. >> >> I would also suggest that we find maintainers or co-maintainers for the >> sub-modules. I would propose Paul Lemire as (co-)maintainer for the >> render module. I'm happy to keep driving the animation module and help >> with qt3dcore. Other nominations are of course welcome. >> >> Kind regards and have a great weekend, >> >> Sean >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From aha_1980 at gmx.de Tue Oct 2 17:45:28 2018 From: aha_1980 at gmx.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Tue, 2 Oct 2018 17:45:28 +0200 Subject: [Development] Requesting a wip/qt6 branch for QtSerialBus In-Reply-To: <20181002110841.GC29262@troll08> References: <20181002110841.GC29262@troll08> Message-ID: Hi Oswald, > the more pragmatic approach is to "hide" the qt6 variant behind ifdefs. If that is the "official" way, fine with me. > note that the qt(core) code is already full of QT_VERSION_CHECK(6,0,0) > which does effectively the same, but to activate it you would need to > change .qmake.conf instead of just calling configure -qt6. Ok, I'll try this next time, seems like a sensible solution. I've also played a bit with the comment hjk gave me in [1] and it seems some of the changes can even be done for Qt5 - which is even better. I hereby declare that for now I don't need a wip branch, as enough other possiblities exist. Thanks for your time. Regards, André [1] https://bugreports.qt.io/browse/QTBUG-64145 Am 02.10.2018 um 13:08 schrieb Oswald Buddenhagen: > On Tue, Oct 02, 2018 at 10:37:24AM +0200, André Hartmann wrote: >> I allready have some ideas for QCanBusDevice which requires >> binary-incompatible changes and therefore needs to be done for Qt6 [1]. >> >> To be able to already start the work, I'm hereby requesting a wip branch >> that could be merged when the "real" Qt6 development begins. >> >> The advantage would be, that others could already pick up that changes >> and test them, which hopefully will improve the code quality. >> > the more pragmatic approach is to "hide" the qt6 variant behind ifdefs. > > in fact, the introduction of a respective configure feature (so you > would #if QT_CONFIG(qt6)) has been on the table for quite a while > already, but nobody pushed for it yet, presumably because we haven't > officially started qt6 yet. > > note that the qt(core) code is already full of QT_VERSION_CHECK(6,0,0) > which does effectively the same, but to activate it you would need to > change .qmake.conf instead of just calling configure -qt6. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From enmarantispam at gmail.com Tue Oct 2 19:41:34 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue, 2 Oct 2018 20:41:34 +0300 Subject: [Development] MSVC 2017 32bit pre-built binaries for Qt 5.12 (replacing MSVC2015 32bit) In-Reply-To: References: Message-ID: Wasn't it decided it was not the time to switch? Saying for myself - this will will likely see me not upgrade Qt distro until at least 6.0 once your suggested change hits.. On Tue, Oct 2, 2018 at 3:47 PM Alex Blasche wrote: > Hi, > > We had this discussion for Qt 5.11 already but it is time to decide for Qt > 5.12. The discussion details can be found under > > https://bugreports.qt.io/browse/QTBUG-63708 > > Based on download figures and dropped MSVC2015 support for webengine we > plan to change MSVC2015 32bit binaries over to MSVC2017 32bit. I realize > this will not be happy news for everybody but considering the LTS > implications of Qt 5.12 it makes sense. Nevertheless if you believe you > have strong counter arguments please comment on the issue in Jira. > > Thank you. > -- > Alex > > P.S. This does *not* mean that we drop 32bit for MSVC2015 support. We > merely drop the pre-built binary offering in our installer. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kde at carewolf.com Tue Oct 2 20:04:31 2018 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Tue, 02 Oct 2018 20:04:31 +0200 Subject: [Development] MSVC 2017 32bit pre-built binaries for Qt 5.12 (replacing MSVC2015 32bit) In-Reply-To: References: Message-ID: <14117845.ZdvQCiDvuY@twilight> On Dienstag, 2. Oktober 2018 14:47:42 CEST Alex Blasche wrote: > Hi, > > We had this discussion for Qt 5.11 already but it is time to decide for Qt > 5.12. The discussion details can be found under > > https://bugreports.qt.io/browse/QTBUG-63708 > > Based on download figures and dropped MSVC2015 support for webengine we plan > to change MSVC2015 32bit binaries over to MSVC2017 32bit. I realize this > will not be happy news for everybody but considering the LTS implications > of Qt 5.12 it makes sense. Nevertheless if you believe you have strong > counter arguments please comment on the issue in Jira. > Would it be possible to just replace 32bit MSVC2015 with 32bit MSVC2017 on the CIs that test the individual modules, but keep both for qt5.git if we have the resources for it? `Allan From tony.sarajarvi at qt.io Wed Oct 3 08:19:57 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Wed, 3 Oct 2018 06:19:57 +0000 Subject: [Development] MSVC 2017 32bit pre-built binaries for Qt 5.12 (replacing MSVC2015 32bit) In-Reply-To: <14117845.ZdvQCiDvuY@twilight> References: <14117845.ZdvQCiDvuY@twilight> Message-ID: We currently work like this in 5.12 For all submodule builds we do: MSVC 2015 x64 - a DeveloperBuild that isn't a DebugAndRelease build that's _not_ exported to release MSVC 2015 x86 - a DebugAndRelease build that's exported to release MSVC 2015 x64 - a DebugAndRelease build that's exported to release MSVC 2017 x64 - a DebugAndRelease build that's exported to release on top of that for every qt5.git build we do an additional MSVC 2017 x86 - a DebugAndRelease build that's _not_ exported to release So we actually build MSVC with both 2015 and 2017 for both x86 and x64. So it's just a matter of selecting which we want to export to release. -Tony -----Original Message----- From: Development On Behalf Of Allan Sandfeld Jensen Sent: tiistai 2. lokakuuta 2018 21.05 To: development at qt-project.org Subject: Re: [Development] MSVC 2017 32bit pre-built binaries for Qt 5.12 (replacing MSVC2015 32bit) On Dienstag, 2. Oktober 2018 14:47:42 CEST Alex Blasche wrote: > Hi, > > We had this discussion for Qt 5.11 already but it is time to decide > for Qt 5.12. The discussion details can be found under > > https://bugreports.qt.io/browse/QTBUG-63708 > > Based on download figures and dropped MSVC2015 support for webengine > we plan to change MSVC2015 32bit binaries over to MSVC2017 32bit. I > realize this will not be happy news for everybody but considering the > LTS implications of Qt 5.12 it makes sense. Nevertheless if you > believe you have strong counter arguments please comment on the issue in Jira. > Would it be possible to just replace 32bit MSVC2015 with 32bit MSVC2017 on the CIs that test the individual modules, but keep both for qt5.git if we have the resources for it? `Allan _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Wed Oct 3 11:04:42 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 3 Oct 2018 09:04:42 +0000 Subject: [Development] MSVC 2017 32bit pre-built binaries for Qt 5.12 (replacing MSVC2015 32bit) In-Reply-To: References: <14117845.ZdvQCiDvuY@twilight>, Message-ID: And we don't want to increase amount of released binary packages so that's why we will drop msvc2015 32 bit when we will start delivering msvc2017 32 bit ones br, Jani ________________________________________ From: Development on behalf of Tony Sarajärvi Sent: Wednesday, October 3, 2018 9:19 AM To: Allan Sandfeld Jensen; development at qt-project.org Subject: Re: [Development] MSVC 2017 32bit pre-built binaries for Qt 5.12 (replacing MSVC2015 32bit) We currently work like this in 5.12 For all submodule builds we do: MSVC 2015 x64 - a DeveloperBuild that isn't a DebugAndRelease build that's _not_ exported to release MSVC 2015 x86 - a DebugAndRelease build that's exported to release MSVC 2015 x64 - a DebugAndRelease build that's exported to release MSVC 2017 x64 - a DebugAndRelease build that's exported to release on top of that for every qt5.git build we do an additional MSVC 2017 x86 - a DebugAndRelease build that's _not_ exported to release So we actually build MSVC with both 2015 and 2017 for both x86 and x64. So it's just a matter of selecting which we want to export to release. -Tony -----Original Message----- From: Development On Behalf Of Allan Sandfeld Jensen Sent: tiistai 2. lokakuuta 2018 21.05 To: development at qt-project.org Subject: Re: [Development] MSVC 2017 32bit pre-built binaries for Qt 5.12 (replacing MSVC2015 32bit) On Dienstag, 2. Oktober 2018 14:47:42 CEST Alex Blasche wrote: > Hi, > > We had this discussion for Qt 5.11 already but it is time to decide > for Qt 5.12. The discussion details can be found under > > https://bugreports.qt.io/browse/QTBUG-63708 > > Based on download figures and dropped MSVC2015 support for webengine > we plan to change MSVC2015 32bit binaries over to MSVC2017 32bit. I > realize this will not be happy news for everybody but considering the > LTS implications of Qt 5.12 it makes sense. Nevertheless if you > believe you have strong counter arguments please comment on the issue in Jira. > Would it be possible to just replace 32bit MSVC2015 with 32bit MSVC2017 on the CIs that test the individual modules, but keep both for qt5.git if we have the resources for it? `Allan _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Wed Oct 3 11:58:27 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 3 Oct 2018 09:58:27 +0000 Subject: [Development] Maintainers, your action needed: Qt 5.9.7 changes files Message-ID: Hi, Initial ones here: https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.9.7%22,n,z Please take over & finalize if needed. And get approval as soon as possible br, Jani Heikkinen Release Manager From Frederik.Gladhorn at qt.io Wed Oct 3 16:52:16 2018 From: Frederik.Gladhorn at qt.io (Frederik Gladhorn) Date: Wed, 3 Oct 2018 14:52:16 +0000 Subject: [Development] Closing issues automatically with new keyword In-Reply-To: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> References: <1605403.ZOvVMTnn74@frederik-thinkcentre-m93p> Message-ID: <2103227.rpmBvmFqt5@frederik-thinkcentre-m93p> Hello again, After another round of fixing (such as allowing to close issues that are 'In Progress', because they have a different name for the transition), adding the setting of the commit sha1 and no longer setting too many versions, we should be live with a working bot. I'm interested in issues that you encounter. I just let the bot run through all historical commits to fix them up and add for example the missing sha1s. The rules are basically: - if there is a lower patch level already in the fix versions, nothing is added 5.12.1 is there: do not add 5.12.2 or 5.12.3 - if there is a .0 release that is earlier than the current release, nothing is added 5.12.0 is there: do not add 5.13.0 Cheers, Frederik From Shawn.Rutledge at qt.io Wed Oct 3 17:26:27 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Wed, 3 Oct 2018 15:26:27 +0000 Subject: [Development] Requesting a wip/qt6 branch for QtSerialBus In-Reply-To: <20181002110841.GC29262@troll08> References: <20181002110841.GC29262@troll08> Message-ID: > On 2 Oct 2018, at 13:08, Oswald Buddenhagen wrote: > > in fact, the introduction of a respective configure feature (so you > would #if QT_CONFIG(qt6)) has been on the table for quite a while > already, but nobody pushed for it yet, presumably because we haven't > officially started qt6 yet. Well I think it’s a good idea to do it ASAP. > note that the qt(core) code is already full of QT_VERSION_CHECK(6,0,0) > which does effectively the same, but to activate it you would need to > change .qmake.conf instead of just calling configure -qt6. I’ve written those once or twice but never actually tried to build that way. It would be good to really try a few things soon. (Some things will be a lot of work, so better not wait until there is a time crunch to get Qt 6 done within a few months.) A configure option sounds like the nicer way to do it, so that I can make a Qt6 shadow build of dev branch at any time. From thiago.macieira at intel.com Wed Oct 3 23:06:11 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 3 Oct 2018 14:06:11 -0700 Subject: [Development] Requesting a wip/qt6 branch for QtSerialBus In-Reply-To: References: <20181002110841.GC29262@troll08> Message-ID: <1577264.GA3YUeyern@tjmaciei-mobl1> On Wednesday, 3 October 2018 08:26:27 PDT Shawn Rutledge wrote: > > note that the qt(core) code is already full of QT_VERSION_CHECK(6,0,0) > > which does effectively the same, but to activate it you would need to > > change .qmake.conf instead of just calling configure -qt6. > > I’ve written those once or twice but never actually tried to build that way. > It would be good to really try a few things soon. (Some things will be a > lot of work, so better not wait until there is a time crunch to get Qt 6 > done within a few months.) A configure option sounds like the nicer way to > do it, so that I can make a Qt6 shadow build of dev branch at any time. A configure option that overrides the MODULE_VERSION variable from .qmake.conf should be easy. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Robert.Loehning at qt.io Thu Oct 4 14:15:11 2018 From: Robert.Loehning at qt.io (Robert Loehning) Date: Thu, 4 Oct 2018 12:15:11 +0000 Subject: [Development] bugreports.qt.io production update In-Reply-To: <20180913092106.6oeadxirufp7o446@saltation.com> References: <20180913091547.7pl6mgt4c4alvha3@saltation.com> <20180913092106.6oeadxirufp7o446@saltation.com> Message-ID: <703ee196-bc8b-68df-a86b-6b54f5825640@qt.io> Hi, is there a bugreport about this, already? Best Regards, Robert Am 13.09.2018 um 11:21 schrieb Nils Jeisecke via Development: > Hi, > > using the Jira login form does not work but the "Login" button (on top > right) does. > > Nils > > Am 13.09.2018 um 11:15 hat Nils Jeisecke via Development geschrieben: >> Hi Alex, >> >> Am 11.09.2018 um 06:32 hat Alex Blasche geschrieben: >>> The update was done and everything seems to work out. >>> >>> If there are any issues please report them to: >>> >>> https://bugreports.qt.io/projects/QTJIRA/summary >> My issue is: I cannot login. Until recently this used work with my >> Qt account credentials. >> >> Nils > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From nils.jeisecke at saltation.com Thu Oct 4 17:25:41 2018 From: nils.jeisecke at saltation.com (Nils Jeisecke) Date: Thu, 4 Oct 2018 17:25:41 +0200 Subject: [Development] bugreports.qt.io production update In-Reply-To: <703ee196-bc8b-68df-a86b-6b54f5825640@qt.io> References: <20180913091547.7pl6mgt4c4alvha3@saltation.com> <20180913092106.6oeadxirufp7o446@saltation.com> <703ee196-bc8b-68df-a86b-6b54f5825640@qt.io> Message-ID: <20181004152541.dzbc4g36hwtb32fb@saltation.com> Hi, Am 04.10.2018 um 12:15 hat Robert Loehning geschrieben: > is there a bugreport about this, already? https://bugreports.qt.io/browse/QTWEBSITE-830 Nils From nils.jeisecke at saltation.com Thu Oct 4 17:35:05 2018 From: nils.jeisecke at saltation.com (Nils Jeisecke) Date: Thu, 4 Oct 2018 17:35:05 +0200 Subject: [Development] Building Qt documentation with developer-build Message-ID: <20181004153504.svfcdcugrampzwqt@saltation.com> Hi, While trying improve the documentations to fix QTBUG-32064 I've stumbled over problems invoking qdoc. I'd like to use my developer-build to check the result of my changes but qdoc seems to have been skipped when building with --developer-build. "make docs" from within my shadow build directory fails: /Users/njeiseck/projects/qt/build/5.12.0-alpha1/qtbase/src/corelib/qdoc_wrapper.sh: line 12: /Users/njeiseck/projects/qt/build/5.12.0-alpha1/qtbase/bin/qdoc: No such file or directory /Users/njeiseck/projects/qt/build/5.12.0-alpha1/qtbase/src/corelib/qdoc_wrapper.sh: line 12: exec: /Users/njeiseck/projects/qt/build/5.12.0-alpha1/qtbase/bin/qdoc: cannot execute: No such file or directory make[6]: *** [prepare_docs] Error 126 make[5]: *** [debug-prepare_docs] Error 2 make[4]: *** [sub-corelib-prepare_docs] Error 2 make[3]: *** [sub-src-prepare_docs] Error 2 make[2]: *** [module-qtbase-prepare_docs] Error 2 make[1]: *** [html_docs] Error 2 make: *** [docs] Error 2 Seems that qdoc was not build at all. Building qdoc as described on https://wiki.qt.io/Building_Qt_Documentation does not work. I've not found any special qdoc configure options so what am I doing wrong? This is my configure line: ../../qt512/configure -developer-build -opensource -nomake examples -nomake tests -skip qtwebchannel -skip qtscript -skip qt3d -skip qtdatavis3d -skip qtremoteobjects -skip qtserialport -skip qtvirtualkeyboard -skip qtwebengine -opensource -confirm-license Any help is appreciated! Nils From mitch.curtis at qt.io Thu Oct 4 17:49:35 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Thu, 4 Oct 2018 15:49:35 +0000 Subject: [Development] Building Qt documentation with developer-build In-Reply-To: <20181004153504.svfcdcugrampzwqt@saltation.com> References: <20181004153504.svfcdcugrampzwqt@saltation.com> Message-ID: Did you set LLVM_INSTALL_DIR before building Qt? If you check the build log you should see an error message related to the failure to build qdoc. > Seems that qdoc was not build at all. Building qdoc as described on https://wiki.qt.io/Building_Qt_Documentation does not work. If you forgot LLVM_INSTALL_DIR and are trying to build qdoc separately rather than with the rest of Qt, you might run into https://bugreports.qt.io/browse/QTBUG-66366, in which case you’ll need to rebuild *all of Qt*, unfortunately. On 10/4/18, 5:35 PM, "Development on behalf of Nils Jeisecke via Development" wrote: Hi, While trying improve the documentations to fix QTBUG-32064 I've stumbled over problems invoking qdoc. I'd like to use my developer-build to check the result of my changes but qdoc seems to have been skipped when building with --developer-build. "make docs" from within my shadow build directory fails: /Users/njeiseck/projects/qt/build/5.12.0-alpha1/qtbase/src/corelib/qdoc_wrapper.sh: line 12: /Users/njeiseck/projects/qt/build/5.12.0-alpha1/qtbase/bin/qdoc: No such file or directory /Users/njeiseck/projects/qt/build/5.12.0-alpha1/qtbase/src/corelib/qdoc_wrapper.sh: line 12: exec: /Users/njeiseck/projects/qt/build/5.12.0-alpha1/qtbase/bin/qdoc: cannot execute: No such file or directory make[6]: *** [prepare_docs] Error 126 make[5]: *** [debug-prepare_docs] Error 2 make[4]: *** [sub-corelib-prepare_docs] Error 2 make[3]: *** [sub-src-prepare_docs] Error 2 make[2]: *** [module-qtbase-prepare_docs] Error 2 make[1]: *** [html_docs] Error 2 make: *** [docs] Error 2 Seems that qdoc was not build at all. Building qdoc as described on https://wiki.qt.io/Building_Qt_Documentation does not work. I've not found any special qdoc configure options so what am I doing wrong? This is my configure line: ../../qt512/configure -developer-build -opensource -nomake examples -nomake tests -skip qtwebchannel -skip qtscript -skip qt3d -skip qtdatavis3d -skip qtremoteobjects -skip qtserialport -skip qtvirtualkeyboard -skip qtwebengine -opensource -confirm-license Any help is appreciated! Nils _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Jaroslaw.Kobus at qt.io Fri Oct 5 07:46:08 2018 From: Jaroslaw.Kobus at qt.io (Jaroslaw Kobus) Date: Fri, 5 Oct 2018 05:46:08 +0000 Subject: [Development] Building Qt documentation with developer-build In-Reply-To: References: <20181004153504.svfcdcugrampzwqt@saltation.com>, Message-ID: Hi, You may also want to check the https://bugreports.qt.io/browse/QTBUG-65762 - if you think the issue is still not solved, you may reopen / report new bug report. Regards Jarek [QTBUG-65762] Compiling qdoc in dev is a big pain - Qt Bug ... bugreports.qt.io I've recently updated my dev branch of qt and I have big issues compiling qdoc. For the first machine I've learned (from a colleague) that I need libclang in order to compile it. ________________________________ From: Development on behalf of Mitch Curtis Sent: Thursday, October 4, 2018 5:49:35 PM To: Nils Jeisecke; development at qt-project.org Subject: Re: [Development] Building Qt documentation with developer-build Did you set LLVM_INSTALL_DIR before building Qt? If you check the build log you should see an error message related to the failure to build qdoc. > Seems that qdoc was not build at all. Building qdoc as described on https://wiki.qt.io/Building_Qt_Documentation does not work. If you forgot LLVM_INSTALL_DIR and are trying to build qdoc separately rather than with the rest of Qt, you might run into https://bugreports.qt.io/browse/QTBUG-66366, in which case you’ll need to rebuild *all of Qt*, unfortunately. On 10/4/18, 5:35 PM, "Development on behalf of Nils Jeisecke via Development" wrote: Hi, While trying improve the documentations to fix QTBUG-32064 I've stumbled over problems invoking qdoc. I'd like to use my developer-build to check the result of my changes but qdoc seems to have been skipped when building with --developer-build. "make docs" from within my shadow build directory fails: /Users/njeiseck/projects/qt/build/5.12.0-alpha1/qtbase/src/corelib/qdoc_wrapper.sh: line 12: /Users/njeiseck/projects/qt/build/5.12.0-alpha1/qtbase/bin/qdoc: No such file or directory /Users/njeiseck/projects/qt/build/5.12.0-alpha1/qtbase/src/corelib/qdoc_wrapper.sh: line 12: exec: /Users/njeiseck/projects/qt/build/5.12.0-alpha1/qtbase/bin/qdoc: cannot execute: No such file or directory make[6]: *** [prepare_docs] Error 126 make[5]: *** [debug-prepare_docs] Error 2 make[4]: *** [sub-corelib-prepare_docs] Error 2 make[3]: *** [sub-src-prepare_docs] Error 2 make[2]: *** [module-qtbase-prepare_docs] Error 2 make[1]: *** [html_docs] Error 2 make: *** [docs] Error 2 Seems that qdoc was not build at all. Building qdoc as described on https://wiki.qt.io/Building_Qt_Documentation does not work. I've not found any special qdoc configure options so what am I doing wrong? This is my configure line: ../../qt512/configure -developer-build -opensource -nomake examples -nomake tests -skip qtwebchannel -skip qtscript -skip qt3d -skip qtdatavis3d -skip qtremoteobjects -skip qtserialport -skip qtvirtualkeyboard -skip qtwebengine -opensource -confirm-license Any help is appreciated! Nils _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Fri Oct 5 11:19:44 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 5 Oct 2018 09:19:44 +0000 Subject: [Development] Qt 5.12 beta1 released In-Reply-To: References: Message-ID: Hi! We have released Qt 5.12 beta1 today, see http://blog.qt.io/blog/2018/10/05/qt-5-12-lts-beta-released/ You can find Qt 5.12 beta1 under 'Preview' node from Online installer. Please take a tour & start testing Qt 5.12 now. As earlier we will release new beta releases regularly until we are ready for final Qt 5.12 release. It is really important to recognize all blockers for the final release now so please make sure all release blockers can be found from RC blocker list (https://bugreports.qt.io/issues/?filter=19961). br Jani From Kai.Koehne at qt.io Fri Oct 5 11:24:39 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Fri, 5 Oct 2018 09:24:39 +0000 Subject: [Development] Dropping remaining support of qtquick1 Message-ID: Hi, Can we drop the last remaining traces of qtquick1 from qtbase? Remember that qtquick1 is not part of Qt anymore since Qt 5.6. Anyhow, some people might still compiled it compiled with later versions on their own ... Right now it doesn't compile for me with 5.12, but I haven't investigated why. The last remaining support for Qt Quick 1 are in the build system (qml1_module.prf, qml1_plugin.prf), QLibraryInfo::ImportsPath, qmake ($$QT_INSTALL_IMPORTS), and finally in QObject and QWidget (handling of QAbstractDeclarativeData::destroyed_qml1). We could remove these already in 5.12, in 5.13, or wait for Qt 6. I'd prefer 5.12 if nobody objects 😊 Regards Kai -- Kai Koehne, Senior Manager R&D | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B The Future is Written with Qt www.qtworldsummit.com From edward.welbourne at qt.io Fri Oct 5 13:25:05 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 5 Oct 2018 11:25:05 +0000 Subject: [Development] unified data model API in QtCore => thin wrapper proposal In-Reply-To: <2667897.cUWARcUy5E@tjmaciei-mobl1> References: <808C8A97-7108-439B-A008-83D5AA298296@qt.io>, <2667897.cUWARcUy5E@tjmaciei-mobl1> Message-ID: On Sunday, 9 September 2018 04:16:24 PDT Tor Arne Vestbø wrote: >> This is exactly the kind of stuff I brought up at the contributors >> summit. We should strive to at least be on par with QJson, but I’m >> hoping we can also have a nice API for writing (something QJson >> doesn’t easily facilitate). Any chance the read-only stuff can be >> added at least Thiago? Thiago Macieira (9 September 2018 18:36) wrote: > It can be, but we're already past feature freeze and I don't have time > to do it right now. I'm completely swamped at work and I'm dedicating > any free minutes I have for Qt to do code reviews for others. > > The issue with map["hello"] can be an API review issue, though. For the sake of openness (we took most of this discussion off-line), the end result of that was: 5.12: QCbor{Map,Array}::operator[] grow over-loads for string literals and all read-only variants return const QCborValue: https://codereview.qt-project.org/240046 QCborArray::operator[] and insert() allow indices past the end of the array, padding the array with invalid entries: https://codereview.qt-project.org/240537 dev (5.13): QCborValue{Ref,}::operator[] added where missing https://codereview.qt-project.org/240042 The first's const-ing and the second's padding are needed in 5.12 to let the last be backwards-compatible, when it lands. Once the first two land, we can finally close the qtbase API review. Eddy. From nils.jeisecke at saltation.com Fri Oct 5 14:17:12 2018 From: nils.jeisecke at saltation.com (Nils Jeisecke) Date: Fri, 5 Oct 2018 14:17:12 +0200 Subject: [Development] Building Qt documentation with developer-build In-Reply-To: References: <20181004153504.svfcdcugrampzwqt@saltation.com> Message-ID: <20181005121712.nqugigb4p2q7f3ql@saltation.com> Hi! Am 05.10.2018 um 05:46 hat Jaroslaw Kobus geschrieben: > You may also want to check the > https://bugreports.qt.io/browse/QTBUG-65762 - if you think the issue > is still not solved, you may reopen / report new bug report. After rebuilding Qt it works now. On macOS is is sufficient to install clang with brew. The qmake stuff looks at the brew default location with 5.12 so setting LLVM_INSTALL_DIR is not necessary. Thanks for your help! However building the documentation with "make docs" in one of the submodules is rather slow. Pretty annoying when you only want to check whether your changes look ok when compiled to HTML. Nils From mitch.curtis at qt.io Fri Oct 5 14:38:39 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Fri, 5 Oct 2018 12:38:39 +0000 Subject: [Development] Building Qt documentation with developer-build In-Reply-To: <20181005121712.nqugigb4p2q7f3ql@saltation.com> References: <20181004153504.svfcdcugrampzwqt@saltation.com> <20181005121712.nqugigb4p2q7f3ql@saltation.com> Message-ID: > -----Original Message----- > From: Nils Jeisecke > Sent: Friday, 5 October 2018 2:17 PM > To: Jaroslaw Kobus > Cc: Mitch Curtis ; development at qt-project.org > Subject: Re: [Development] Building Qt documentation with developer-build > > Hi! > > Am 05.10.2018 um 05:46 hat Jaroslaw Kobus geschrieben: > > You may also want to check the > > https://bugreports.qt.io/browse/QTBUG-65762 - if you think the issue > > is still not solved, you may reopen / report new bug report. > > After rebuilding Qt it works now. On macOS is is sufficient to install clang with > brew. The qmake stuff looks at the brew default location with > 5.12 so setting LLVM_INSTALL_DIR is not necessary. > > Thanks for your help! > > However building the documentation with "make docs" in one of the > submodules is rather slow. Pretty annoying when you only want to check > whether your changes look ok when compiled to HTML. Yeah, it is. One kinda small speed-up can be made by only running make html_docs in a specific folder, such as src/qml if you're editing QML docs, rather than doing it in the top level qtdeclarative directory and building both QML and Qt Quick docs. > Nils From thiago.macieira at intel.com Fri Oct 5 17:28:08 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 5 Oct 2018 08:28:08 -0700 Subject: [Development] Dropping remaining support of qtquick1 In-Reply-To: References: Message-ID: <2782043.OPD08NQSv6@tjmaciei-mobl1> On Friday, 5 October 2018 02:24:39 PDT Kai Koehne wrote: > The last remaining support for Qt Quick 1 are in the build system > (qml1_module.prf, qml1_plugin.prf), QLibraryInfo::ImportsPath, qmake > ($$QT_INSTALL_IMPORTS), and finally in QObject and QWidget (handling of > QAbstractDeclarativeData::destroyed_qml1). > > We could remove these already in 5.12, in 5.13, or wait for Qt 6. I'd prefer > 5.12 if nobody objects I don't think we should. qtquick1 may not be as dead as we'd like it to be. I'd rather keep the QtCore API just in case someone is keeping the old module working for their applications (or Linux distribution, though I can't find any). They may also be (ab)using QLibraryInfo::ImportsPath for some other purpose. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Oct 5 17:35:10 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 5 Oct 2018 08:35:10 -0700 Subject: [Development] unified data model API in QtCore => thin wrapper proposal In-Reply-To: References: <2667897.cUWARcUy5E@tjmaciei-mobl1> Message-ID: <2220296.uft7SWZhur@tjmaciei-mobl1> On Friday, 5 October 2018 04:25:05 PDT Edward Welbourne wrote: > dev (5.13): > QCborValue{Ref,}::operator[] added where missing > https://codereview.qt-project.org/240042 > > The first's const-ing and the second's padding are needed in 5.12 to let > the last be backwards-compatible, when it lands. Once the first two land, > we can finally close the qtbase API review. May as well bring this question to the list as a whole now: QCborValue, Array and Map have methods like: const QCborValue operator[](qint64 index) const; We're trying to figure out if the returned type should be const. Pros: 1) once QCborValue can be modified by the APi above, you can't accidentally use it in a const object 2) you can't write array[n] = newValue; Cons: Suppresses move construction as in QCborValue v = array[n]; this still compiles, but passes through the copy constructor, not the move one. We cana add an extra move constructor for const QCborValue && if necessary. Eddy: what happens in the new API if you write: const QCborArray array = { QCborArray{ 1 } }; QCborValue v = array[0]; v[0] = 2; Does that modify array? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From edward.welbourne at qt.io Fri Oct 5 18:26:45 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 5 Oct 2018 16:26:45 +0000 Subject: [Development] unified data model API in QtCore => thin wrapper proposal In-Reply-To: <2220296.uft7SWZhur@tjmaciei-mobl1> References: <2667897.cUWARcUy5E@tjmaciei-mobl1> , <2220296.uft7SWZhur@tjmaciei-mobl1> Message-ID: Thiago Macieira (5 October 2018 17:35) asked me: > Eddy: what happens in the new API if you write: > const QCborArray array = { QCborArray{ 1 } }; > QCborValue v = array[0]; > v[0] = 2; > > Does that modify array? No. It should only modify what v[0] reports, or a v.toArray()[0] reports, after the assignment. My addition to the end of tst_QCborValue::arrayDefaultInitialization() verifies exactly this with the QVERIFY(a2.isEmpty()); that it adds, after such an assignment. Eddy. From enmarantispam at gmail.com Fri Oct 5 18:30:28 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Fri, 5 Oct 2018 19:30:28 +0300 Subject: [Development] Dropping remaining support of qtquick1 In-Reply-To: <2782043.OPD08NQSv6@tjmaciei-mobl1> References: <2782043.OPD08NQSv6@tjmaciei-mobl1> Message-ID: I would like to remind people that there has already been a deprecation thread "[Development] Deprecation of Qt Quick Controls 1" byFrederik Gladhorn this Februrary. A couple issues were raised there that were rather relevant and I would like to know if they were ever addressed. On Fri, Oct 5, 2018 at 6:29 PM Thiago Macieira wrote: > On Friday, 5 October 2018 02:24:39 PDT Kai Koehne wrote: > > The last remaining support for Qt Quick 1 are in the build system > > (qml1_module.prf, qml1_plugin.prf), QLibraryInfo::ImportsPath, qmake > > ($$QT_INSTALL_IMPORTS), and finally in QObject and QWidget (handling of > > QAbstractDeclarativeData::destroyed_qml1). > > > > We could remove these already in 5.12, in 5.13, or wait for Qt 6. I'd > prefer > > 5.12 if nobody objects > > I don't think we should. qtquick1 may not be as dead as we'd like it to > be. > I'd rather keep the QtCore API just in case someone is keeping the old > module > working for their applications (or Linux distribution, though I can't find > any). They may also be (ab)using QLibraryInfo::ImportsPath for some other > purpose. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Fri Oct 5 18:33:54 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 5 Oct 2018 16:33:54 +0000 Subject: [Development] Dropping remaining support of qtquick1 In-Reply-To: References: <2782043.OPD08NQSv6@tjmaciei-mobl1>, Message-ID: NIkolai Marchenko (5 October 2018 18:30) wrote: > I would like to remind people that there has already been a deprecation thread " > [Development] Deprecation of Qt Quick Controls 1" by > Frederik Gladhorn this Februrary. > A couple issues were raised there that were rather relevant and I would like to know if they were ever addressed. To save others the finding of it, that starts here: https://lists.qt-project.org/pipermail/development/2018-February/032073.html Eddy. From thiago.macieira at intel.com Sat Oct 6 00:47:42 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 5 Oct 2018 15:47:42 -0700 Subject: [Development] unified data model API in QtCore => thin wrapper proposal In-Reply-To: <2220296.uft7SWZhur@tjmaciei-mobl1> References: <2220296.uft7SWZhur@tjmaciei-mobl1> Message-ID: <1965578.lFb7HmRHaD@tjmaciei-mobl1> On Friday, 5 October 2018 08:35:10 PDT Thiago Macieira wrote: > Cons: > Suppresses move construction as in > QCborValue v = array[n]; > this still compiles, but passes through the copy constructor, not the move > one. We cana add an extra move constructor for const QCborValue && if > necessary. Never mind, you can't move from the const rvalue reference. It needs to be modifiable. So, again: should we have the const in the return types at the expense of losing the move semantic? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From py.siret at gmail.com Sat Oct 6 14:32:48 2018 From: py.siret at gmail.com (Pierre-Yves Siret) Date: Sat, 6 Oct 2018 14:32:48 +0200 Subject: [Development] Dropping remaining support of qtquick1 In-Reply-To: References: <2782043.OPD08NQSv6@tjmaciei-mobl1> Message-ID: Le ven. 5 oct. 2018 à 18:34, Edward Welbourne a écrit : > NIkolai Marchenko (5 October 2018 18:30) wrote: > > I would like to remind people that there has already been a deprecation > thread " > > [Development] Deprecation of Qt Quick Controls 1" by > > Frederik Gladhorn this Februrary. > > A couple issues were raised there that were rather relevant and I would > like to know if they were ever addressed. > > To save others the finding of it, that starts here: > > https://lists.qt-project.org/pipermail/development/2018-February/032073.html > > Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Kai is talking about Qt Quick 1 not Qt Quick Controls 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From enmarantispam at gmail.com Sat Oct 6 14:45:47 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Sat, 6 Oct 2018 15:45:47 +0300 Subject: [Development] Dropping remaining support of qtquick1 In-Reply-To: References: <2782043.OPD08NQSv6@tjmaciei-mobl1> Message-ID: Doesn't that mean that Controls will also get the boot though? On Sat, Oct 6, 2018 at 3:33 PM Pierre-Yves Siret wrote: > > > Le ven. 5 oct. 2018 à 18:34, Edward Welbourne a > écrit : > >> NIkolai Marchenko (5 October 2018 18:30) wrote: >> > I would like to remind people that there has already been a deprecation >> thread " >> > [Development] Deprecation of Qt Quick Controls 1" by >> > Frederik Gladhorn this Februrary. >> > A couple issues were raised there that were rather relevant and I would >> like to know if they were ever addressed. >> >> To save others the finding of it, that starts here: >> >> https://lists.qt-project.org/pipermail/development/2018-February/032073.html >> >> Eddy. >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > > Kai is talking about Qt Quick 1 not Qt Quick Controls 1 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sat Oct 6 19:25:23 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 06 Oct 2018 10:25:23 -0700 Subject: [Development] Dropping remaining support of qtquick1 In-Reply-To: References: Message-ID: <1652999.vzMnarWouJ@tjmaciei-mobl1> On Saturday, 6 October 2018 05:45:47 PDT NIkolai Marchenko wrote: > Doesn't that mean that Controls will also get the boot though? No, QtQuickControls1 is a QtQuick2 framework. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lars.knoll at qt.io Sun Oct 7 10:53:04 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Sun, 7 Oct 2018 08:53:04 +0000 Subject: [Development] unified data model API in QtCore => thin wrapper proposal In-Reply-To: <1965578.lFb7HmRHaD@tjmaciei-mobl1> References: <2220296.uft7SWZhur@tjmaciei-mobl1> <1965578.lFb7HmRHaD@tjmaciei-mobl1> Message-ID: > On 6 Oct 2018, at 00:47, Thiago Macieira wrote: > > On Friday, 5 October 2018 08:35:10 PDT Thiago Macieira wrote: >> Cons: >> Suppresses move construction as in >> QCborValue v = array[n]; >> this still compiles, but passes through the copy constructor, not the move >> one. We cana add an extra move constructor for const QCborValue && if >> necessary. > > Never mind, you can't move from the const rvalue reference. It needs to be > modifiable. > > So, again: should we have the const in the return types at the expense of > losing the move semantic? I’d go for returning a const object. It’s a shame to loose the move semantics, but the other case would lead to easy programming errors. Cheers, Lars From lars.knoll at qt.io Sun Oct 7 10:56:47 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Sun, 7 Oct 2018 08:56:47 +0000 Subject: [Development] Using #pragma once Message-ID: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io> Hi, Just a quick question: Does anybody have any good arguments against us starting to use #pragma once instead of header guards throughout our code base? I’ve started using it implicitly when updating 3rd party code (the macro assembler) in qtdeclarative without any problems (so I’d supported by all our compilers). IMO #pragma once is both safer and nicer to use than classic header guards. Cheers, Lars From apoenitz at t-online.de Sun Oct 7 11:06:05 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Sun, 7 Oct 2018 11:06:05 +0200 Subject: [Development] Using #pragma once In-Reply-To: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io> References: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io> Message-ID: <20181007090605.GA5407@klara.mpi.htwm.de> On Sun, Oct 07, 2018 at 08:56:47AM +0000, Lars Knoll wrote: > Hi, > > Just a quick question: Does anybody have any good arguments against us > starting to use #pragma once instead of header guards throughout our > code base? Not me. > I’ve started using it implicitly when updating 3rd party code (the > macro assembler) in qtdeclarative without any problems (so I’d > supported by all our compilers). IMO #pragma once is both safer and > nicer to use than classic header guards. Qt Creator uses it since more than two years without problems. For a potential conversion https://github.com/cgmb/guardonce may help. Andre' From tony.sarajarvi at qt.io Sun Oct 7 11:16:26 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Sun, 7 Oct 2018 09:16:26 +0000 Subject: [Development] Bug in Ubuntu 18.04 provisioning preventing builds in dev branch currently Message-ID: Hi A small bug in the provisioning scripts of Ubuntu 18.04 prevents the builds from going through in dev branch currently. We run apt update only after we try to install the packages. So it's trying to install a package so old it doesn't exist in the repos anymore. A fix has landed in 5.12 already (a side effect of another change), so a merge from 5.12 -> dev will fix the situation. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From gunnar.roth at gmx.de Sun Oct 7 14:30:52 2018 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Sun, 07 Oct 2018 12:30:52 +0000 Subject: [Development] Using #pragma once In-Reply-To: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io> References: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io> Message-ID: Hi Lars, I do not really object exclusive use of pragma once, without header guards ( I use it myself), I just want to tell about my experience on Debian Stretch with gcc 6.3 1. Using precompiled header, you can run into trouble, if you use forward header , like qt does, and these do not contain pragma once too. I got double definition errors then, because pragam once was ignored somehow. 2. There is a , still unfixed, gcc bug since gcc 4.6.3 , where pragma once is ignored for files which start with a Utf8 BOM, when using precompiled headers. see https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=56549 3. #pragma once makes gcc much slower according to Bug 58770 - GCC very slow compiling with #pragma once https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58770 Regards, Gunnar Roth ------ Original Message ------ From: "Lars Knoll" To: "Qt development mailing list" Sent: 07/10/2018 10:56:47 Subject: [Development] Using #pragma once >Hi, > >Just a quick question: Does anybody have any good arguments against us >starting to use #pragma once instead of header guards throughout our >code base? > >I’ve started using it implicitly when updating 3rd party code (the >macro assembler) in qtdeclarative without any problems (so I’d >supported by all our compilers). IMO #pragma once is both safer and >nicer to use than classic header guards. > >Cheers, >Lars > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From sergio.martins at kdab.com Sun Oct 7 15:18:55 2018 From: sergio.martins at kdab.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Sun, 07 Oct 2018 14:18:55 +0100 Subject: [Development] Using #pragma once In-Reply-To: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io> References: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io> Message-ID: <9bb11eeef4723a86086f2c6b03639ba2@kdab.com> On 2018-10-07 09:56, Lars Knoll wrote: > Hi, > > Just a quick question: Does anybody have any good arguments against us > starting to use #pragma once instead of header guards throughout our > code base? Hi Lars, This was already discussed back in January: https://lists.qt-project.org/pipermail/development/2018-January/031966.html The conclusion was to keep using header guards. Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From lars.knoll at qt.io Sun Oct 7 16:37:19 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Sun, 7 Oct 2018 14:37:19 +0000 Subject: [Development] Using #pragma once In-Reply-To: <9bb11eeef4723a86086f2c6b03639ba2@kdab.com> References: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io> <9bb11eeef4723a86086f2c6b03639ba2@kdab.com> Message-ID: <4D674CFD-B9C5-4E0E-B787-CB4A4B6C70AC@qt.io> > On 7 Oct 2018, at 15:18, Sérgio Martins wrote: > > On 2018-10-07 09:56, Lars Knoll wrote: >> Hi, >> Just a quick question: Does anybody have any good arguments against us >> starting to use #pragma once instead of header guards throughout our >> code base? > > Hi Lars, > > > This was already discussed back in January: https://lists.qt-project.org/pipermail/development/2018-January/031966.html > > The conclusion was to keep using header guards. Thanks. I must have missed that thread (or forgotten about it) :) Cheers, Lars From sergio.martins at kdab.com Sun Oct 7 17:41:05 2018 From: sergio.martins at kdab.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Sun, 07 Oct 2018 16:41:05 +0100 Subject: [Development] Using #pragma once In-Reply-To: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io> References: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io> Message-ID: <5f263fc22e8fc3f475dafa390d3ebf4d@kdab.com> On 2018-10-07 09:56, Lars Knoll wrote: > IMO #pragma once is both safer and nicer to use than classic header > guards. Regarding safety, clang has -Wheader-guard which catches typos in header guards, so most of our codebase should be ok. (Would be nice to have clang-cl -Werror builds on our Windows CI though!) Inspired by this I quickly hacked a clazy check to find typos in all ifndef/define pairs, since clang only does it for include guards. It found this https://codereview.qt-project.org/#/c/242090/ Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Sun Oct 7 20:39:22 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 7 Oct 2018 11:39:22 -0700 Subject: [Development] Using #pragma once In-Reply-To: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io> References: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io> Message-ID: <5875504.orze0AEH0V@tjmaciei-mobl1> On Sunday, 7 October 2018 01:56:47 PDT Lars Knoll wrote: > Hi, > > Just a quick question: Does anybody have any good arguments against us > starting to use #pragma once instead of header guards throughout our code > base? Yes, two: a) not supported everywhere b) not well-defined behaviour when it comes to anything but the simplest organisation For example, I have ~/src as a bind-mount to ~/dev/src. That means ~/src/qt/qt5/qtbase/src/corelib/global/qglobal.h ~/dev/src/qt/qt5/qtbase/src/corelib/global/qglobal.h are actually the same file, but they aren't for the effects of #pragma once because the paths differ. Another problem is qcompilerdetection.h, qprocessordetection.h, qsystemdetection.h, qtypeinfo.h, etc. which depend on the header guards to break the include cycle. Ditto for qlist.h + qstringlist.h and qbytearraylist.h > I’ve started using it implicitly when updating 3rd party code (the macro > assembler) in qtdeclarative without any problems (so I’d supported by all > our compilers). IMO #pragma once is both safer and nicer to use than > classic header guards. On all the compilers that compile that macro assembler. We still have architectures where they don't. Another aspect is that the macro assembler headers don't get installed and aren't subject to syncqt.pl, so their hierarchy is a lot simpler than for Qt's own headers. I recommend against changing Qt. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From fromqt at tungware.se Mon Oct 8 00:17:30 2018 From: fromqt at tungware.se (Henry Skoglund) Date: Mon, 8 Oct 2018 00:17:30 +0200 Subject: [Development] Using #pragma once In-Reply-To: <5875504.orze0AEH0V@tjmaciei-mobl1> References: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io> <5875504.orze0AEH0V@tjmaciei-mobl1> Message-ID: <0a1f55ed-42c2-8a04-854b-c8e1f5eb8270@tungware.se> On 2018-10-07 20:39, Thiago Macieira wrote: > On Sunday, 7 October 2018 01:56:47 PDT Lars Knoll wrote: >> Hi, >> >> Just a quick question: Does anybody have any good arguments against us >> starting to use #pragma once instead of header guards throughout our code >> base? > > Yes, two: > > a) not supported everywhere > b) not well-defined behaviour when it comes to anything but the simplest > organisation > > For example, I have ~/src as a bind-mount to ~/dev/src. That means > ~/src/qt/qt5/qtbase/src/corelib/global/qglobal.h > ~/dev/src/qt/qt5/qtbase/src/corelib/global/qglobal.h > are actually the same file, but they aren't for the effects of #pragma once > because the paths differ. > > Another problem is qcompilerdetection.h, qprocessordetection.h, > qsystemdetection.h, qtypeinfo.h, etc. which depend on the header guards to > break the include cycle. Ditto for qlist.h + qstringlist.h and > qbytearraylist.h > ... ... > > I recommend against changing Qt. > Hi, but isn't C++17's __has_include preprocessor cmd an implicit endorsement of #pragma once? I mean, they both assume that the file namespace is stable and idempotent. The example with ~/src as a bind-mount to ~/dev/src above, reminds me of the old pointer aliasing problems in C++. But cannot it be solved by requiring #pragma once to always call realpath() first, i.e. always test on "the canonicalized absolute pathname" that realpath() returns? Rgrds Henry From thiago.macieira at intel.com Mon Oct 8 07:13:16 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 07 Oct 2018 22:13:16 -0700 Subject: [Development] Using #pragma once In-Reply-To: <0a1f55ed-42c2-8a04-854b-c8e1f5eb8270@tungware.se> References: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io> <5875504.orze0AEH0V@tjmaciei-mobl1> <0a1f55ed-42c2-8a04-854b-c8e1f5eb8270@tungware.se> Message-ID: <3095832.MIWNsL7gjg@tjmaciei-mobl1> On Sunday, 7 October 2018 15:17:30 PDT Henry Skoglund wrote: > > I recommend against changing Qt. > > Hi, but isn't C++17's __has_include preprocessor cmd an implicit > endorsement of #pragma once? I mean, they both assume that the file > namespace is stable and idempotent. No, I don't see how one thing has to do with the other. __has_include imples that the #include will not fail with "No such file or directory" and hopefully won't fail either with "Is a directory". Other checks are welcome, but I wouldn't be too picky if they didn't get done. #pragma once only applies after the #include and changes nothing about whether the #include succeeds or not. > The example with ~/src as a bind-mount to ~/dev/src above, reminds me of > the old pointer aliasing problems in C++. But cannot it be solved by > requiring #pragma once to always call realpath() first, i.e. always test > on "the canonicalized absolute pathname" that realpath() returns? No. $ realpath ~/dev/src/qt/ ~/src/qt /home/tjmaciei/dev/src/qt /home/tjmaciei/src/qt Bind-mounts are not symlinks. For all intents and purposes they are different filesystems: you can't link() from one to the other, for example. You may be able to tell that they are the same because the dev_t is the same: $ stat -c '%D %i %n' ~/dev/src ~/src fe03 4456449 /home/tjmaciei/dev/src fe03 4456449 /home/tjmaciei/src But to tell that the file is the same you'd need to compare inodes and those are not guaranteed on network mounts. Another option is to use name_to_handle_at(), a Linux-specific function, but that will also fail with bind mounts and multiple mounts of the same filesystem. The manpage suggests resolving mount IDs to actual disks by looking for them in /dev/disks/by-uuid. So you see why this is not a very easy solution. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From fromqt at tungware.se Mon Oct 8 08:23:39 2018 From: fromqt at tungware.se (Henry Skoglund) Date: Mon, 8 Oct 2018 08:23:39 +0200 Subject: [Development] Using #pragma once In-Reply-To: <3095832.MIWNsL7gjg@tjmaciei-mobl1> References: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io> <5875504.orze0AEH0V@tjmaciei-mobl1> <0a1f55ed-42c2-8a04-854b-c8e1f5eb8270@tungware.se> <3095832.MIWNsL7gjg@tjmaciei-mobl1> Message-ID: <6b9795ba-b6a2-69f8-57bd-cd7ae048ced7@tungware.se> On 2018-10-08 07:13, Thiago Macieira wrote: > On Sunday, 7 October 2018 15:17:30 PDT Henry Skoglund wrote: >>> I recommend against changing Qt. >> >> Hi, but isn't C++17's __has_include preprocessor cmd an implicit >> endorsement of #pragma once? I mean, they both assume that the file >> namespace is stable and idempotent. > > No, I don't see how one thing has to do with the other. > > __has_include imples that the #include will not fail with "No such file or > directory" and hopefully won't fail either with "Is a directory". Other checks > are welcome, but I wouldn't be too picky if they didn't get done. > > #pragma once only applies after the #include and changes nothing about whether > the #include succeeds or not. > >> The example with ~/src as a bind-mount to ~/dev/src above, reminds me of >> the old pointer aliasing problems in C++. But cannot it be solved by >> requiring #pragma once to always call realpath() first, i.e. always test >> on "the canonicalized absolute pathname" that realpath() returns? > > No. > > $ realpath ~/dev/src/qt/ ~/src/qt > /home/tjmaciei/dev/src/qt > /home/tjmaciei/src/qt > > Bind-mounts are not symlinks. For all intents and purposes they are different > filesystems: you can't link() from one to the other, for example. You may be > able to tell that they are the same because the dev_t is the same: > > $ stat -c '%D %i %n' ~/dev/src ~/src > fe03 4456449 /home/tjmaciei/dev/src > fe03 4456449 /home/tjmaciei/src > > But to tell that the file is the same you'd need to compare inodes and those > are not guaranteed on network mounts. > > Another option is to use name_to_handle_at(), a Linux-specific function, but > that will also fail with bind mounts and multiple mounts of the same > filesystem. The manpage suggests resolving mount IDs to actual disks by > looking for them in /dev/disks/by-uuid. > > So you see why this is not a very easy solution. > Yes, I see. When #pragma once was introduced 20 years ago by Microsoft I thought it was the greatest thing since sliced bread, but maybe it's time to reconsider. So, what about a new preprocessor command: __has_same_md6_digest It would require the compiler to store an md6 hash/checksum of the contents of each of the #include files seen during compilation, but if most of the compiler's time is spent waiting for file i/o, then computing those md6 sums wouldn't be so costly. It would work the same way as the traditional header guards, but more automated, example: #if !__has_same_md6_digest ... ... ... #endif Rgrds Henry From edward.welbourne at qt.io Mon Oct 8 10:14:41 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 8 Oct 2018 08:14:41 +0000 Subject: [Development] unified data model API in QtCore => thin wrapper proposal In-Reply-To: References: <2220296.uft7SWZhur@tjmaciei-mobl1> <1965578.lFb7HmRHaD@tjmaciei-mobl1>, Message-ID: > On Friday, 5 October 2018 08:35:10 PDT Thiago Macieira wrote: >>> Cons: >>> Suppresses move construction as in >>> QCborValue v = array[n]; >>> this still compiles, but passes through the copy constructor, not >>> the move one. We cana add an extra move constructor for const >>> QCborValue && if necessary. On 6 Oct 2018, at 00:47, Thiago Macieira wrote: >> Never mind, you can't move from the const rvalue reference. It needs >> to be modifiable. >> >> So, again: should we have the const in the return types at the >> expense of losing the move semantic? Lars Knoll (7 October 2018 10:53) > I’d go for returning a const object. It’s a shame to loose the move > semantics, but the other case would lead to easy programming errors. The change currently staged for integration [0] only adds const to the QCborValue return types of the read-only operator[] on QCbor{Array,Map}; as noted in the review comments there, there are several other methods returning QCborValue, e.g. at(index) and value(key), that potentially need to also return it as const. My rationale for limiting this to operator[] was that a['b']['c']['d'] = 12 might seem like a reasonable thing to do, while a.at('b')['c']['d'] = 12 seems more obviously like a senseless thing to attempt. [0] https://codereview.qt-project.org/240046 So the question arises: which other QCbor{Map,Array} methods should const-qualify their QCborValue returns ? Eddy. From edward.welbourne at qt.io Mon Oct 8 10:50:04 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 8 Oct 2018 08:50:04 +0000 Subject: [Development] Using #pragma once In-Reply-To: <5875504.orze0AEH0V@tjmaciei-mobl1> References: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io>, <5875504.orze0AEH0V@tjmaciei-mobl1> Message-ID: On Sunday, 7 October 2018 01:56:47 PDT Lars Knoll wrote: >> Just a quick question: Does anybody have any good arguments against >> us starting to use #pragma once instead of header guards throughout >> our code base? Thiago Macieira (7 October 2018 20:39) wrote: > For example, I have ~/src as a bind-mount to ~/dev/src. That means > ~/src/qt/qt5/qtbase/src/corelib/global/qglobal.h > ~/dev/src/qt/qt5/qtbase/src/corelib/global/qglobal.h > are actually the same file, but they aren't for the effects of #pragma > once because the paths differ. How could the compiler end up trying to #include both of those files ? Wherever they appear in its include-path for a given compilation unit, one of them must appear before the other and thus be used consistently. I suppose you could put one directory in the sys-include path for #include and the other in the source-include path for #include "qglobal.h" ... but this seems like a strangely contrived thing to do and I'd be inclined to say "well don't do that, then" to anyone who has problems with it. What am I missing ? The other reasons make more sense to me (and I'm "not a fan" of #pragma in general), Eddy. From thiago.macieira at intel.com Mon Oct 8 17:33:00 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 8 Oct 2018 08:33:00 -0700 Subject: [Development] Using #pragma once In-Reply-To: References: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io> <5875504.orze0AEH0V@tjmaciei-mobl1> Message-ID: <2157985.6xckCvCmOm@tjmaciei-mobl1> On Monday, 8 October 2018 01:50:04 PDT Edward Welbourne wrote: > On Sunday, 7 October 2018 01:56:47 PDT Lars Knoll wrote: > >> Just a quick question: Does anybody have any good arguments against > >> us starting to use #pragma once instead of header guards throughout > >> our code base? > > Thiago Macieira (7 October 2018 20:39) wrote: > > For example, I have ~/src as a bind-mount to ~/dev/src. That means > > > > ~/src/qt/qt5/qtbase/src/corelib/global/qglobal.h > > ~/dev/src/qt/qt5/qtbase/src/corelib/global/qglobal.h > > > > are actually the same file, but they aren't for the effects of #pragma > > once because the paths differ. > > How could the compiler end up trying to #include both of those files ? THAT is the million dollar question. Of course it shouldn't, but it could happen in an improperly-configured build, with stale files. And now instead of no error due to same include guard, you get C++ error which make no sense. > Wherever they appear in its include-path for a given compilation unit, > one of them must appear before the other and thus be used consistently. > I suppose you could put one directory in the sys-include path for > #include and the other in the source-include path for > #include "qglobal.h" ... but this seems like a strangely contrived thing > to do and I'd be inclined to say "well don't do that, then" to anyone > who has problems with it. What am I missing ? The ability to debug and who has to do it. If this problem happens, it happens for someone *using* Qt, not those of us developing it. And figuring out what went wrong is extremely difficult. > The other reasons make more sense to me (and I'm "not a fan" of #pragma > in general), -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mwoehlke.floss at gmail.com Mon Oct 8 18:12:26 2018 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 8 Oct 2018 12:12:26 -0400 Subject: [Development] Using #pragma once In-Reply-To: <6b9795ba-b6a2-69f8-57bd-cd7ae048ced7@tungware.se> References: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io> <5875504.orze0AEH0V@tjmaciei-mobl1> <0a1f55ed-42c2-8a04-854b-c8e1f5eb8270@tungware.se> <3095832.MIWNsL7gjg@tjmaciei-mobl1> <6b9795ba-b6a2-69f8-57bd-cd7ae048ced7@tungware.se> Message-ID: On 08/10/2018 02.23, Henry Skoglund wrote: > So, what about a new preprocessor command: > > __has_same_md6_digest See also http://wg21.link/p0538 and note that EWG rejected it. The general consensus, AFAICT, is that modules is expected to make all this stuff irrelevant, and therefore EWG does not want to invest in fiddling with the preprocessor for a problem that is becoming irrelevant. -- Matthew From fromqt at tungware.se Mon Oct 8 18:40:52 2018 From: fromqt at tungware.se (Henry Skoglund) Date: Mon, 8 Oct 2018 18:40:52 +0200 Subject: [Development] Using #pragma once In-Reply-To: References: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io> <5875504.orze0AEH0V@tjmaciei-mobl1> <0a1f55ed-42c2-8a04-854b-c8e1f5eb8270@tungware.se> <3095832.MIWNsL7gjg@tjmaciei-mobl1> <6b9795ba-b6a2-69f8-57bd-cd7ae048ced7@tungware.se> Message-ID: On 2018-10-08 18:12, Matthew Woehlke wrote: > On 08/10/2018 02.23, Henry Skoglund wrote: >> So, what about a new preprocessor command: >> >> __has_same_md6_digest > > See also http://wg21.link/p0538 and note that EWG rejected it. The > general consensus, AFAICT, is that modules is expected to make all this > stuff irrelevant, and therefore EWG does not want to invest in fiddling > with the preprocessor for a problem that is becoming irrelevant. > Aha, didn't know about your proposal, looks good. I forgot about modules, and even if they don't make it into C++20, I agree that most likely they are the future/best way to solve this problem. Rgrds Henry From thiago.macieira at intel.com Mon Oct 8 19:06:37 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 8 Oct 2018 10:06:37 -0700 Subject: [Development] Using #pragma once In-Reply-To: References: <137A36F7-EF6A-48F5-950B-4DE72DE74C08@qt.io> <6b9795ba-b6a2-69f8-57bd-cd7ae048ced7@tungware.se> Message-ID: <5351973.aaNgpuUAxS@tjmaciei-mobl1> On Monday, 8 October 2018 09:12:26 PDT Matthew Woehlke wrote: > On 08/10/2018 02.23, Henry Skoglund wrote: > > So, what about a new preprocessor command: > > > > __has_same_md6_digest > > See also http://wg21.link/p0538 and note that EWG rejected it. The > general consensus, AFAICT, is that modules is expected to make all this > stuff irrelevant, and therefore EWG does not want to invest in fiddling > with the preprocessor for a problem that is becoming irrelevant. Comparing hashes has another problem: what happens if you have /usr/include/ QtCore/qglobal.h but it's slightly different (an older version)? In that case, it could get included by #pragma once but wouldn't be for regular include guards. Again, this is a mistake in setting things up, but it happens often enough. And the problem is one of figuring out what's wrong. Not that it would stop *another* header from the older installation from getting included, though. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sierdzio at gmail.com Wed Oct 10 19:43:32 2018 From: sierdzio at gmail.com (Tomasz Siekierda) Date: Wed, 10 Oct 2018 19:43:32 +0200 Subject: [Development] Gerrit "no matching cipher found" Message-ID: Hi, it's been a while since I've last pushed to gerrit. I'm getting this: $ git push gerrit HEAD:refs/for/dev Unable to negotiate with 54.229.21.112 port 29418: no matching cipher found. Their offer: aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. I'm on Kubuntu 18.10. I've made sure the ssh pub key on gerrit is correct. And I've used init-repository script to get going. Does anybody know how to fix this? Most probably it's something stupid/ trivial. Cheerio, sierdzio From kshegunov at gmail.com Wed Oct 10 19:51:54 2018 From: kshegunov at gmail.com (Konstantin Shegunov) Date: Wed, 10 Oct 2018 20:51:54 +0300 Subject: [Development] Gerrit "no matching cipher found" In-Reply-To: References: Message-ID: On Wed, Oct 10, 2018 at 8:43 PM Tomasz Siekierda wrote: > Hi, > I'm on Kubuntu 18.10. I've made sure the ssh pub key on gerrit is > correct. And I've used init-repository script to get going. > Hi, Ran into this a few months ago. Force the cipher through the ssh config and you should get it going. Sample follows: Host codereview.qt-project.org Port 29418 User Ciphers aes256-cbc PreferredAuthentications publickey IdentityFile Kind regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Wed Oct 10 20:25:15 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Wed, 10 Oct 2018 18:25:15 +0000 Subject: [Development] Maintenance break for the CI Message-ID: Hi Let's do a small maintenance break for the CI right away. It's quite unstable currently, and a reset of all the hosts usually helps. While I do that, I'll also enable nested virtual machines. This will enable a few things we are working on. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Oct 10 21:42:49 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 10 Oct 2018 12:42:49 -0700 Subject: [Development] Gerrit "no matching cipher found" In-Reply-To: References: Message-ID: <5293183.xj0a9aMQnB@tjmaciei-mobl1> On Wednesday, 10 October 2018 10:43:32 PDT Tomasz Siekierda wrote: > I'm on Kubuntu 18.10. I've made sure the ssh pub key on gerrit is > correct. And I've used init-repository script to get going. > > Does anybody know how to fix this? Most probably it's something stupid/ > trivial. Most Linux distributions or possibly OpenSSH upstream have begun disabling older ciphers by default. Our Gerrit server uses an old version of JGit, which uses old ciphers. You need to turn something back on. See Konstantin's reply for a suggestion on which one. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Thu Oct 11 06:50:13 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 11 Oct 2018 04:50:13 +0000 Subject: [Development] HEADS UP : Qt 5.12 soft string freeze In-Reply-To: References: Message-ID: Hi all, First beta release from Qt 5.12 is already out so it is time to start keeping translatable strings as it is. And let's have official string freeze Fri 19th October 2018. br, Jani From sierdzio at gmail.com Thu Oct 11 08:08:54 2018 From: sierdzio at gmail.com (Tomasz Siekierda) Date: Thu, 11 Oct 2018 08:08:54 +0200 Subject: [Development] Gerrit "no matching cipher found" In-Reply-To: <5293183.xj0a9aMQnB@tjmaciei-mobl1> References: <5293183.xj0a9aMQnB@tjmaciei-mobl1> Message-ID: Perfect, that worked! Thanks, Konstantin! And thanks Thiago for explanation, too. On Wed, 10 Oct 2018 at 21:43, Thiago Macieira wrote: > > On Wednesday, 10 October 2018 10:43:32 PDT Tomasz Siekierda wrote: > > I'm on Kubuntu 18.10. I've made sure the ssh pub key on gerrit is > > correct. And I've used init-repository script to get going. > > > > Does anybody know how to fix this? Most probably it's something stupid/ > > trivial. > > Most Linux distributions or possibly OpenSSH upstream have begun disabling > older ciphers by default. Our Gerrit server uses an old version of JGit, which > uses old ciphers. You need to turn something back on. See Konstantin's reply > for a suggestion on which one. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From announce at qt-project.org Thu Oct 11 10:50:57 2018 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Thu, 11 Oct 2018 08:50:57 +0000 Subject: [Development] [Announce] Qt Creator 4.8 Beta released Message-ID: We are happy to announce the release of Qt Creator 4.8 Beta! http://blog.qt.io/blog/2018/10/11/qt-creator-4-8-beta-released/ -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From alexander.blasche at qt.io Thu Oct 11 11:28:39 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Thu, 11 Oct 2018 09:28:39 +0000 Subject: [Development] =?iso-8859-1?q?Nominating_Cristi=E1n_Maureira-Frede?= =?iso-8859-1?q?s_for_approver?= Message-ID: Hi, I'd like to nominate Cristian Maureira-Fredes for approver rights. Predominately he has worked on the Qt for Python project ensuring that Qt and the Python world can come together. His work: https://codereview.qt-project.org/#/q/owner:%22Cristian+Maureira-Fredes%22,n,z His reviews: https://codereview.qt-project.org/#/q/reviewer:%22Cristian+Maureira-Fredes%22,n,z -- Alex From alexandru.croitor at qt.io Thu Oct 11 11:44:35 2018 From: alexandru.croitor at qt.io (Alexandru Croitor) Date: Thu, 11 Oct 2018 09:44:35 +0000 Subject: [Development] =?iso-8859-1?q?Nominating_Cristi=E1n_Maureira-Fred?= =?iso-8859-1?q?es_for_approver?= In-Reply-To: References: Message-ID: Hi, A fat +1 from me. Regards, Alex. > On 11. Oct 2018, at 11:28, Alex Blasche wrote: > > Hi, > > I'd like to nominate Cristian Maureira-Fredes for approver rights. > > Predominately he has worked on the Qt for Python project ensuring that Qt and the Python world can come together. > > His work: > https://codereview.qt-project.org/#/q/owner:%22Cristian+Maureira-Fredes%22,n,z > > His reviews: > https://codereview.qt-project.org/#/q/reviewer:%22Cristian+Maureira-Fredes%22,n,z > > -- > Alex > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From perezmeyer at gmail.com Thu Oct 11 12:23:40 2018 From: perezmeyer at gmail.com (=?UTF-8?Q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?=) Date: Thu, 11 Oct 2018 07:23:40 -0300 Subject: [Development] Gerrit "no matching cipher found" In-Reply-To: <5293183.xj0a9aMQnB@tjmaciei-mobl1> References: <5293183.xj0a9aMQnB@tjmaciei-mobl1> Message-ID: El mié., 10 de oct. de 2018 16:43, Thiago Macieira < thiago.macieira at intel.com> escribió: > On Wednesday, 10 October 2018 10:43:32 PDT Tomasz Siekierda wrote: > > I'm on Kubuntu 18.10. I've made sure the ssh pub key on gerrit is > > correct. And I've used init-repository script to get going. > > > > Does anybody know how to fix this? Most probably it's something stupid/ > > trivial. > > Most Linux distributions or possibly OpenSSH upstream have begun disabling > older ciphers by default. The later as I understand. Our Gerrit server uses an old version of JGit, which > uses old ciphers. You need to turn something back on. See Konstantin's > reply > for a suggestion on which one. Is there a chance to fix this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Thu Oct 11 12:33:38 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 11 Oct 2018 10:33:38 +0000 Subject: [Development] Gerrit "no matching cipher found" In-Reply-To: References: <5293183.xj0a9aMQnB@tjmaciei-mobl1>, Message-ID: El mié., 10 de oct. de 2018 16:43, Thiago Macieira > escribió: > Our Gerrit server uses an old version of JGit, which uses old > ciphers. You need to turn something back on. See Konstantin's reply > for a suggestion on which one. Lisandro Damián Nicanor Pérez Meyer (11 October 2018 12:23) > Is there a chance to fix this? I imagine the upgrade to Gerrit should do so. That upgrade is in progress, but may take some time. Eddy. From tony.sarajarvi at qt.io Thu Oct 11 13:48:35 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Thu, 11 Oct 2018 11:48:35 +0000 Subject: [Development] Shutting down the CI right now! Message-ID: Hi Due to a lot of changes while developing and snapshots being huge, our Compellent backend is nearly 100% full. I'll shut down the CI for a few hours to avoid everything breaking due to lack of disk space. We'll be back after snapshots have been deleted. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Fri Oct 12 07:16:00 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Fri, 12 Oct 2018 05:16:00 +0000 Subject: [Development] Shutting down the CI right now! In-Reply-To: References: Message-ID: Wow... ok it took longer than expected (as usual). Not only did we have to remove snapshots, we also had to run unmap on the Compellent, so this whole thing took a while. But nothing got lost, thanks to a last minute intervention. So, the CI is up again, and good luck stage storming it -Tony From: Tony Sarajärvi Sent: torstai 11. lokakuuta 2018 14.49 To: development at qt-project.org Subject: Shutting down the CI right now! Hi Due to a lot of changes while developing and snapshots being huge, our Compellent backend is nearly 100% full. I'll shut down the CI for a few hours to avoid everything breaking due to lack of disk space. We'll be back after snapshots have been deleted. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From Liang.Qi at qt.io Fri Oct 12 07:20:40 2018 From: Liang.Qi at qt.io (Liang Qi) Date: Fri, 12 Oct 2018 05:20:40 +0000 Subject: [Development] Shutting down the CI right now! In-Reply-To: References: Message-ID: <61A949D2-9287-4897-AF3C-A72BF1C778FB@qt.io> Thanks for the work, and sometimes in spare time. But there is no success for qt5 integrations and qtbase in any branch since the work from Wednesday night. See https://bugreports.qt.io/browse/QTQAINFRA-2273 , Angle building timeout (on Windows) So I suggest not to restage in above areas at least before the issue got fixed. Best Regards, Liang > On 12 Oct 2018, at 07:16, Tony Sarajärvi wrote: > > Wow… ok it took longer than expected (as usual). Not only did we have to remove snapshots, we also had to run unmap on the Compellent, so this whole thing took a while. But nothing got lost, thanks to a last minute intervention. > > So, the CI is up again, and good luck stage storming it > > -Tony > > From: Tony Sarajärvi > Sent: torstai 11. lokakuuta 2018 14.49 > To: development at qt-project.org > Subject: Shutting down the CI right now! > > Hi > > Due to a lot of changes while developing and snapshots being huge, our Compellent backend is nearly 100% full. I’ll shut down the CI for a few hours to avoid everything breaking due to lack of disk space. We’ll be back after snapshots have been deleted. > > -Tony > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From tony.sarajarvi at qt.io Fri Oct 12 08:12:10 2018 From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=) Date: Fri, 12 Oct 2018 06:12:10 +0000 Subject: [Development] Shutting down the CI right now! In-Reply-To: <61A949D2-9287-4897-AF3C-A72BF1C778FB@qt.io> References: <61A949D2-9287-4897-AF3C-A72BF1C778FB@qt.io> Message-ID: Liang: Ok, one thing is my bad in all of this. I told you yesterday after noon that I've reverted the host-passthrough thing. Well...yeah, the configuration. I just forgot to host the setting to the hosts. Just realized it. So _now_ the old settings of qemu64 instead of host-passthrough is in effect. See if that helps. -Tony -----Original Message----- From: Liang Qi Sent: perjantai 12. lokakuuta 2018 8.21 To: Tony Sarajärvi Cc: development at qt-project.org Subject: Re: [Development] Shutting down the CI right now! Thanks for the work, and sometimes in spare time. But there is no success for qt5 integrations and qtbase in any branch since the work from Wednesday night. See https://bugreports.qt.io/browse/QTQAINFRA-2273 , Angle building timeout (on Windows) So I suggest not to restage in above areas at least before the issue got fixed. Best Regards, Liang > On 12 Oct 2018, at 07:16, Tony Sarajärvi wrote: > > Wow… ok it took longer than expected (as usual). Not only did we have to remove snapshots, we also had to run unmap on the Compellent, so this whole thing took a while. But nothing got lost, thanks to a last minute intervention. > > So, the CI is up again, and good luck stage storming it > > -Tony > > From: Tony Sarajärvi > Sent: torstai 11. lokakuuta 2018 14.49 > To: development at qt-project.org > Subject: Shutting down the CI right now! > > Hi > > Due to a lot of changes while developing and snapshots being huge, our Compellent backend is nearly 100% full. I’ll shut down the CI for a few hours to avoid everything breaking due to lack of disk space. We’ll be back after snapshots have been deleted. > > -Tony > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Liang.Qi at qt.io Fri Oct 12 09:05:09 2018 From: Liang.Qi at qt.io (Liang Qi) Date: Fri, 12 Oct 2018 07:05:09 +0000 Subject: [Development] Shutting down the CI right now! In-Reply-To: References: <61A949D2-9287-4897-AF3C-A72BF1C778FB@qt.io> Message-ID: <302FD80A-3FE5-462B-BB23-9FC6BF377331@qt.io> Hi, Tony, Now the current integration for https://codereview.qt-project.org/#/c/239542/ and another change looks promising. Thanks. And I plan to hi-jack qtbase 5.12 branch for a batch of qmake and android changes after this integration once more. —Liang > On 12 Oct 2018, at 08:12, Tony Sarajärvi wrote: > > Liang: Ok, one thing is my bad in all of this. I told you yesterday after noon that I've reverted the host-passthrough thing. Well...yeah, the configuration. I just forgot to host the setting to the hosts. Just realized it. So _now_ the old settings of qemu64 instead of host-passthrough is in effect. See if that helps. > > -Tony > > -----Original Message----- > From: Liang Qi > Sent: perjantai 12. lokakuuta 2018 8.21 > To: Tony Sarajärvi > Cc: development at qt-project.org > Subject: Re: [Development] Shutting down the CI right now! > > Thanks for the work, and sometimes in spare time. > > But there is no success for qt5 integrations and qtbase in any branch since the work from Wednesday night. See https://bugreports.qt.io/browse/QTQAINFRA-2273 , Angle building timeout (on Windows) > > So I suggest not to restage in above areas at least before the issue got fixed. > > Best Regards, > Liang > >> On 12 Oct 2018, at 07:16, Tony Sarajärvi wrote: >> >> Wow… ok it took longer than expected (as usual). Not only did we have to remove snapshots, we also had to run unmap on the Compellent, so this whole thing took a while. But nothing got lost, thanks to a last minute intervention. >> >> So, the CI is up again, and good luck stage storming it >> >> -Tony >> >> From: Tony Sarajärvi >> Sent: torstai 11. lokakuuta 2018 14.49 >> To: development at qt-project.org >> Subject: Shutting down the CI right now! >> >> Hi >> >> Due to a lot of changes while developing and snapshots being huge, our Compellent backend is nearly 100% full. I’ll shut down the CI for a few hours to avoid everything breaking due to lack of disk space. We’ll be back after snapshots have been deleted. >> >> -Tony >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > From boud at valdyas.org Fri Oct 12 12:48:15 2018 From: boud at valdyas.org (boud at valdyas.org) Date: Fri, 12 Oct 2018 12:48:15 +0200 Subject: [Development] QButtonGroup: When the "right thing to do" is absolutely the wrong thing to do Message-ID: <3db9d6206291f45e7e6e06318eeab058@valdyas.org> So, there's this commit: https://git.qt.io/consulting-usa/qtbase-xcb-rendering/commit/69335920f724d2d4a49924f373c4fef57c942831 " Move QButtonGroup implementation from qabstractbutton.cpp to qbuttongroup.cpp Because it's the right thing to do. Needed to introduce qbuttongroup_p.h because QAbstractButton likes to poke around in QButtonGroup's private parts. Fixed includes of qabstractbutton_p.h so it compiles on it's own. Change-Id: Ic7725277d2419754de273b2abd4790476edd0eb4 Reviewed-by: Olivier Goffart's avatarOlivier Goffart (Woboq GmbH) " Which of course breaks source compatibility. It's bad enough to have to adapt one's codebase; but this also makes it impossible to bisect code when Qt 5.11 is installed that had to be adapted. I'm constantly running into this problem. Would it be too much to ask that things like this just never ever happen again? Boudewijn From giuseppe.dangelo at kdab.com Fri Oct 12 12:59:46 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Fri, 12 Oct 2018 12:59:46 +0200 Subject: [Development] QButtonGroup: When the "right thing to do" is absolutely the wrong thing to do In-Reply-To: <3db9d6206291f45e7e6e06318eeab058@valdyas.org> References: <3db9d6206291f45e7e6e06318eeab058@valdyas.org> Message-ID: <585dc3c3-a0fe-f630-18df-bb8a5a4bc0db@kdab.com> Hello, Il 12/10/2018 12:48, boud at valdyas.org ha scritto: > Which of course breaks source compatibility. It's bad enough to have to > adapt one's codebase; but this also makes it impossible to bisect code > when Qt 5.11 is installed that had to be adapted. > > I'm constantly running into this problem. Would it be too much to ask > that things like this just never ever happen again? In what way did that commit break source compatibility? Thanks, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From ritt.ks at gmail.com Fri Oct 12 14:31:33 2018 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Fri, 12 Oct 2018 15:31:33 +0300 Subject: [Development] QButtonGroup: When the "right thing to do" is absolutely the wrong thing to do In-Reply-To: <585dc3c3-a0fe-f630-18df-bb8a5a4bc0db@kdab.com> References: <3db9d6206291f45e7e6e06318eeab058@valdyas.org> <585dc3c3-a0fe-f630-18df-bb8a5a4bc0db@kdab.com> Message-ID: It didn't. Regards, Konstantin пт, 12 окт. 2018 г. в 13:59, Giuseppe D'Angelo via Development < development at qt-project.org>: > Hello, > > Il 12/10/2018 12:48, boud at valdyas.org ha scritto: > > Which of course breaks source compatibility. It's bad enough to have to > > adapt one's codebase; but this also makes it impossible to bisect code > > when Qt 5.11 is installed that had to be adapted. > > > > I'm constantly running into this problem. Would it be too much to ask > > that things like this just never ever happen again? > > In what way did that commit break source compatibility? > > Thanks, > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Fri Oct 12 15:44:51 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 12 Oct 2018 16:44:51 +0300 Subject: [Development] Qt Android Service Message-ID: Hi guys. Does anybody tried to create and start the Android Service using Qt? I tried this example: * https://github.com/bbernhard/qtandroidservices_example , and also have read this reccomendations from KDAB: * https://www.kdab.com/qt-android-create-android-service-using-qt/ But a service do not start at all. I use Qt 5.11.2. Is it possible at all, or it broken as usual in Qt? BR, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.svetkin at gmail.com Fri Oct 12 15:49:50 2018 From: mikhail.svetkin at gmail.com (Mikhail Svetkin) Date: Fri, 12 Oct 2018 15:49:50 +0200 Subject: [Development] Qt Android Service In-Reply-To: References: Message-ID: I have tried a year ago. It was ok, but unfortunately i don't remember version of Qt. Best regards, Mikhail On Fri, 12 Oct 2018 at 15:45, Denis Shienkov wrote: > Hi guys. > > Does anybody tried to create and start the Android Service using Qt? > > I tried this example: > > * https://github.com/bbernhard/qtandroidservices_example , > > and also have read this reccomendations from KDAB: > > * https://www.kdab.com/qt-android-create-android-service-using-qt/ > > But a service do not start at all. > > I use Qt 5.11.2. > > Is it possible at all, or it broken as usual in Qt? > > BR, > Denis > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathias at taschenorakel.de Fri Oct 12 15:57:35 2018 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Fri, 12 Oct 2018 15:57:35 +0200 Subject: [Development] QButtonGroup: When the "right thing to do" is absolutely the wrong thing to do In-Reply-To: <3db9d6206291f45e7e6e06318eeab058@valdyas.org> References: <3db9d6206291f45e7e6e06318eeab058@valdyas.org> Message-ID: <8759d958-5114-8f8e-0019-37f8b9d89ac8@taschenorakel.de> Hi Boudewijn, these kind of refactorings are neccessary to keep code maintainable I fear. Anyway, it seems like you are maintaining a bunch of custom patches on top of Qt? How about reducing your maintainance burden by upstreaming them? Qt would benefit from bugfixes and new features. You would benefit from reduced workload and responsiblity? This sounds like win-win to me, do you agree? Ciao, Mathias Am 12.10.2018 um 12:48 schrieb boud at valdyas.org: > So, there's this commit: > > https://git.qt.io/consulting-usa/qtbase-xcb-rendering/commit/69335920f724d2d4a49924f373c4fef57c942831 > > > " > Move QButtonGroup implementation from qabstractbutton.cpp to > qbuttongroup.cpp > > Because it's the right thing to do. > > Needed to introduce qbuttongroup_p.h because QAbstractButton > likes to poke around in QButtonGroup's private parts. > > Fixed includes of qabstractbutton_p.h so it compiles on it's > own. > > Change-Id: Ic7725277d2419754de273b2abd4790476edd0eb4 > Reviewed-by: Olivier Goffart's avatarOlivier Goffart (Woboq GmbH) > > > " > > Which of course breaks source compatibility. It's bad enough to have > to adapt one's codebase; but this also makes it impossible to bisect > code when Qt 5.11 is installed that had to be adapted. > > I'm constantly running into this problem. Would it be too much to ask > that things like this just never ever happen again? > > > Boudewijn > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jhihn at gmx.com Fri Oct 12 15:58:12 2018 From: jhihn at gmx.com (Jason H) Date: Fri, 12 Oct 2018 15:58:12 +0200 Subject: [Development] Qt Android Service In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Fri Oct 12 16:03:58 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 12 Oct 2018 17:03:58 +0300 Subject: [Development] Qt Android Service In-Reply-To: References: Message-ID: Hmm... Maybe anybody can share a *real* simple working example on Qt 5.11? (with sources)? :) пт, 12 окт. 2018 г. в 16:58, Jason H : > I would not attribute this to Qt without a thorough investigation. My only > use of serves on Android was a Qt app with a normal Android service. As I > understand it, you can't have both Qt App and service in the same app. > Something simple like a manifest error is more likely the issue, but > without more detail, helping is impossible. > > > *Sent:* Friday, October 12, 2018 at 9:49 AM > *From:* "Mikhail Svetkin" > *To:* denis.shienkov at gmail.com > *Cc:* development at qt-project.org > *Subject:* Re: [Development] Qt Android Service > I have tried a year ago. It was ok, but unfortunately i don't remember > version of Qt. > > Best regards, > Mikhail > > On Fri, 12 Oct 2018 at 15:45, Denis Shienkov > wrote: > >> Hi guys. >> >> Does anybody tried to create and start the Android Service using Qt? >> >> I tried this example: >> >> * https://github.com/bbernhard/qtandroidservices_example , >> >> and also have read this reccomendations from KDAB: >> >> * https://www.kdab.com/qt-android-create-android-service-using-qt/ >> >> But a service do not start at all. >> >> I use Qt 5.11.2. >> >> Is it possible at all, or it broken as usual in Qt? >> >> BR, >> Denis >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Fri Oct 12 21:11:43 2018 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Fri, 12 Oct 2018 15:11:43 -0400 Subject: [Development] Improving CMake support for static builds Message-ID: <1539371503.5597.57.camel@kitware.com> Hello everyone, New Qt developer here. I'm trying to improve Qt's support for static builds using CMake - specifically, encoding transitive dependencies in the *Config.cmake files. I see that these files already have inter- module dependencies encoded in the exported targets' INTERFACE_LINK_LIBRARIES property, but there is no information for the flags needed to link against system libraries (freetype, harfbuzz, etc.) With dynamic builds, this isn't an issue, because the Qt modules themselves link against these libraries. However, static builds need this information to generate a fully linked binary. I've started a patch to add this support, but I'm not very familiar with Qt's buildsystem, and I was hoping someone could help me figure out how to get the information that I need. The start of my patch is below: ------------------------------------------------------------- diff --git a/mkspecs/features/create_cmake.prf b/mkspecs/features/create_cmake.prf index 2ed708e..2d5ab55 100644 --- a/mkspecs/features/create_cmake.prf +++ b/mkspecs/features/create_cmake.prf @@ -180,6 +180,7 @@ CMAKE_MKSPEC = $$[QMAKE_XSPEC]  sorted_deps = $$sort_depends(QT.$${MODULE}.depends, QT.)  mod_deps =  lib_deps = +mod_link_flags =  aux_mod_deps =  aux_lib_deps =  # Until CMake 3.0 is the minimum requirement of Qt 5, we need to filter @@ -197,6 +198,7 @@ for (dep, sorted_deps) {  }  CMAKE_MODULE_DEPS = $$join(mod_deps, ";")  CMAKE_QT5_MODULE_DEPS = $$join(lib_deps, ";") +CMAKE_MODULE_LINK_FLAGS = $$join(mod_link_flags, ";")  CMAKE_INTERFACE_MODULE_DEPS = $$join(aux_mod_deps, ";")  CMAKE_INTERFACE_QT5_MODULE_DEPS = $$join(aux_lib_deps, ";")   diff --git a/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in b/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in index 3ed6dd5..a320902 100644 --- a/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in +++ b/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in @@ -64,6 +64,11 @@ macro(_populate_$${CMAKE_MODULE_NAME}_target_properties Configuration LIB_LOCATI  !!IF !isEmpty(CMAKE_LIB_SONAME)          \"IMPORTED_SONAME_${Configuration}\" \"$${CMAKE_LIB_SONAME}\"  !!ENDIF +!!IF !isEmpty(CMAKE_STATIC_TYPE) +!!IF !isEmpty(CMAKE_MODULE_LINK_FLAGS) +        \"INTERFACE_LINK_OPTIONS\" \"${_Qt5$${CMAKE_MODULE_NAME}_LIB_LINK_FLAGS}\" +!!ENDIF +!!ENDIF          # For backward compatibility with CMake < 2.8.12          \"IMPORTED_LINK_INTERFACE_LIBRARIES_${Configuration}\" \"${_Qt5$${CMAKE_MODULE_NAME}_LIB_DEPENDENCIES}\"      ) @@ -215,6 +220,10 @@ if (NOT TARGET Qt5::$${CMAKE_MODULE_NAME})  !!ENDIF    !!IF !isEmpty(CMAKE_STATIC_TYPE) +!!IF !isEmpty(CMAKE_MODULE_LINK_FLAGS) +    set(_Qt5$${CMAKE_MODULE_NAME}_LIB_LINK_FLAGS \"$${CMAKE_MODULE_LINK_FLAGS}\") + +!!ENDIF      add_library(Qt5::$${CMAKE_MODULE_NAME} STATIC IMPORTED)      set_property(TARGET Qt5::$${CMAKE_MODULE_NAME} PROPERTY IMPORTED_LINK_INTERFACE_LANGUAGES "CXX")  !!ELSE ------------------------------------------------------------- I've figured out how to pass information into Qt5BasicConfig.cmake.in from create_cmake.prf, but I'm not sure where to get the link flags that need to be passed in. Any advice would be appreciated. Kyle From mwoehlke.floss at gmail.com Fri Oct 12 21:23:18 2018 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 12 Oct 2018 15:23:18 -0400 Subject: [Development] Improving CMake support for static builds In-Reply-To: <1539371503.5597.57.camel@kitware.com> References: <1539371503.5597.57.camel@kitware.com> Message-ID: On 12/10/2018 15.11, Kyle Edwards wrote: > New Qt developer here. I'm trying to improve Qt's support for static > builds using CMake [...] See also https://bugreports.qt.io/browse/QTBUG-38913. This has been languishing for entirely too long; it will be great if someone can finally fix it! Hopefully someone with more qmake knowledge can help? -- Matthew From jeanmichael.celerier at gmail.com Fri Oct 12 20:32:10 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Fri, 12 Oct 2018 20:32:10 +0200 Subject: [Development] Improving CMake support for static builds In-Reply-To: <1539371503.5597.57.camel@kitware.com> References: <1539371503.5597.57.camel@kitware.com> Message-ID: > but there is no information for the flags needed to link against system libraries (freetype, harfbuzz, etc.) it would be so nice to add them ! currently I have to use the following chthonic horror: https://github.com/OSSIA/score/blob/master/base/app/StaticApp.cmake I think that in Qt the pkg-config files are generated by a perl script, maybe the same could be used for static builds ? ------- Jean-Michaël Celerier http://www.jcelerier.name On Fri, Oct 12, 2018 at 9:12 PM Kyle Edwards wrote: > Hello everyone, > > New Qt developer here. I'm trying to improve Qt's support for static > builds using CMake - specifically, encoding transitive dependencies in > the *Config.cmake files. I see that these files already have inter- > module dependencies encoded in the exported targets' > INTERFACE_LINK_LIBRARIES property, but there is no information for the > flags needed to link against system libraries (freetype, harfbuzz, > etc.) > > With dynamic builds, this isn't an issue, because the Qt modules > themselves link against these libraries. However, static builds need > this information to generate a fully linked binary. I've started a > patch to add this support, but I'm not very familiar with Qt's > buildsystem, and I was hoping someone could help me figure out how to > get the information that I need. The start of my patch is below: > > ------------------------------------------------------------- > > diff --git a/mkspecs/features/create_cmake.prf > b/mkspecs/features/create_cmake.prf > index 2ed708e..2d5ab55 100644 > --- a/mkspecs/features/create_cmake.prf > +++ b/mkspecs/features/create_cmake.prf > @@ -180,6 +180,7 @@ CMAKE_MKSPEC = $$[QMAKE_XSPEC] > sorted_deps = $$sort_depends(QT.$${MODULE}.depends, QT.) > mod_deps = > lib_deps = > +mod_link_flags = > aux_mod_deps = > aux_lib_deps = > # Until CMake 3.0 is the minimum requirement of Qt 5, we need to > filter > @@ -197,6 +198,7 @@ for (dep, sorted_deps) { > } > CMAKE_MODULE_DEPS = $$join(mod_deps, ";") > CMAKE_QT5_MODULE_DEPS = $$join(lib_deps, ";") > +CMAKE_MODULE_LINK_FLAGS = $$join(mod_link_flags, ";") > CMAKE_INTERFACE_MODULE_DEPS = $$join(aux_mod_deps, ";") > CMAKE_INTERFACE_QT5_MODULE_DEPS = $$join(aux_lib_deps, ";") > > diff --git a/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in > b/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in > index 3ed6dd5..a320902 100644 > --- a/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in > +++ b/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in > @@ -64,6 +64,11 @@ > macro(_populate_$${CMAKE_MODULE_NAME}_target_properties Configuration > LIB_LOCATI > !!IF !isEmpty(CMAKE_LIB_SONAME) > \"IMPORTED_SONAME_${Configuration}\" \"$${CMAKE_LIB_SONAME}\" > !!ENDIF > +!!IF !isEmpty(CMAKE_STATIC_TYPE) > +!!IF !isEmpty(CMAKE_MODULE_LINK_FLAGS) > + \"INTERFACE_LINK_OPTIONS\" > \"${_Qt5$${CMAKE_MODULE_NAME}_LIB_LINK_FLAGS}\" > +!!ENDIF > +!!ENDIF > # For backward compatibility with CMake < 2.8.12 > \"IMPORTED_LINK_INTERFACE_LIBRARIES_${Configuration}\" > \"${_Qt5$${CMAKE_MODULE_NAME}_LIB_DEPENDENCIES}\" > ) > @@ -215,6 +220,10 @@ if (NOT TARGET Qt5::$${CMAKE_MODULE_NAME}) > !!ENDIF > > !!IF !isEmpty(CMAKE_STATIC_TYPE) > +!!IF !isEmpty(CMAKE_MODULE_LINK_FLAGS) > + set(_Qt5$${CMAKE_MODULE_NAME}_LIB_LINK_FLAGS > \"$${CMAKE_MODULE_LINK_FLAGS}\") > + > +!!ENDIF > add_library(Qt5::$${CMAKE_MODULE_NAME} STATIC IMPORTED) > set_property(TARGET Qt5::$${CMAKE_MODULE_NAME} PROPERTY > IMPORTED_LINK_INTERFACE_LANGUAGES "CXX") > !!ELSE > > ------------------------------------------------------------- > > I've figured out how to pass information into Qt5BasicConfig.cmake.in > from create_cmake.prf, but I'm not sure where to get the link flags > that need to be passed in. Any advice would be appreciated. > > Kyle > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Fri Oct 12 22:35:34 2018 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Fri, 12 Oct 2018 16:35:34 -0400 Subject: [Development] Improving CMake support for static builds In-Reply-To: References: <1539371503.5597.57.camel@kitware.com> Message-ID: <1539376534.5597.61.camel@kitware.com> On Fri, 2018-10-12 at 20:32 +0200, Jean-Michaël Celerier wrote: > it would be so nice to add them ! currently I have to use the > following chthonic horror:  https://github.com/OSSIA/score/blob/maste > r/base/app/StaticApp.cmake Yep, this is exactly what I'm trying to fix! Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Oct 12 23:37:39 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 12 Oct 2018 14:37:39 -0700 Subject: [Development] Improving CMake support for static builds In-Reply-To: References: <1539371503.5597.57.camel@kitware.com> Message-ID: <7063141.XT6IMc8xfF@tjmaciei-mobl1> On Friday, 12 October 2018 11:32:10 PDT Jean-Michaël Celerier wrote: > > but there is no information for the > > flags needed to link against system libraries (freetype, harfbuzz, > etc.) > > it would be so nice to add them ! currently I have to use the following > chthonic horror: > https://github.com/OSSIA/score/blob/master/base/app/StaticApp.cmake > > I think that in Qt the pkg-config files are generated by a perl script, > maybe the same could be used for static builds ? syncqt only generates the headers and the .pri files that qmake uses to find the headers. The pkg-config files and the libtool files are generated by qmake itself. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From boud at valdyas.org Sat Oct 13 09:02:02 2018 From: boud at valdyas.org (Boudewijn Rempt) Date: Sat, 13 Oct 2018 09:02:02 +0200 Subject: [Development] QButtonGroup: When the "right thing to do" is absolutely the wrong thing to do In-Reply-To: <8759d958-5114-8f8e-0019-37f8b9d89ac8@taschenorakel.de> References: <3db9d6206291f45e7e6e06318eeab058@valdyas.org> <8759d958-5114-8f8e-0019-37f8b9d89ac8@taschenorakel.de> Message-ID: <2732330.kgu87bYErS@boud-thinkpad-t470p> On vrijdag 12 oktober 2018 15:57:35 CEST Mathias Hasselmann wrote: > Hi Boudewijn, > > these kind of refactorings are neccessary to keep code maintainable I fear. Well... If code stops building from Qt 5 to another Qt 5, that means that thousands of projects have to change their code. Thousands of projects have to struggle. Is that really worth it? I always thought Qt came with a firm promise not to break source compatibility except in new, major releases. > Anyway, it seems like you are maintaining a bunch of custom patches on > top of Qt? How about reducing your maintainance burden by upstreaming > them? Qt would benefit from bugfixes and new features. You would benefit > from reduced workload and responsiblity? This sounds like win-win to me, > do you agree? Apart from one patch that disables wintab support because we've got our own, those patches pretty much all come from Qt's bug tracker. We did try to upstream the one big patch that made the opengl painter engine work again on macOS, and that happened in the end. -- https://www.krita.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From boud at valdyas.org Sat Oct 13 09:03:08 2018 From: boud at valdyas.org (Boudewijn Rempt) Date: Sat, 13 Oct 2018 09:03:08 +0200 Subject: [Development] QButtonGroup: When the "right thing to do" is absolutely the wrong thing to do In-Reply-To: References: <3db9d6206291f45e7e6e06318eeab058@valdyas.org> <585dc3c3-a0fe-f630-18df-bb8a5a4bc0db@kdab.com> Message-ID: <2467385.fuYmosCuWv@boud-thinkpad-t470p> On vrijdag 12 oktober 2018 14:31:33 CEST Konstantin Ritt wrote: > It didn't. Then what else made it necessary to suddenly add lots of #include lines? -- https://www.krita.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From giuseppe.dangelo at kdab.com Sat Oct 13 13:39:55 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Sat, 13 Oct 2018 13:39:55 +0200 Subject: [Development] QButtonGroup: When the "right thing to do" is absolutely the wrong thing to do In-Reply-To: <2467385.fuYmosCuWv@boud-thinkpad-t470p> References: <3db9d6206291f45e7e6e06318eeab058@valdyas.org> <585dc3c3-a0fe-f630-18df-bb8a5a4bc0db@kdab.com> <2467385.fuYmosCuWv@boud-thinkpad-t470p> Message-ID: Hi, Il 13/10/2018 09:03, Boudewijn Rempt ha scritto: > Then what else made it necessary to suddenly add lots of #include > lines? I still don't get it, how is that possible? * If we're talking about a SIC internal to Qt, that is, some other part of Qt not building because of that change, that of course has to be fixed as part of the change itself (or immediately after). The fact that we're talking of a patch landed 2½ years ago makes me think this is not the case. * If we're talking about a SIC against user code using public APIs, the commit does not touch any public header, so I fail to see how it could break anything. * If we're talking about a SIC against user code using private APIs, or some 3rd party patches on top of Qt, they're obviously not covered by any source compatibility promise. While the above is true in general, note that for the _specific_ case of breaking includes, Qt does indeed not guarantee source compatibility. You're not supposed to rely on transitive inclusions through Qt public headers; if you need something, you must include the right header. This has always been the case; and this makes Qt free of add/remove/modify include from its public headers (e.g. turn an unnecessary inclusion into a forward declaration). The policy of which source incompatible changes are allowed in Qt _public_ APIs is documented in QUIP 6: > https://code.qt.io/cgit/meta/quips.git/tree/quip-0006.rst My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From olivier at woboq.com Mon Oct 15 09:46:14 2018 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 15 Oct 2018 09:46:14 +0200 Subject: [Development] QButtonGroup: When the "right thing to do" is absolutely the wrong thing to do In-Reply-To: <2467385.fuYmosCuWv@boud-thinkpad-t470p> References: <3db9d6206291f45e7e6e06318eeab058@valdyas.org> <585dc3c3-a0fe-f630-18df-bb8a5a4bc0db@kdab.com> <2467385.fuYmosCuWv@boud-thinkpad-t470p> Message-ID: On 10/13/18 9:03 AM, Boudewijn Rempt wrote: > On vrijdag 12 oktober 2018 14:31:33 CEST Konstantin Ritt wrote: >> It didn't. > > Then what else made it necessary to suddenly add lots of #include > lines? Maybe that was commit 000c76ada5cc21479fc479be16a7507fed6490f8 ? The commit you mentioned does not touch any public headers and was already in Qt 5.6. So unless you include private headers, in which case you are on your own, there was no way it causes a source incompatible change. No wonder why the replies you got were skeptical. You could have stated directly what source incompatibilities you have seen. Coming back to the actual problem of missing includes, this is indeed not the first time that Qt broke source compatibility in that regards. (last time i remember, it was requiring to include QDataStream, in Qt 5.5) According to QUIP-6, 'Removing an include from a public header file' is an acceptable source incompatible change. The rationale is that you should not rely on indirect includes. IMHO, this is a bit unfortunate, as this causes indeed source incompatible change that makes it harder to upgrade Qt. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From Friedemann.Kleint at qt.io Mon Oct 15 10:31:10 2018 From: Friedemann.Kleint at qt.io (Friedemann Kleint) Date: Mon, 15 Oct 2018 08:31:10 +0000 Subject: [Development] =?utf-8?q?Nominating_Cristi=C3=A1n_Maureira-Fredes?= =?utf-8?q?_for_approver?= In-Reply-To: References: Message-ID: +1 from me -- Friedemann Kleint The Qt Company GmbH From jani.heikkinen at qt.io Tue Oct 16 12:48:48 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 16 Oct 2018 10:48:48 +0000 Subject: [Development] Qt 5.12 beta2 released Message-ID: Hi all, We have published Qt 5.12 beta2 today. As earlier you can get it via online installer. Delta to beta1 attached. Please test the packages now & report all findings to Jira. Also make sure all release blockers can be found from release blocker list (https://bugreports.qt.io/issues/?filter=19961). It is really time to test the packages now; plan is to release Qt 5.12.0 final at the end of November. br, Jani -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: delta_qt5.12.0-beta1-qt5.12.0-beta1.txt URL: From kyle.edwards at kitware.com Tue Oct 16 18:02:21 2018 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Tue, 16 Oct 2018 12:02:21 -0400 Subject: [Development] Improving CMake support for static builds In-Reply-To: <7063141.XT6IMc8xfF@tjmaciei-mobl1> References: <1539371503.5597.57.camel@kitware.com> <7063141.XT6IMc8xfF@tjmaciei-mobl1> Message-ID: <1539705741.5597.83.camel@kitware.com> On Fri, 2018-10-12 at 14:37 -0700, Thiago Macieira wrote: > On Friday, 12 October 2018 11:32:10 PDT Jean-Michaël Celerier wrote: > > > > > > > >  but there is no information for the > > flags needed to link against system libraries (freetype, harfbuzz, > > etc.) > > > > it would be so nice to add them ! currently I have to use the > > following > > chthonic horror: > > https://github.com/OSSIA/score/blob/master/base/app/StaticApp.cmake > > > > I think that in Qt the pkg-config files are generated by a perl > > script, > > maybe the same could be used for static builds ? > syncqt only generates the headers and the .pri files that qmake uses > to find  > the headers. > > The pkg-config files and the libtool files are generated by qmake > itself. > I've done a lot of experimentation, and I've gotten my code to look like this: ------------------------------------------------------------- diff --git a/mkspecs/features/create_cmake.prf b/mkspecs/features/create_cmake.prf index 2ed708e..abab6ea 100644 --- a/mkspecs/features/create_cmake.prf +++ b/mkspecs/features/create_cmake.prf @@ -180,6 +180,8 @@ CMAKE_MKSPEC = $$[QMAKE_XSPEC]  sorted_deps = $$sort_depends(QT.$${MODULE}.depends, QT.)  mod_deps =  lib_deps = +mod_link_flags = +mod_libs =  aux_mod_deps =  aux_lib_deps =  # Until CMake 3.0 is the minimum requirement of Qt 5, we need to filter @@ -195,8 +197,19 @@ for (dep, sorted_deps) {          aux_lib_deps += Qt5::$$cdep      }  } +for (lib, QT.$${MODULE}_private.libraries) { +    for (flag, QMAKE_LIBS_$$upper($${lib})) { +        contains(flag, "^-l.*$") { +            mod_libs *= $$str_member($$flag, 2, -1) +        } else { +            mod_link_flags *= flag +        } +    } +}  CMAKE_MODULE_DEPS = $$join(mod_deps, ";")  CMAKE_QT5_MODULE_DEPS = $$join(lib_deps, ";") +CMAKE_MODULE_LINK_FLAGS = $$join(mod_link_flags, ";") +CMAKE_MODULE_LIBS = $$join(mod_libs, ";")  CMAKE_INTERFACE_MODULE_DEPS = $$join(aux_mod_deps, ";")  CMAKE_INTERFACE_QT5_MODULE_DEPS = $$join(aux_lib_deps, ";")   diff --git a/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in b/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in index 3ed6dd5..444bf0f 100644 --- a/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in +++ b/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in @@ -67,6 +67,16 @@ macro(_populate_$${CMAKE_MODULE_NAME}_target_properties Configuration LIB_LOCATI          # For backward compatibility with CMake < 2.8.12          \"IMPORTED_LINK_INTERFACE_LIBRARIES_${Configuration}\" \"${_Qt5$${CMAKE_MODULE_NAME}_LIB_DEPENDENCIES}\"      ) +!!IF !isEmpty(CMAKE_STATIC_TYPE) +!!IF !isEmpty(CMAKE_MODULE_LINK_FLAGS) + +    if(CMAKE_VERSION VERSION_GREATER_EQUAL \"3.13\") +        set_target_properties(Qt5::$${CMAKE_MODULE_NAME} PROPERTIES +            \"INTERFACE_LINK_OPTIONS\" \"${_Qt5$${CMAKE_MODULE_NAME}_LINK_FLAGS}\" +        ) +    endif() +!!ENDIF +!!ENDIF    !!IF !isEmpty(CMAKE_WINDOWS_BUILD)  !!IF isEmpty(CMAKE_LIB_DIR_IS_ABSOLUTE) @@ -215,6 +225,26 @@ if (NOT TARGET Qt5::$${CMAKE_MODULE_NAME})  !!ENDIF    !!IF !isEmpty(CMAKE_STATIC_TYPE) +!!IF !isEmpty(CMAKE_MODULE_LINK_FLAGS) +    set(_Qt5$${CMAKE_MODULE_NAME}_LINK_FLAGS \"$${CMAKE_MODULE_LINK_FLAGS}\") + +!!ENDIF +!!IF !isEmpty(CMAKE_MODULE_LIBS) +    set(_Qt5$${CMAKE_MODULE_NAME}_LIBS \"$${CMAKE_MODULE_LIBS}\") + +    foreach(_l ${_Qt5$${CMAKE_MODULE_NAME}_LIBS}) +        find_library(_Qt5$${CMAKE_MODULE_NAME}_${_l}_lpath ${_l}) +        if(_Qt5$${CMAKE_MODULE_NAME}_${_l}_lpath) +            set(_Qt5$${CMAKE_MODULE_NAME}_LIB_DEPENDENCIES +                ${_Qt5$${CMAKE_MODULE_NAME}_LIB_DEPENDENCIES} +                ${_Qt5$${CMAKE_MODULE_NAME}_${_l}_lpath} +            ) +        else() +            message(FATAL_ERROR \"Could not find -l${_l}\") +        endif() +    endforeach() + +!!ENDIF      add_library(Qt5::$${CMAKE_MODULE_NAME} STATIC IMPORTED)      set_property(TARGET Qt5::$${CMAKE_MODULE_NAME} PROPERTY IMPORTED_LINK_INTERFACE_LANGUAGES "CXX")  !!ELSE ------------------------------------------------------------- So anything that links against a static Qt module in CMake will inherit all of the "libs" that the module depends on. However, the downstream targets still aren't receiving crucial libraries like -lpthread, which is still causing link errors. Looking through the qmake scripts, it looks like "thread" is a "feature" rather than a "lib", and I'm not sure what would be the best approach to include "features" in the CMake script. Would someone who's more familiar with the workings of the qmake scripts be able to assist me here? Kyle From mark.dewit at iesve.com Wed Oct 17 09:10:01 2018 From: mark.dewit at iesve.com (Mark De Wit) Date: Wed, 17 Oct 2018 07:10:01 +0000 Subject: [Development] Qt 5.12 beta2 released In-Reply-To: References: Message-ID: What is the criteria for blocker? It would be great if WebEngine were usable again for people behind proxies (my last usable Qt release is 5.9)... https://bugreports.qt.io/browse/QTBUG-69281 is marked as P1 but not targeted at 5.12? Kind regards, Mark -----Original Message----- From: Development On Behalf Of Jani Heikkinen Sent: 16 October 2018 11:49 To: releasing at qt-project.org Cc: development at qt-project.org Subject: [Development] Qt 5.12 beta2 released Hi all, We have published Qt 5.12 beta2 today. As earlier you can get it via online installer. Delta to beta1 attached. Please test the packages now & report all findings to Jira. Also make sure all release blockers can be found from release blocker list (https://bugreports.qt.io/issues/?filter=19961). It is really time to test the packages now; plan is to release Qt 5.12.0 final at the end of November. br, Jani From Kai.Koehne at qt.io Wed Oct 17 09:14:17 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Wed, 17 Oct 2018 07:14:17 +0000 Subject: [Development] Qt 5.12 beta2 released In-Reply-To: References: Message-ID: > -----Original Message----- > From: Development project.org> On Behalf Of Mark De Wit > Sent: Wednesday, October 17, 2018 9:10 AM > To: development at qt-project.org > Subject: Re: [Development] Qt 5.12 beta2 released > > What is the criteria for blocker? It would be great if WebEngine were usable > again for people behind proxies (my last usable Qt release is 5.9)... > > https://bugreports.qt.io/browse/QTBUG-69281 is marked as P1 but not > targeted at 5.12? For bugs, we do set the 'fix version' only for bugs that will potentially delay the release. Anyhow, the bug is being worked on, and will most likely be fixed both in 5.11 branch and for 5.12.0. You can already give the patches a try if you want to 😊 Kai From michal.klocek at qt.io Wed Oct 17 10:32:27 2018 From: michal.klocek at qt.io (Michal Klocek) Date: Wed, 17 Oct 2018 08:32:27 +0000 Subject: [Development] Qt 5.12 beta2 released In-Reply-To: References: Message-ID: I am sorry for delay, I know it is important issue so marked it for 5.11.3 now. Patches have to go though coin still, which may take a while. Br Michal On 10/17/2018 09:10 AM, Mark De Wit wrote: > What is the criteria for blocker? It would be great if WebEngine were usable again for people behind proxies (my last usable Qt release is 5.9)... > > https://bugreports.qt.io/browse/QTBUG-69281 is marked as P1 but not targeted at 5.12? > > Kind regards, > Mark > > -----Original Message----- > From: Development On Behalf Of Jani Heikkinen > Sent: 16 October 2018 11:49 > To: releasing at qt-project.org > Cc: development at qt-project.org > Subject: [Development] Qt 5.12 beta2 released > > Hi all, > > We have published Qt 5.12 beta2 today. As earlier you can get it via online installer. Delta to beta1 attached. > > Please test the packages now & report all findings to Jira. Also make sure all release blockers can be found from release blocker list (https://bugreports.qt.io/issues/?filter=19961). It is really time to test the packages now; plan is to release Qt 5.12.0 final at the end of November. > > br, > Jani > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From mark.dewit at iesve.com Wed Oct 17 11:51:01 2018 From: mark.dewit at iesve.com (Mark De Wit) Date: Wed, 17 Oct 2018 09:51:01 +0000 Subject: [Development] Qt 5.12 beta2 released In-Reply-To: References: Message-ID: It's great to see a resolution so close... I'll see if I can find time to try the patch locally. Really appreciate the work going into it! Kind regards, Mark -----Original Message----- From: Michal Klocek Sent: 17 October 2018 09:32 To: Mark De Wit ; development at qt-project.org Subject: Re: [Development] Qt 5.12 beta2 released I am sorry for delay, I know it is important issue so marked it for 5.11.3 now. Patches have to go though coin still, which may take a while. Br Michal On 10/17/2018 09:10 AM, Mark De Wit wrote: > What is the criteria for blocker? It would be great if WebEngine were usable again for people behind proxies (my last usable Qt release is 5.9)... > > https://bugreports.qt.io/browse/QTBUG-69281 is marked as P1 but not targeted at 5.12? > > Kind regards, > Mark > > -----Original Message----- > From: Development On Behalf Of Jani Heikkinen > Sent: 16 October 2018 11:49 > To: releasing at qt-project.org > Cc: development at qt-project.org > Subject: [Development] Qt 5.12 beta2 released > > Hi all, > > We have published Qt 5.12 beta2 today. As earlier you can get it via online installer. Delta to beta1 attached. > > Please test the packages now & report all findings to Jira. Also make sure all release blockers can be found from release blocker list (https://bugreports.qt.io/issues/?filter=19961). It is really time to test the packages now; plan is to release Qt 5.12.0 final at the end of November. > > br, > Jani > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From jani.heikkinen at qt.io Wed Oct 17 12:19:02 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 17 Oct 2018 10:19:02 +0000 Subject: [Development] Qt 5.12 beta2 released In-Reply-To: References: Message-ID: > -----Original Message----- > From: Development project.org> On Behalf Of Mark De Wit > Sent: keskiviikko 17. lokakuuta 2018 10.10 > To: development at qt-project.org > Subject: Re: [Development] Qt 5.12 beta2 released > > What is the criteria for blocker? There isn't exact definition for release blocker. Everyone can propose (by sending a mail to me or adding release in Fix Version(s) -field in Jira) one as a release blocker and at the end it is my call (of course with module maintainers etc) if the issue is a release blocker or not. br Jani From olszak.tomasz at gmail.com Wed Oct 17 17:59:26 2018 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Wed, 17 Oct 2018 17:59:26 +0200 Subject: [Development] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI? Message-ID: Hi, I would like just to ensure that I missed something and there is documentation somewhere informing that Linux fonts are rendered *always* in 72 dpi (https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Set_Char_Size) (which makes font.pixelSize inaccurate for regular screens). I found: https://bugreports.qt.io/browse/QTBUG-8890 which fixes the problem but it was rejected. I see the default 72 dpi is also used in current Qt 5.11 FT engine (https://code.woboq.org/qt5/qtbase/src/platformsupport/fontdatabases/freetype/qfontengine_ft.cpp.html#297). Does it surprise any of Qt developers or is it only me? Am I right thinking that when we do following: Rectangle { height: 100 Text {font.pixelSize: 100} } then the relation between height of text and height of rectangle will differ depending on screen dpi (don't have a way to test it currently)? Moreover I'm pretty sure that's the cause I very often use Text.fontSizeMode: Text.Fit because setting pixelSize to height of desired text size never worked correctly :) tl;dr: Is it a bug? From jhihn at gmx.com Wed Oct 17 18:21:24 2018 From: jhihn at gmx.com (Jason H) Date: Wed, 17 Oct 2018 18:21:24 +0200 Subject: [Development] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI? In-Reply-To: References: Message-ID: A pixel is a pixel, regardless of DPI. However things matter when you use point sizes (which assumes 72 points per inch) there are also Screen.devicePixelRatio ( http://doc.qt.io/qt-5/qml-qtquick-window-screen.html#devicePixelRatio-attached-prop ) to contend with. I haven't had to worry about this for some time, so my intel may be out of date. It was a mess around 5.6... I'm assuming the 72 has something to do with the point size, and being able to calculate scaling relative to 72. > Sent: Wednesday, October 17, 2018 at 11:59 AM > From: "Tomasz Olszak" > To: development at qt-project.org > Subject: [Development] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI? > > Hi, > > I would like just to ensure that I missed something and there is > documentation somewhere informing that Linux fonts are rendered > *always* in 72 dpi > (https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Set_Char_Size) > (which makes font.pixelSize inaccurate for regular screens). > > I found: https://bugreports.qt.io/browse/QTBUG-8890 which fixes the > problem but it was rejected. I see the default 72 dpi is also used in > current Qt 5.11 FT engine > (https://code.woboq.org/qt5/qtbase/src/platformsupport/fontdatabases/freetype/qfontengine_ft.cpp.html#297). > > Does it surprise any of Qt developers or is it only me? Am I right > thinking that when we do following: > Rectangle { > height: 100 > Text {font.pixelSize: 100} > } > then the relation between height of text and height of rectangle will > differ depending on screen dpi (don't have a way to test it > currently)? > > Moreover I'm pretty sure that's the cause I very often use > Text.fontSizeMode: Text.Fit because setting pixelSize to height of > desired text size never worked correctly :) > > tl;dr: Is it a bug? > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From olszak.tomasz at gmail.com Wed Oct 17 18:48:17 2018 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Wed, 17 Oct 2018 18:48:17 +0200 Subject: [Development] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI? In-Reply-To: References: Message-ID: If I understand correctly font.pixelSize is actually not the same as pixels user for with and height of items. So if you render rectangle of height e.g 100 pixels on 96 dpi screen, and render Text with font.pixelSize = 100 on 96 screen the iheight of text will be exactly 100 * 72/96 which is exactly 75% of rectangle's height. If you render the same example on screen with 72 dpi they will be exactly the same, on 192 dpi text will be ~37% of rectangle's height. It is just a guess, all my 4 screens I have currently access to are 96 dpi. It is just a guess and if Qt doesn't do something under the hood, FT engine renders fonts in 72 dpi which means that actually on screen text with a font with 100 pixels size is smaller than item with 100 pixel size . That's why I'm asking here not on Interest. Device pixel ratio can be used to calculate screen DPI in Qt Quick - I use it now to correctly render fonts using pixelSize (fontPixelSize factor == Screen.dpi / 72). Pixel size is given by ocring image in 300 dpi. But pixel is pixel and it should work. Text however always was a bit smaller. When I calculated pointSize then the text was correct. I dug more and ended up with conclusions as described above. śr., 17 paź 2018 o 18:21 Jason H napisał(a): > > A pixel is a pixel, regardless of DPI. > > However things matter when you use point sizes (which assumes 72 points per inch) there are also Screen.devicePixelRatio ( http://doc.qt.io/qt-5/qml-qtquick-window-screen.html#devicePixelRatio-attached-prop ) to contend with. I haven't had to worry about this for some time, so my intel may be out of date. It was a mess around 5.6... > > I'm assuming the 72 has something to do with the point size, and being able to calculate scaling relative to 72. > > > > Sent: Wednesday, October 17, 2018 at 11:59 AM > > From: "Tomasz Olszak" > > To: development at qt-project.org > > Subject: [Development] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI? > > > > Hi, > > > > I would like just to ensure that I missed something and there is > > documentation somewhere informing that Linux fonts are rendered > > *always* in 72 dpi > > (https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Set_Char_Size) > > (which makes font.pixelSize inaccurate for regular screens). > > > > I found: https://bugreports.qt.io/browse/QTBUG-8890 which fixes the > > problem but it was rejected. I see the default 72 dpi is also used in > > current Qt 5.11 FT engine > > (https://code.woboq.org/qt5/qtbase/src/platformsupport/fontdatabases/freetype/qfontengine_ft.cpp.html#297). > > > > Does it surprise any of Qt developers or is it only me? Am I right > > thinking that when we do following: > > Rectangle { > > height: 100 > > Text {font.pixelSize: 100} > > } > > then the relation between height of text and height of rectangle will > > differ depending on screen dpi (don't have a way to test it > > currently)? > > > > Moreover I'm pretty sure that's the cause I very often use > > Text.fontSizeMode: Text.Fit because setting pixelSize to height of > > desired text size never worked correctly :) > > > > tl;dr: Is it a bug? > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > From olszak.tomasz at gmail.com Wed Oct 17 19:04:50 2018 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Wed, 17 Oct 2018 19:04:50 +0200 Subject: [Development] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI? In-Reply-To: References: Message-ID: Here you can find and example of what I believe is true: śr., 17 paź 2018 o 18:48 Tomasz Olszak napisał(a): > > If I understand correctly font.pixelSize is actually not the same as > pixels user for with and height of items. So if you render rectangle > of height e.g 100 pixels on 96 dpi screen, and render Text with > font.pixelSize = 100 on 96 screen the iheight of text will be exactly > 100 * 72/96 which is exactly 75% of rectangle's height. If you render > the same example on screen with 72 dpi they will be exactly the same, > on 192 dpi text will be ~37% of rectangle's height. It is just a > guess, all my 4 screens I have currently access to are 96 dpi. It is > just a guess and if Qt doesn't do something under the hood, FT engine > renders fonts in 72 dpi which means that actually on screen text with > a font with 100 pixels size is smaller than item with 100 pixel size . > That's why I'm asking here not on Interest. > > Device pixel ratio can be used to calculate screen DPI in Qt Quick - I > use it now to correctly render fonts using pixelSize (fontPixelSize > factor == Screen.dpi / 72). Pixel size is given by ocring image in 300 > dpi. But pixel is pixel and it should work. Text however always was a > bit smaller. When I calculated pointSize then the text was correct. I > dug more and ended up with conclusions as described above. > > śr., 17 paź 2018 o 18:21 Jason H napisał(a): > > > > A pixel is a pixel, regardless of DPI. > > > > However things matter when you use point sizes (which assumes 72 points per inch) there are also Screen.devicePixelRatio ( http://doc.qt.io/qt-5/qml-qtquick-window-screen.html#devicePixelRatio-attached-prop ) to contend with. I haven't had to worry about this for some time, so my intel may be out of date. It was a mess around 5.6... > > > > I'm assuming the 72 has something to do with the point size, and being able to calculate scaling relative to 72. > > > > > > > Sent: Wednesday, October 17, 2018 at 11:59 AM > > > From: "Tomasz Olszak" > > > To: development at qt-project.org > > > Subject: [Development] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI? > > > > > > Hi, > > > > > > I would like just to ensure that I missed something and there is > > > documentation somewhere informing that Linux fonts are rendered > > > *always* in 72 dpi > > > (https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Set_Char_Size) > > > (which makes font.pixelSize inaccurate for regular screens). > > > > > > I found: https://bugreports.qt.io/browse/QTBUG-8890 which fixes the > > > problem but it was rejected. I see the default 72 dpi is also used in > > > current Qt 5.11 FT engine > > > (https://code.woboq.org/qt5/qtbase/src/platformsupport/fontdatabases/freetype/qfontengine_ft.cpp.html#297). > > > > > > Does it surprise any of Qt developers or is it only me? Am I right > > > thinking that when we do following: > > > Rectangle { > > > height: 100 > > > Text {font.pixelSize: 100} > > > } > > > then the relation between height of text and height of rectangle will > > > differ depending on screen dpi (don't have a way to test it > > > currently)? > > > > > > Moreover I'm pretty sure that's the cause I very often use > > > Text.fontSizeMode: Text.Fit because setting pixelSize to height of > > > desired text size never worked correctly :) > > > > > > tl;dr: Is it a bug? > > > _______________________________________________ > > > Development mailing list > > > Development at qt-project.org > > > http://lists.qt-project.org/mailman/listinfo/development > > > From olszak.tomasz at gmail.com Wed Oct 17 19:06:09 2018 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Wed, 17 Oct 2018 19:06:09 +0200 Subject: [Development] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI? References: Message-ID: Sorry accidental Shift+Enter https://pastebin.com/m2tAgT3f For my screens QScreen::physicalDotsPerInch() return ~92dpi instead of 96 but it is probably due to some platform edid implementation or something like that. śr., 17 paź 2018 o 19:04 Tomasz Olszak napisał(a): > > Here you can find and example of what I believe is true: > > śr., 17 paź 2018 o 18:48 Tomasz Olszak napisał(a): > > > > If I understand correctly font.pixelSize is actually not the same as > > pixels user for with and height of items. So if you render rectangle > > of height e.g 100 pixels on 96 dpi screen, and render Text with > > font.pixelSize = 100 on 96 screen the iheight of text will be exactly > > 100 * 72/96 which is exactly 75% of rectangle's height. If you render > > the same example on screen with 72 dpi they will be exactly the same, > > on 192 dpi text will be ~37% of rectangle's height. It is just a > > guess, all my 4 screens I have currently access to are 96 dpi. It is > > just a guess and if Qt doesn't do something under the hood, FT engine > > renders fonts in 72 dpi which means that actually on screen text with > > a font with 100 pixels size is smaller than item with 100 pixel size . > > That's why I'm asking here not on Interest. > > > > Device pixel ratio can be used to calculate screen DPI in Qt Quick - I > > use it now to correctly render fonts using pixelSize (fontPixelSize > > factor == Screen.dpi / 72). Pixel size is given by ocring image in 300 > > dpi. But pixel is pixel and it should work. Text however always was a > > bit smaller. When I calculated pointSize then the text was correct. I > > dug more and ended up with conclusions as described above. > > > > śr., 17 paź 2018 o 18:21 Jason H napisał(a): > > > > > > A pixel is a pixel, regardless of DPI. > > > > > > However things matter when you use point sizes (which assumes 72 points per inch) there are also Screen.devicePixelRatio ( http://doc.qt.io/qt-5/qml-qtquick-window-screen.html#devicePixelRatio-attached-prop ) to contend with. I haven't had to worry about this for some time, so my intel may be out of date. It was a mess around 5.6... > > > > > > I'm assuming the 72 has something to do with the point size, and being able to calculate scaling relative to 72. > > > > > > > > > > Sent: Wednesday, October 17, 2018 at 11:59 AM > > > > From: "Tomasz Olszak" > > > > To: development at qt-project.org > > > > Subject: [Development] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI? > > > > > > > > Hi, > > > > > > > > I would like just to ensure that I missed something and there is > > > > documentation somewhere informing that Linux fonts are rendered > > > > *always* in 72 dpi > > > > (https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#FT_Set_Char_Size) > > > > (which makes font.pixelSize inaccurate for regular screens). > > > > > > > > I found: https://bugreports.qt.io/browse/QTBUG-8890 which fixes the > > > > problem but it was rejected. I see the default 72 dpi is also used in > > > > current Qt 5.11 FT engine > > > > (https://code.woboq.org/qt5/qtbase/src/platformsupport/fontdatabases/freetype/qfontengine_ft.cpp.html#297). > > > > > > > > Does it surprise any of Qt developers or is it only me? Am I right > > > > thinking that when we do following: > > > > Rectangle { > > > > height: 100 > > > > Text {font.pixelSize: 100} > > > > } > > > > then the relation between height of text and height of rectangle will > > > > differ depending on screen dpi (don't have a way to test it > > > > currently)? > > > > > > > > Moreover I'm pretty sure that's the cause I very often use > > > > Text.fontSizeMode: Text.Fit because setting pixelSize to height of > > > > desired text size never worked correctly :) > > > > > > > > tl;dr: Is it a bug? > > > > _______________________________________________ > > > > Development mailing list > > > > Development at qt-project.org > > > > http://lists.qt-project.org/mailman/listinfo/development > > > > From kde at carewolf.com Wed Oct 17 19:07:36 2018 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Wed, 17 Oct 2018 19:07:36 +0200 Subject: [Development] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI? In-Reply-To: References: Message-ID: <11176097.O9o76ZdvQC@twilight> Hi That is a incorrect assesment. Fonts are rendered in pixel sizes. When you request a QFont at a certain pixel size you get the font in that size. It should be noted that those sizes ONLY matter for things like pixel hinting. The font will typically be rendered in the same size it was requested, but in some cases a specific font-size is used at a different resolution (for instance with hidpi modes), in that case pixel-hinting is disable, and we do vector based rendering of the glyphs. In any case the DPI is irrelevant and only matters if you select fonts by point instead of pixels, and then the translation to pixels is done before we get anywhere near the font engine. 'Allan On Mittwoch, 17. Oktober 2018 17:59:26 CEST Tomasz Olszak wrote: > Hi, > > I would like just to ensure that I missed something and there is > documentation somewhere informing that Linux fonts are rendered > *always* in 72 dpi > (https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#F > T_Set_Char_Size) (which makes font.pixelSize inaccurate for regular > screens). > > I found: https://bugreports.qt.io/browse/QTBUG-8890 which fixes the > problem but it was rejected. I see the default 72 dpi is also used in > current Qt 5.11 FT engine > (https://code.woboq.org/qt5/qtbase/src/platformsupport/fontdatabases/freetyp > e/qfontengine_ft.cpp.html#297). > > Does it surprise any of Qt developers or is it only me? Am I right > thinking that when we do following: > Rectangle { > height: 100 > Text {font.pixelSize: 100} > } > then the relation between height of text and height of rectangle will > differ depending on screen dpi (don't have a way to test it > currently)? > > Moreover I'm pretty sure that's the cause I very often use > Text.fontSizeMode: Text.Fit because setting pixelSize to height of > desired text size never worked correctly :) > > tl;dr: Is it a bug? > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From olszak.tomasz at gmail.com Wed Oct 17 19:10:45 2018 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Wed, 17 Oct 2018 19:10:45 +0200 Subject: [Development] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI? In-Reply-To: <11176097.O9o76ZdvQC@twilight> References: <11176097.O9o76ZdvQC@twilight> Message-ID: Could you please try example I sent on Linux and explain why font size doesn't match rectangle size? Maybe the ft font engine has bug? śr., 17 paź 2018, 19:07 użytkownik Allan Sandfeld Jensen napisał: > Hi > > That is a incorrect assesment. Fonts are rendered in pixel sizes. When you > request a QFont at a certain pixel size you get the font in that size. It > should be noted that those sizes ONLY matter for things like pixel hinting. > The font will typically be rendered in the same size it was requested, but > in > some cases a specific font-size is used at a different resolution (for > instance with hidpi modes), in that case pixel-hinting is disable, and we > do > vector based rendering of the glyphs. > > In any case the DPI is irrelevant and only matters if you select fonts by > point instead of pixels, and then the translation to pixels is done before > we > get anywhere near the font engine. > > 'Allan > > On Mittwoch, 17. Oktober 2018 17:59:26 CEST Tomasz Olszak wrote: > > Hi, > > > > I would like just to ensure that I missed something and there is > > documentation somewhere informing that Linux fonts are rendered > > *always* in 72 dpi > > ( > https://www.freetype.org/freetype2/docs/reference/ft2-base_interface.html#F > > T_Set_Char_Size) (which makes font.pixelSize inaccurate for regular > > screens). > > > > I found: https://bugreports.qt.io/browse/QTBUG-8890 which fixes the > > problem but it was rejected. I see the default 72 dpi is also used in > > current Qt 5.11 FT engine > > ( > https://code.woboq.org/qt5/qtbase/src/platformsupport/fontdatabases/freetyp > > e/qfontengine_ft.cpp.html#297). > > > > Does it surprise any of Qt developers or is it only me? Am I right > > thinking that when we do following: > > Rectangle { > > height: 100 > > Text {font.pixelSize: 100} > > } > > then the relation between height of text and height of rectangle will > > differ depending on screen dpi (don't have a way to test it > > currently)? > > > > Moreover I'm pretty sure that's the cause I very often use > > Text.fontSizeMode: Text.Fit because setting pixelSize to height of > > desired text size never worked correctly :) > > > > tl;dr: Is it a bug? > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kde at carewolf.com Wed Oct 17 19:23:23 2018 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Wed, 17 Oct 2018 19:23:23 +0200 Subject: [Development] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI? In-Reply-To: References: <11176097.O9o76ZdvQC@twilight> Message-ID: <1708382.tdWV9SEqCh@twilight> On Mittwoch, 17. Oktober 2018 19:10:45 CEST Tomasz Olszak wrote: > Could you please try example I sent on Linux and explain why font size > doesn't match rectangle size? Maybe the ft font engine has bug? > Try putting a capital Å or any other capital with accents in your example, and you will see that it fits snugly. Though it should be noted fonts are a bit inconsistent in what they consider their heights, some use the capital-height as their height, some use the maximum including accents. I believe we normally always render text with the leading on top, so there is room for all the Latin-1 characters and the results are always the same. 'Allan From jhihn at gmx.com Wed Oct 17 21:17:27 2018 From: jhihn at gmx.com (Jason H) Date: Wed, 17 Oct 2018 21:17:27 +0200 Subject: [Development] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI? In-Reply-To: <1708382.tdWV9SEqCh@twilight> References: <11176097.O9o76ZdvQC@twilight> <1708382.tdWV9SEqCh@twilight> Message-ID: +1. Make sure that you are accounting for the full font height, see QFontMetrics::ascent() and descent() > Sent: Wednesday, October 17, 2018 at 1:23 PM > From: "Allan Sandfeld Jensen" > To: development at qt-project.org > Subject: Re: [Development] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI? > > On Mittwoch, 17. Oktober 2018 19:10:45 CEST Tomasz Olszak wrote: > > Could you please try example I sent on Linux and explain why font size > > doesn't match rectangle size? Maybe the ft font engine has bug? > > > Try putting a capital Å or any other capital with accents in your example, and > you will see that it fits snugly. > > Though it should be noted fonts are a bit inconsistent in what they consider > their heights, some use the capital-height as their height, some use the > maximum including accents. I believe we normally always render text with the > leading on top, so there is room for all the Latin-1 characters and the > results are always the same. > > 'Allan > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From olszak.tomasz at gmail.com Wed Oct 17 22:11:38 2018 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Wed, 17 Oct 2018 22:11:38 +0200 Subject: [Development] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI? In-Reply-To: References: <11176097.O9o76ZdvQC@twilight> <1708382.tdWV9SEqCh@twilight> Message-ID: Ok, It's a lot more clear. Thank you for explanation! I used default font with pixel size 100 and according to FontMetrics: 1. family: "Sans Serif" 2. pointSize: 75 3. pixelSize: 100 4. ascent 93 5. descent: 24 6. height: 117 7. leading -1 So how ascent, descent, leading is related to 100. How can I calculate font.pixelSiize knowing that capital letter height is 100. By trial and errors the font with pixel size = 137 and ascent = 129 have capital letter(without accent) of 100 pixel height. Is it a way to determin font.pixelSize if we want the non accent capilat letter to be e.g 100px? Or should I just iterate over pixel sizes and calculate using fontMetrics and tightBoundingRect for capitalized letter without accent? śr., 17 paź 2018 o 21:17 Jason H napisał(a): > > +1. Make sure that you are accounting for the full font height, see QFontMetrics::ascent() and descent() > > > > Sent: Wednesday, October 17, 2018 at 1:23 PM > > From: "Allan Sandfeld Jensen" > > To: development at qt-project.org > > Subject: Re: [Development] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI? > > > > On Mittwoch, 17. Oktober 2018 19:10:45 CEST Tomasz Olszak wrote: > > > Could you please try example I sent on Linux and explain why font size > > > doesn't match rectangle size? Maybe the ft font engine has bug? > > > > > Try putting a capital Å or any other capital with accents in your example, and > > you will see that it fits snugly. > > > > Though it should be noted fonts are a bit inconsistent in what they consider > > their heights, some use the capital-height as their height, some use the > > maximum including accents. I believe we normally always render text with the > > leading on top, so there is room for all the Latin-1 characters and the > > results are always the same. > > > > 'Allan > > > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From kde at carewolf.com Thu Oct 18 00:58:14 2018 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Thu, 18 Oct 2018 00:58:14 +0200 Subject: [Development] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI? In-Reply-To: References: Message-ID: <7529457.T7Z3S40VBb@twilight> On Mittwoch, 17. Oktober 2018 22:11:38 CEST Tomasz Olszak wrote: > Ok, > It's a lot more clear. Thank you for explanation! > > I used default font with pixel size 100 and according to FontMetrics: > 1. family: "Sans Serif" > 2. pointSize: 75 > 3. pixelSize: 100 > 4. ascent 93 > 5. descent: 24 > 6. height: 117 > 7. leading -1 > > So how ascent, descent, leading is related to 100. How can I calculate > font.pixelSiize knowing that capital letter height is 100. By trial > and errors the font with pixel size = 137 and ascent = 129 have > capital letter(without accent) of 100 pixel height. > Is it a way to determin font.pixelSize if we want the non accent > capilat letter to be e.g 100px? Or should I just iterate over pixel > sizes and calculate using fontMetrics and tightBoundingRect for > capitalized letter without accent? > You should read the capHeight of the font. I think QFontMetrics can give you that (https://doc.qt.io/qt-5/qfontmetrics.html#capHeight), though I am not sure if there are QML bindings for that. In any case capital latin letters are generally all the same height, so you could probably just measure the height of H or M. From kde at carewolf.com Thu Oct 18 01:04:11 2018 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Thu, 18 Oct 2018 01:04:11 +0200 Subject: [Development] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI? In-Reply-To: <7529457.T7Z3S40VBb@twilight> References: <7529457.T7Z3S40VBb@twilight> Message-ID: <2049576.iZASKD2KPV@twilight> On Donnerstag, 18. Oktober 2018 00:58:14 CEST Allan Sandfeld Jensen wrote: > On Mittwoch, 17. Oktober 2018 22:11:38 CEST Tomasz Olszak wrote: > > Ok, > > It's a lot more clear. Thank you for explanation! > > > > I used default font with pixel size 100 and according to FontMetrics: > > 1. family: "Sans Serif" > > 2. pointSize: 75 > > 3. pixelSize: 100 > > 4. ascent 93 > > 5. descent: 24 > > 6. height: 117 > > 7. leading -1 > > > > So how ascent, descent, leading is related to 100. How can I calculate > > font.pixelSiize knowing that capital letter height is 100. By trial > > and errors the font with pixel size = 137 and ascent = 129 have > > capital letter(without accent) of 100 pixel height. > > Is it a way to determin font.pixelSize if we want the non accent > > capilat letter to be e.g 100px? Or should I just iterate over pixel > > sizes and calculate using fontMetrics and tightBoundingRect for > > capitalized letter without accent? > > You should read the capHeight of the font. I think QFontMetrics can give you > that (https://doc.qt.io/qt-5/qfontmetrics.html#capHeight), though I am not > sure if there are QML bindings for that. In any case capital latin letters > are generally all the same height, so you could probably just measure the > height of H or M. > See also https://en.wikipedia.org/wiki/Typeface#Font_metrics From olszak.tomasz at gmail.com Thu Oct 18 07:14:13 2018 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Thu, 18 Oct 2018 07:14:13 +0200 Subject: [Development] Why on Linux using FreeType engine fonts are rendered in 72 dpi instead of Screen DPI? In-Reply-To: <2049576.iZASKD2KPV@twilight> References: <7529457.T7Z3S40VBb@twilight> <2049576.iZASKD2KPV@twilight> Message-ID: Ok, I just thought that knowing capital letter height I can calculate correct font pixel size but seems using font metrics and iteration over pixel sizes is the only option. Thank you all for help! czw., 18 paź 2018, 01:04 użytkownik Allan Sandfeld Jensen napisał: > On Donnerstag, 18. Oktober 2018 00:58:14 CEST Allan Sandfeld Jensen wrote: > > On Mittwoch, 17. Oktober 2018 22:11:38 CEST Tomasz Olszak wrote: > > > Ok, > > > It's a lot more clear. Thank you for explanation! > > > > > > I used default font with pixel size 100 and according to FontMetrics: > > > 1. family: "Sans Serif" > > > 2. pointSize: 75 > > > 3. pixelSize: 100 > > > 4. ascent 93 > > > 5. descent: 24 > > > 6. height: 117 > > > 7. leading -1 > > > > > > So how ascent, descent, leading is related to 100. How can I calculate > > > font.pixelSiize knowing that capital letter height is 100. By trial > > > and errors the font with pixel size = 137 and ascent = 129 have > > > capital letter(without accent) of 100 pixel height. > > > Is it a way to determin font.pixelSize if we want the non accent > > > capilat letter to be e.g 100px? Or should I just iterate over pixel > > > sizes and calculate using fontMetrics and tightBoundingRect for > > > capitalized letter without accent? > > > > You should read the capHeight of the font. I think QFontMetrics can give > you > > that (https://doc.qt.io/qt-5/qfontmetrics.html#capHeight), though I am > not > > sure if there are QML bindings for that. In any case capital latin > letters > > are generally all the same height, so you could probably just measure the > > height of H or M. > > > See also https://en.wikipedia.org/wiki/Typeface#Font_metrics > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aapo.keskimolo at qt.io Fri Oct 19 13:02:19 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Fri, 19 Oct 2018 11:02:19 +0000 Subject: [Development] Coin production update: Import note for users of testresults Message-ID: To all our Developers, Coin production will be updated tomorrow during Sat Oct 20 10:00-16:00 EEST 2018. See attached change log for related patches. IMPORTANT NOTES: - This update will contain changes in our CI storage meaning that we will need to rebuild all cached binaries. I will take the service offline while artifacts are being re-create and restore the service after most of them have been finished. - The integrations in testresults coin page will look somewhat strange after this change since we are moving to a new era of building products in Coin and we have decided to decouple platform related code from our Coin source code base and legacy support will not be provided. The log links posted in gerrit should continue working as before. If you REALLY need to have the integration workitems display fixed, please, reply to this email and I will reconsider providing legacy support. The commit resulting in this behavior is a4280c7f61822a336f88bcec91c571bcebd94e97. Have a great weekend, Aapo Keskimölö -------------- next part -------------- A non-text attachment was scrubbed... Name: product_baseline_20181019.log Type: application/octet-stream Size: 10262 bytes Desc: product_baseline_20181019.log URL: From Simon.Hausmann at qt.io Fri Oct 19 14:50:33 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 19 Oct 2018 12:50:33 +0000 Subject: [Development] Coin production update: Import note for users of testresults In-Reply-To: References: Message-ID: Hi, Just to clarify. When the CI posts a message to Gerrit about a failure for example, it looks like this: Build log: Details: Do I understand correctly that the first link, the link to the build log, will continue to work. However _ALL_ links to the integration overview in _all_ changes ever posted to Gerrit by Coin will stop working and only newly posted links will be valid? >From an archeological point of view I think that is a mistake. For example at the beginning of this week had to look into why something was missing from the 5.11.2 release binaries. So I went to the release tag in qt5.git and from there I got - via the Change-ID - to the Gerrit change that contained the last change to qt5 that constitues the final release content. From there I was able to follow the "Details:" link to the CI integration that gave access to all the logs used in the release for builds and tests. With help of that I was able to identify which builds were broken. That was possible because the qt5 overview gave access to the sub-module build and test logs. I understand that any _new_ qt5 builds would continue to have working links, but practically destroying the old ones looks like a mistake to me. Simon ________________________________ From: Development on behalf of Aapo Keskimölö Sent: Friday, October 19, 2018 1:02:19 PM To: development at qt-project.org Subject: [Development] Coin production update: Import note for users of testresults To all our Developers, Coin production will be updated tomorrow during Sat Oct 20 10:00-16:00 EEST 2018. See attached change log for related patches. IMPORTANT NOTES: - This update will contain changes in our CI storage meaning that we will need to rebuild all cached binaries. I will take the service offline while artifacts are being re-create and restore the service after most of them have been finished. - The integrations in testresults coin page will look somewhat strange after this change since we are moving to a new era of building products in Coin and we have decided to decouple platform related code from our Coin source code base and legacy support will not be provided. The log links posted in gerrit should continue working as before. If you REALLY need to have the integration workitems display fixed, please, reply to this email and I will reconsider providing legacy support. The commit resulting in this behavior is a4280c7f61822a336f88bcec91c571bcebd94e97. Have a great weekend, Aapo Keskimölö -------------- next part -------------- An HTML attachment was scrubbed... URL: From aapo.keskimolo at qt.io Fri Oct 19 21:19:19 2018 From: aapo.keskimolo at qt.io (=?iso-8859-1?Q?Aapo_Keskim=F6l=F6?=) Date: Fri, 19 Oct 2018 19:19:19 +0000 Subject: [Development] Coin production update: Import note for users of testresults In-Reply-To: References: Message-ID: Yes, you have understood correctly. I can halt the deprecation if there are use cases and there seems to be at least one. From: Simon Hausmann Sent: perjantai 19. lokakuuta 2018 15.51 To: Aapo Keskimölö ; development at qt-project.org Subject: Re: Coin production update: Import note for users of testresults Hi, Just to clarify. When the CI posts a message to Gerrit about a failure for example, it looks like this: Build log: Details: Do I understand correctly that the first link, the link to the build log, will continue to work. However _ALL_ links to the integration overview in _all_ changes ever posted to Gerrit by Coin will stop working and only newly posted links will be valid? >From an archeological point of view I think that is a mistake. For example at the beginning of this week had to look into why something was missing from the 5.11.2 release binaries. So I went to the release tag in qt5.git and from there I got - via the Change-ID - to the Gerrit change that contained the last change to qt5 that constitues the final release content. From there I was able to follow the "Details:" link to the CI integration that gave access to all the logs used in the release for builds and tests. With help of that I was able to identify which builds were broken. That was possible because the qt5 overview gave access to the sub-module build and test logs. I understand that any _new_ qt5 builds would continue to have working links, but practically destroying the old ones looks like a mistake to me. Simon ________________________________ From: Development > on behalf of Aapo Keskimölö > Sent: Friday, October 19, 2018 1:02:19 PM To: development at qt-project.org Subject: [Development] Coin production update: Import note for users of testresults To all our Developers, Coin production will be updated tomorrow during Sat Oct 20 10:00-16:00 EEST 2018. See attached change log for related patches. IMPORTANT NOTES: - This update will contain changes in our CI storage meaning that we will need to rebuild all cached binaries. I will take the service offline while artifacts are being re-create and restore the service after most of them have been finished. - The integrations in testresults coin page will look somewhat strange after this change since we are moving to a new era of building products in Coin and we have decided to decouple platform related code from our Coin source code base and legacy support will not be provided. The log links posted in gerrit should continue working as before. If you REALLY need to have the integration workitems display fixed, please, reply to this email and I will reconsider providing legacy support. The commit resulting in this behavior is a4280c7f61822a336f88bcec91c571bcebd94e97. Have a great weekend, Aapo Keskimölö -------------- next part -------------- An HTML attachment was scrubbed... URL: From aapo.keskimolo at qt.io Sat Oct 20 12:45:32 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Sat, 20 Oct 2018 10:45:32 +0000 Subject: [Development] Coin production update: Import note for users of testresults In-Reply-To: References: Message-ID: It seems that some users will want to keep the old task links working so we have decided to cancel this production update and do a new one after the backwards compatibility is in place. Kind regards/Ystävällisin terveisin, Aapo Keskimölö > On 19 Oct 2018, at 14.02, Aapo Keskimölö wrote: > > To all our Developers, > > Coin production will be updated tomorrow during Sat Oct 20 10:00-16:00 EEST 2018. See attached change log for related patches. > > IMPORTANT NOTES: > - This update will contain changes in our CI storage meaning that we will need to rebuild all cached binaries. I will take the service offline while artifacts are being re-create and restore the service after most of them have been finished. > - The integrations in testresults coin page will look somewhat strange after this change since we are moving to a new era of building products in Coin and we have decided to decouple platform related code from our Coin source code base and legacy support will not be provided. The log links posted in gerrit should continue working as before. If you REALLY need to have the integration workitems display fixed, please, reply to this email and I will reconsider providing legacy support. The commit resulting in this behavior is a4280c7f61822a336f88bcec91c571bcebd94e97. > > Have a great weekend, > Aapo Keskimölö > From aapo.keskimolo at qt.io Sat Oct 20 12:51:25 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Sat, 20 Oct 2018 10:51:25 +0000 Subject: [Development] Coin go version has been updated Message-ID: Hi all, I have bumped the go compiler on the master machine 1.8.3->1.11.1 because the current go version is not supporting all features that are required to continue development of Coin. In the past this caused issues with mac builds: https://bugreports.qt.io/browse/QTQAINFRA-2172 If you experience any problems with your integrations that might be related to the new go version, you can reply to this email or in internal IRC. Kind regards/Ystävällisin terveisin, Aapo Keskimölö -------------- next part -------------- An HTML attachment was scrubbed... URL: From aapo.keskimolo at qt.io Sat Oct 20 14:36:35 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Sat, 20 Oct 2018 12:36:35 +0000 Subject: [Development] Coin go version has been updated In-Reply-To: References: Message-ID: It seems that the mac machines are still having the same issue with this go version:/ I have reverted the go version coin master back to 1.8.3. Kind regards/Ystävällisin terveisin, Aapo Keskimölö On 20 Oct 2018, at 13.51, Aapo Keskimölö > wrote: Hi all, I have bumped the go compiler on the master machine 1.8.3->1.11.1 because the current go version is not supporting all features that are required to continue development of Coin. In the past this caused issues with mac builds: https://bugreports.qt.io/browse/QTQAINFRA-2172 If you experience any problems with your integrations that might be related to the new go version, you can reply to this email or in internal IRC. Kind regards/Ystävällisin terveisin, Aapo Keskimölö -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvstone at gmail.com Sat Oct 20 14:43:45 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Sat, 20 Oct 2018 14:43:45 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? Message-ID: Hi all (first post), In Qt 5.7+ there's qAsConst, an std::as_const implementation for those who are not on C++17 yet, which is convenient for iterating over Qt containers using range-based for loops without causing a detach. For good reasons there's no version of qAsConst that takes an rvalue reference, so you can't do e.g. for (auto foo : qAsConst(returnsQtContainer()) { ... }. Instead you must do const auto stuff = returnsQtContainer(); for (auto foo : stuff) { ... }. In our application we added a helper like template const T moveToConst(T &&t) { return std::move(t); } that we use for these cases. It just moves the argument to a const value and returns it. With that we can do for (auto foo : moveToConst(returnsQtContainer()) { ... }. Since it's such a common pattern to want to iterate a returned Qt container, what would you think of having such a helper (qMoveToConst?) in Qt? Cheers, Elvis From giuseppe.dangelo at kdab.com Sat Oct 20 18:53:22 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Sat, 20 Oct 2018 18:53:22 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: Message-ID: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> Il 20/10/18 14:43, Elvis Stansvik ha scritto: > In our application we added a helper like > > template > const T moveToConst(T &&t) > { > return std::move(t); > } > > that we use for these cases. It just moves the argument to a const > value and returns it. With that we can do for (auto foo : > moveToConst(returnsQtContainer()) { ... }. > > Since it's such a common pattern to want to iterate a returned Qt > container, what would you think of having such a helper > (qMoveToConst?) in Qt? Possibly... Note however that such a thing was already proposed for qAsConst itself, and shut down to avoid having qAsConst diverge from std::as_const (and I approve of not having Qt-specific behaviours). I can't find the relevant discussion on the mailing list right now. For reference, std::as_const's original authors had doubts about the lifetime issues around this, saying that more investigations were needed: > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r0.html#9.0 After a LEWG meeting it was reworded like this: > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r1.html#8.0 I'm not entirely sure of what prompted the change for as_const -- if just a safety net while waiting for more investigation, or if something more profound was raised. I can easily imagine however a scenario where moveToConst() can lead to worse code than the current solution. Current solution: // GCE may get applied, 0 moves const QVector v = getVector(); for (auto &obj : v) ~~~ vs. // Always 2 moves for (auto &obj : qMoveToConst(getVector()) ~~~ And if the type is not even cheap to move (e.g. QVLA, std::array), qMoveToConst becomes a really unpleasant surprise. How about asking LEWG about their reasoning too? My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From tony.sarajarvi at qt.io Sat Oct 20 19:28:25 2018 From: tony.sarajarvi at qt.io (=?utf-8?B?VG9ueSBTYXJhasOkcnZp?=) Date: Sat, 20 Oct 2018 17:28:25 +0000 Subject: [Development] Coin go version has been updated In-Reply-To: References: Message-ID: I’m also interested in what you thought had fixed the issues, as they clearly state they remove the compatibility with the old distros? And what features do we need from the new go-lang versions? -T From: Development On Behalf Of Aapo Keskimölö Sent: lauantai 20. lokakuuta 2018 15.37 To: development at qt-project.org Cc: Coin Team Subject: Re: [Development] Coin go version has been updated It seems that the mac machines are still having the same issue with this go version:/ I have reverted the go version coin master back to 1.8.3. Kind regards/Ystävällisin terveisin, Aapo Keskimölö On 20 Oct 2018, at 13.51, Aapo Keskimölö > wrote: Hi all, I have bumped the go compiler on the master machine 1.8.3->1.11.1 because the current go version is not supporting all features that are required to continue development of Coin. In the past this caused issues with mac builds: https://bugreports.qt.io/browse/QTQAINFRA-2172 If you experience any problems with your integrations that might be related to the new go version, you can reply to this email or in internal IRC. Kind regards/Ystävällisin terveisin, Aapo Keskimölö -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvstone at gmail.com Sat Oct 20 19:37:26 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Sat, 20 Oct 2018 19:37:26 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> Message-ID: Den lör 20 okt. 2018 kl 18:53 skrev Giuseppe D'Angelo via Development : > > Il 20/10/18 14:43, Elvis Stansvik ha scritto: > > In our application we added a helper like > > > > template > > const T moveToConst(T &&t) > > { > > return std::move(t); > > } > > > > that we use for these cases. It just moves the argument to a const > > value and returns it. With that we can do for (auto foo : > > moveToConst(returnsQtContainer()) { ... }. > > > > Since it's such a common pattern to want to iterate a returned Qt > > container, what would you think of having such a helper > > (qMoveToConst?) in Qt? > > Possibly... Note however that such a thing was already proposed for > qAsConst itself, and shut down to avoid having qAsConst diverge from > std::as_const (and I approve of not having Qt-specific behaviours). I > can't find the relevant discussion on the mailing list right now. > > > For reference, std::as_const's original authors had doubts about the > lifetime issues around this, saying that more investigations were needed: > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r0.html#9.0 > > > After a LEWG meeting it was reworded like this: > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r1.html#8.0 > > > I'm not entirely sure of what prompted the change for as_const -- if > just a safety net while waiting for more investigation, or if something > more profound was raised. > > > I can easily imagine however a scenario where moveToConst() can lead to > worse code than the current solution. > > Current solution: > > // GCE may get applied, 0 moves > const QVector v = getVector(); > for (auto &obj : v) ~~~ > > vs. > > // Always 2 moves > for (auto &obj : qMoveToConst(getVector()) ~~~ > > > And if the type is not even cheap to move (e.g. QVLA, std::array), > qMoveToConst becomes a really unpleasant surprise. > > How about asking LEWG about their reasoning too? > Thanks a lot for the pointers and back story Giuseppe. I definitely think it's good that qAsConst mirrors what std::as_const did, so wouldn't want it expanded. If the C++ wizards considered this but were hesitant, then I think it's right that Qt is hesitant as well. I hadn't really considered potential life-time issues, so I guess what we're doing might possibly be unsafe (?). What's GCE? Some optimization? (Google "c++ gce" didn't give me anything). Elvis > > My 2 c, > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Simon.Hausmann at qt.io Sat Oct 20 23:05:15 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Sat, 20 Oct 2018 21:05:15 +0000 Subject: [Development] Coin production update: Import note for users of testresults In-Reply-To: References: , Message-ID: Thank you Aapo! Simon > On 20. Oct 2018, at 12:45, Aapo Keskimölö wrote: > > It seems that some users will want to keep the old task links working so we have decided to cancel this production update and do a new one after the backwards compatibility is in place. > > Kind regards/Ystävällisin terveisin, > Aapo Keskimölö > >> On 19 Oct 2018, at 14.02, Aapo Keskimölö wrote: >> >> To all our Developers, >> >> Coin production will be updated tomorrow during Sat Oct 20 10:00-16:00 EEST 2018. See attached change log for related patches. >> >> IMPORTANT NOTES: >> - This update will contain changes in our CI storage meaning that we will need to rebuild all cached binaries. I will take the service offline while artifacts are being re-create and restore the service after most of them have been finished. >> - The integrations in testresults coin page will look somewhat strange after this change since we are moving to a new era of building products in Coin and we have decided to decouple platform related code from our Coin source code base and legacy support will not be provided. The log links posted in gerrit should continue working as before. If you REALLY need to have the integration workitems display fixed, please, reply to this email and I will reconsider providing legacy support. The commit resulting in this behavior is a4280c7f61822a336f88bcec91c571bcebd94e97. >> >> Have a great weekend, >> Aapo Keskimölö >> > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From elvstone at gmail.com Sat Oct 20 23:58:53 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Sat, 20 Oct 2018 23:58:53 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> Message-ID: (Adding back the mailing list) Den lör 20 okt. 2018 kl 23:54 skrev Elvis Stansvik : > > Den lör 20 okt. 2018 kl 23:50 skrev Giuseppe D'Angelo > : > > > > Il 20/10/18 19:37, Elvis Stansvik ha scritto: > > > If the C++ wizards considered this but were hesitant, then I think > > > it's right that Qt is hesitant as well. I hadn't really considered > > > potential life-time issues, so I guess what we're doing might possibly > > > be unsafe (?). > > > > Probably in the sense that the function you pasted can be applied like this: > > > > QVector v; > > for (auto &o : qMoveAsConst(v)) ~~~; // compiles with an lvalue! > > use(v); // unspecified behavior > > Ah yes, it may be that the standards folks simply didn't want this > because of foot-shooting potential like this. Another potential foot-shooter I found on an SO question (https://stackoverflow.com/a/39051612/252857): for (auto const &&value : as_const(getQString())) // whoops! { } Elvis > > > > > > > > What's GCE? Some optimization? (Google "c++ gce" didn't give me anything). > > > > Guaranteed Copy Elision: > > > > > https://en.cppreference.com/w/cpp/language/copy_elision > > Thanks! > > Elvis > > > > > My 2 c, > > > > -- > > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > > KDAB (France) S.A.S., a KDAB Group company > > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > > KDAB - The Qt, C++ and OpenGL Experts > > From elvstone at gmail.com Sun Oct 21 16:15:58 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Sun, 21 Oct 2018 16:15:58 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> Message-ID: Den lör 20 okt. 2018 kl 18:53 skrev Giuseppe D'Angelo via Development : > > Il 20/10/18 14:43, Elvis Stansvik ha scritto: > > In our application we added a helper like > > > > template > > const T moveToConst(T &&t) > > { > > return std::move(t); > > } > > > > that we use for these cases. It just moves the argument to a const > > value and returns it. With that we can do for (auto foo : > > moveToConst(returnsQtContainer()) { ... }. > > > > Since it's such a common pattern to want to iterate a returned Qt > > container, what would you think of having such a helper > > (qMoveToConst?) in Qt? > > Possibly... Note however that such a thing was already proposed for > qAsConst itself, and shut down to avoid having qAsConst diverge from > std::as_const (and I approve of not having Qt-specific behaviours). I > can't find the relevant discussion on the mailing list right now. > > > For reference, std::as_const's original authors had doubts about the > lifetime issues around this, saying that more investigations were needed: > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r0.html#9.0 > > > After a LEWG meeting it was reworded like this: > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r1.html#8.0 > > > I'm not entirely sure of what prompted the change for as_const -- if > just a safety net while waiting for more investigation, or if something > more profound was raised. > > > I can easily imagine however a scenario where moveToConst() can lead to > worse code than the current solution. > > Current solution: > > // GCE may get applied, 0 moves > const QVector v = getVector(); > for (auto &obj : v) ~~~ > > vs. > > // Always 2 moves > for (auto &obj : qMoveToConst(getVector()) ~~~ > > > And if the type is not even cheap to move (e.g. QVLA, std::array), > qMoveToConst becomes a really unpleasant surprise. > > How about asking LEWG about their reasoning too? I couldn't find a way to contact them. In order to try out the unsafe usage you suggested in your other mail, and also another unsafe usage pointed out in an SO question (https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612), I made the following test program. The output when running is: [estan at newton move-to-const-test]$ ./move-to-const-test without moveToConst: FooPrivate constr from vector Foo constr with arg 0x7fffdb627200 Foo begin 0x7fffdb627200 Foo end 0x7fffdb627200 Foo destr 0x7fffdb627200 FooPrivate destr with moveToConst: FooPrivate constr from vector Foo constr with arg 0x7fffdb627208 Foo move constr 0x7fffdb627210 Foo destr 0x7fffdb627208 Foo begin const 0x7fffdb627210 Foo end const 0x7fffdb627210 Foo destr 0x7fffdb627210 FooPrivate destr [estan at newton move-to-const-test]$ Which just shows it's working as intended. The two unsafe usages are commented out, because they wouldn't compile (good!). Note that the version suggested under Further Discussion in rev 0 is different from our helper, we return std::move(t) while they return t. With the version from rev 0, your example unsafe usage will compile (the one from SO still won't). Elvis #include #include #include #include class FooPrivate : public QSharedData { public: FooPrivate() { qDebug() << "FooPrivate default constr"; }; FooPrivate(const FooPrivate &other) : QSharedData(other) { qDebug() << "FooPrivate copy constr"; }; explicit FooPrivate(const QVector &v) : v(v) { qDebug() << "FooPrivate constr from vector"; }; ~FooPrivate() { qDebug() << "FooPrivate destr"; }; QVector v; }; class Foo { public: Foo() : d(new FooPrivate) { qDebug() << "Foo default constr" << this; }; Foo(const Foo &other) : d(other.d) { qDebug() << "Foo copy constr" << this; }; Foo(Foo &&other) : d(other.d) { other.d = nullptr; qDebug() << "Foo move constr" << this; }; explicit Foo(const QVector &v) : d(new FooPrivate(v)) { qDebug() << "Foo constr with arg" << this; }; ~Foo() { qDebug() << "Foo destr" << this; }; Foo &operator=(const Foo &other) { qDebug() << "Foo copy ass op" << this; d = other.d; return *this; }; QVector::iterator begin() { qDebug() << "Foo begin" << this; return d->v.begin(); }; QVector::const_iterator begin() const { qDebug() << "Foo begin const" << this; return d->v.begin(); }; QVector::const_iterator cbegin() const { qDebug() << "Foo cbegin" << this; return d->v.cbegin(); }; QVector::iterator end() { qDebug() << "Foo end" << this; return d->v.end(); }; QVector::const_iterator end() const { qDebug() << "Foo end const" << this; return d->v.end(); }; QVector::const_iterator cend() { qDebug() << "Foo cend" << this; return d->v.cend(); }; private: QSharedDataPointer d; }; template const T moveToConst(T &&t) { return std::move(t); } Foo f() { return Foo({1, 2, 3}); } int main(int argc, char *argv[]) { Q_UNUSED(argc); Q_UNUSED(argv); qDebug() << "without moveToConst:"; for (auto v : f()) { Q_UNUSED(v); } qDebug() << ""; qDebug() << "with moveToConst:"; for (auto v : moveToConst(f())) { Q_UNUSED(v); } /* * Potential unsafe use suggested by Guiseppe D'Angelo * https://lists.qt-project.org/pipermail/development/2018-October/033808.html * * Gives: * * move-to-const-test.cpp:93:23: error: cannot bind non-const lvalue reference of type ‘Foo&’ to an rvalue of type ‘std::remove_reference::type {aka Foo}’ * return std::move(t); * ^ */ //Foo baz; //for (auto &v : moveToConst(baz)) { Q_UNUSED(v); }; /* * Potential unsafe use from https://stackoverflow.com/a/39051612/252857 * * Gives: * * move-to-const-test.cpp:118:42: error: cannot bind rvalue reference of type ‘const int&&’ to lvalue of type ‘const int’ * for (auto const &&v : moveToConst(f())) { Q_UNUSED(v); } // whoops! */ //for (auto const &&v : moveToConst(f())) { Q_UNUSED(v); } // whoops! return 0; } > > > My 2 c, > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From elvstone at gmail.com Sun Oct 21 16:20:22 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Sun, 21 Oct 2018 16:20:22 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> Message-ID: Den sön 21 okt. 2018 kl 16:15 skrev Elvis Stansvik : > > Den lör 20 okt. 2018 kl 18:53 skrev Giuseppe D'Angelo via Development > : > > > > Il 20/10/18 14:43, Elvis Stansvik ha scritto: > > > In our application we added a helper like > > > > > > template > > > const T moveToConst(T &&t) > > > { > > > return std::move(t); > > > } > > > > > > that we use for these cases. It just moves the argument to a const > > > value and returns it. With that we can do for (auto foo : > > > moveToConst(returnsQtContainer()) { ... }. > > > > > > Since it's such a common pattern to want to iterate a returned Qt > > > container, what would you think of having such a helper > > > (qMoveToConst?) in Qt? > > > > Possibly... Note however that such a thing was already proposed for > > qAsConst itself, and shut down to avoid having qAsConst diverge from > > std::as_const (and I approve of not having Qt-specific behaviours). I > > can't find the relevant discussion on the mailing list right now. > > > > > > For reference, std::as_const's original authors had doubts about the > > lifetime issues around this, saying that more investigations were needed: > > > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r0.html#9.0 > > > > > > After a LEWG meeting it was reworded like this: > > > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r1.html#8.0 > > > > > > I'm not entirely sure of what prompted the change for as_const -- if > > just a safety net while waiting for more investigation, or if something > > more profound was raised. > > > > > > I can easily imagine however a scenario where moveToConst() can lead to > > worse code than the current solution. > > > > Current solution: > > > > // GCE may get applied, 0 moves > > const QVector v = getVector(); > > for (auto &obj : v) ~~~ > > > > vs. > > > > // Always 2 moves > > for (auto &obj : qMoveToConst(getVector()) ~~~ > > > > > > And if the type is not even cheap to move (e.g. QVLA, std::array), > > qMoveToConst becomes a really unpleasant surprise. These two points of yours of course still stands, and I can understand why you wouldn't want this as a helper in Qt because of it. Elvis > > > > How about asking LEWG about their reasoning too? > > I couldn't find a way to contact them. > > In order to try out the unsafe usage you suggested in your other mail, > and also another unsafe usage pointed out in an SO question > (https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612), > I made the following test program. > > The output when running is: > > [estan at newton move-to-const-test]$ ./move-to-const-test > without moveToConst: > FooPrivate constr from vector > Foo constr with arg 0x7fffdb627200 > Foo begin 0x7fffdb627200 > Foo end 0x7fffdb627200 > Foo destr 0x7fffdb627200 > FooPrivate destr > > with moveToConst: > FooPrivate constr from vector > Foo constr with arg 0x7fffdb627208 > Foo move constr 0x7fffdb627210 > Foo destr 0x7fffdb627208 > Foo begin const 0x7fffdb627210 > Foo end const 0x7fffdb627210 > Foo destr 0x7fffdb627210 > FooPrivate destr > [estan at newton move-to-const-test]$ > > Which just shows it's working as intended. > > The two unsafe usages are commented out, because they wouldn't compile (good!). > > Note that the version suggested under Further Discussion in rev 0 is > different from our helper, we return std::move(t) while they return t. > > With the version from rev 0, your example unsafe usage will compile > (the one from SO still won't). > > Elvis > > #include > #include > #include > #include > > class FooPrivate : public QSharedData { > public: > FooPrivate() { > qDebug() << "FooPrivate default constr"; > }; > > FooPrivate(const FooPrivate &other) : QSharedData(other) { > qDebug() << "FooPrivate copy constr"; > }; > > explicit FooPrivate(const QVector &v) : v(v) { > qDebug() << "FooPrivate constr from vector"; > }; > > ~FooPrivate() { > qDebug() << "FooPrivate destr"; > }; > > QVector v; > }; > > class Foo { > public: > Foo() : d(new FooPrivate) { > qDebug() << "Foo default constr" << this; > }; > > Foo(const Foo &other) : d(other.d) { > qDebug() << "Foo copy constr" << this; > }; > > Foo(Foo &&other) : d(other.d) { > other.d = nullptr; > qDebug() << "Foo move constr" << this; > }; > > explicit Foo(const QVector &v) : d(new FooPrivate(v)) { > qDebug() << "Foo constr with arg" << this; > }; > > ~Foo() { > qDebug() << "Foo destr" << this; > }; > > Foo &operator=(const Foo &other) { > qDebug() << "Foo copy ass op" << this; > d = other.d; > return *this; > }; > > QVector::iterator begin() { > qDebug() << "Foo begin" << this; > return d->v.begin(); > }; > > QVector::const_iterator begin() const { > qDebug() << "Foo begin const" << this; > return d->v.begin(); > }; > > QVector::const_iterator cbegin() const { > qDebug() << "Foo cbegin" << this; > return d->v.cbegin(); > }; > > QVector::iterator end() { > qDebug() << "Foo end" << this; > return d->v.end(); > }; > > QVector::const_iterator end() const { > qDebug() << "Foo end const" << this; > return d->v.end(); > }; > > QVector::const_iterator cend() { > qDebug() << "Foo cend" << this; > return d->v.cend(); > }; > > private: > QSharedDataPointer d; > }; > > template > const T moveToConst(T &&t) > { > return std::move(t); > } > > Foo f() { > return Foo({1, 2, 3}); > } > > int main(int argc, char *argv[]) { > Q_UNUSED(argc); > Q_UNUSED(argv); > > qDebug() << "without moveToConst:"; > for (auto v : f()) { Q_UNUSED(v); } > > qDebug() << ""; > > qDebug() << "with moveToConst:"; > for (auto v : moveToConst(f())) { Q_UNUSED(v); } > > /* > * Potential unsafe use suggested by Guiseppe D'Angelo > * https://lists.qt-project.org/pipermail/development/2018-October/033808.html > * > * Gives: > * > * move-to-const-test.cpp:93:23: error: cannot bind non-const > lvalue reference of type ‘Foo&’ to an rvalue of type > ‘std::remove_reference::type {aka Foo}’ > * return std::move(t); > * ^ > */ > > //Foo baz; > //for (auto &v : moveToConst(baz)) { Q_UNUSED(v); }; > > /* > * Potential unsafe use from https://stackoverflow.com/a/39051612/252857 > * > * Gives: > * > * move-to-const-test.cpp:118:42: error: cannot bind rvalue > reference of type ‘const int&&’ to lvalue of type ‘const int’ > * for (auto const &&v : moveToConst(f())) { Q_UNUSED(v); } > // whoops! > */ > > //for (auto const &&v : moveToConst(f())) { Q_UNUSED(v); } // whoops! > > return 0; > } > > > > > > > My 2 c, > > -- > > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > > KDAB (France) S.A.S., a KDAB Group company > > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > > KDAB - The Qt, C++ and OpenGL Experts > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development From giuseppe.dangelo at kdab.com Sun Oct 21 17:50:33 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Sun, 21 Oct 2018 17:50:33 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> Message-ID: <4b21d498-c513-53e7-5c20-2e8c88aeb0db@kdab.com> Hello, Il 21/10/18 16:15, Elvis Stansvik ha scritto: > I couldn't find a way to contact them. The best shot would be the std-discussion mailing list, I think. > In order to try out the unsafe usage you suggested in your other mail, > and also another unsafe usage pointed out in an SO question > (https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612), > I made the following test program. > > The output when running is: > > [estan at newton move-to-const-test]$ ./move-to-const-test > without moveToConst: > FooPrivate constr from vector > Foo constr with arg 0x7fffdb627200 > Foo begin 0x7fffdb627200 > Foo end 0x7fffdb627200 > Foo destr 0x7fffdb627200 > FooPrivate destr > > with moveToConst: > FooPrivate constr from vector > Foo constr with arg 0x7fffdb627208 > Foo move constr 0x7fffdb627210 > Foo destr 0x7fffdb627208 > Foo begin const 0x7fffdb627210 > Foo end const 0x7fffdb627210 > Foo destr 0x7fffdb627210 > FooPrivate destr > [estan at newton move-to-const-test]$ > > Which just shows it's working as intended. However the third test should be a without moveToConst, but storing in a temporary, i.e. the current best practice. It should output exactly like the first one, but of course call const begin/end. And note the extra move/destruciton in the second example. > The two unsafe usages are commented out, because they wouldn't compile (good!). Whops, you're absolutely right. My bad. With your proposed implementation: > template > const T moveToConst(T &&t) > { > return std::move(t); > } This won't compile when called on a non-const lvalue (the return type will be a lvalue reference to const, which won't bind to a non-const rvalue). I stand corrected. Which actually makes me think of yet another possibility of misuse, that is, applying moveToConst to a function returning a const object. That will compile, using a copy... > const QVector getVector(); > for (auto &obj : moveToConst(getVector()) ~~~ Long story short, I think it's good if we stay away from this in Qt. Clazy warns you if you "do it wrong", and being a Qt-specific problem, we better not offer too many ways that could have unpleasant drawbacks. My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From giuseppe.dangelo at kdab.com Sun Oct 21 17:58:01 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Sun, 21 Oct 2018 17:58:01 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <4b21d498-c513-53e7-5c20-2e8c88aeb0db@kdab.com> References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> <4b21d498-c513-53e7-5c20-2e8c88aeb0db@kdab.com> Message-ID: <3a690174-2b3c-ac06-5d87-bf13fea57309@kdab.com> Il 21/10/18 17:50, Giuseppe D'Angelo via Development ha scritto: > This won't compile when called on a non-const lvalue (the return type > will be a lvalue reference to const, To NON-const, that is. -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From elvstone at gmail.com Sun Oct 21 18:23:35 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Sun, 21 Oct 2018 18:23:35 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <4b21d498-c513-53e7-5c20-2e8c88aeb0db@kdab.com> References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> <4b21d498-c513-53e7-5c20-2e8c88aeb0db@kdab.com> Message-ID: Den sön 21 okt. 2018 kl 17:50 skrev Giuseppe D'Angelo : > > Hello, > > Il 21/10/18 16:15, Elvis Stansvik ha scritto: > > I couldn't find a way to contact them. > > The best shot would be the std-discussion mailing list, I think. > > > In order to try out the unsafe usage you suggested in your other mail, > > and also another unsafe usage pointed out in an SO question > > (https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612), > > I made the following test program. > > > > The output when running is: > > > > [estan at newton move-to-const-test]$ ./move-to-const-test > > without moveToConst: > > FooPrivate constr from vector > > Foo constr with arg 0x7fffdb627200 > > Foo begin 0x7fffdb627200 > > Foo end 0x7fffdb627200 > > Foo destr 0x7fffdb627200 > > FooPrivate destr > > > > with moveToConst: > > FooPrivate constr from vector > > Foo constr with arg 0x7fffdb627208 > > Foo move constr 0x7fffdb627210 > > Foo destr 0x7fffdb627208 > > Foo begin const 0x7fffdb627210 > > Foo end const 0x7fffdb627210 > > Foo destr 0x7fffdb627210 > > FooPrivate destr > > [estan at newton move-to-const-test]$ > > > > Which just shows it's working as intended. > > However the third test should be a without moveToConst, but storing in a > temporary, i.e. the current best practice. It should output exactly like > the first one, but of course call const begin/end. > > And note the extra move/destruciton in the second example. Yep, well aware of the extra move/destruction. It's the price we pay for saving that extra line of code to define a const variable. > > > > The two unsafe usages are commented out, because they wouldn't compile (good!). > > > Whops, you're absolutely right. My bad. With your proposed implementation: > > > template > > const T moveToConst(T &&t) > > { > > return std::move(t); > > } > > This won't compile when called on a non-const lvalue (the return type > will be a lvalue reference to const, which won't bind to a non-const > rvalue). I stand corrected. > > Which actually makes me think of yet another possibility of misuse, that > is, applying moveToConst to a function returning a const object. That > will compile, using a copy... > > > const QVector getVector(); > > for (auto &obj : moveToConst(getVector()) ~~~ Yes, that would be useless, but at least not UB :) > > > Long story short, I think it's good if we stay away from this in Qt. > Clazy warns you if you "do it wrong", and being a Qt-specific problem, > we better not offer too many ways that could have unpleasant drawbacks. Yea, I can understand that. And since all it saves is a line of code, I guess not worth the trouble. Elvis > > > My 2 c, > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > From elvstone at gmail.com Sun Oct 21 18:45:58 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Sun, 21 Oct 2018 18:45:58 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <4b21d498-c513-53e7-5c20-2e8c88aeb0db@kdab.com> References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> <4b21d498-c513-53e7-5c20-2e8c88aeb0db@kdab.com> Message-ID: Den sön 21 okt. 2018 kl 17:50 skrev Giuseppe D'Angelo : > > Hello, > > Il 21/10/18 16:15, Elvis Stansvik ha scritto: > > I couldn't find a way to contact them. > > The best shot would be the std-discussion mailing list, I think. > > > In order to try out the unsafe usage you suggested in your other mail, > > and also another unsafe usage pointed out in an SO question > > (https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612), > > I made the following test program. > > > > The output when running is: > > > > [estan at newton move-to-const-test]$ ./move-to-const-test > > without moveToConst: > > FooPrivate constr from vector > > Foo constr with arg 0x7fffdb627200 > > Foo begin 0x7fffdb627200 > > Foo end 0x7fffdb627200 > > Foo destr 0x7fffdb627200 > > FooPrivate destr > > > > with moveToConst: > > FooPrivate constr from vector > > Foo constr with arg 0x7fffdb627208 > > Foo move constr 0x7fffdb627210 > > Foo destr 0x7fffdb627208 > > Foo begin const 0x7fffdb627210 > > Foo end const 0x7fffdb627210 > > Foo destr 0x7fffdb627210 > > FooPrivate destr > > [estan at newton move-to-const-test]$ > > > > Which just shows it's working as intended. > > However the third test should be a without moveToConst, but storing in a > temporary, i.e. the current best practice. It should output exactly like > the first one, but of course call const begin/end. For completeness sake, indeed qDebug() << "with recommended way:"; const auto stuff = f(); for (auto v : stuff) { Q_UNUSED(v); } gives with recommended way: FooPrivate constr from vector Foo constr with arg 0x7ffdc9d50040 Foo begin const 0x7ffdc9d50040 Foo end const 0x7ffdc9d50040 Foo destr 0x7ffdc9d50040 FooPrivate destr as expected. Elvis > > And note the extra move/destruciton in the second example. > > > > The two unsafe usages are commented out, because they wouldn't compile (good!). > > > Whops, you're absolutely right. My bad. With your proposed implementation: > > > template > > const T moveToConst(T &&t) > > { > > return std::move(t); > > } > > This won't compile when called on a non-const lvalue (the return type > will be a lvalue reference to const, which won't bind to a non-const > rvalue). I stand corrected. > > Which actually makes me think of yet another possibility of misuse, that > is, applying moveToConst to a function returning a const object. That > will compile, using a copy... > > > const QVector getVector(); > > for (auto &obj : moveToConst(getVector()) ~~~ > > > Long story short, I think it's good if we stay away from this in Qt. > Clazy warns you if you "do it wrong", and being a Qt-specific problem, > we better not offer too many ways that could have unpleasant drawbacks. > > > My 2 c, > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > From Ch.Ehrlicher at gmx.de Sun Oct 21 19:59:56 2018 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Sun, 21 Oct 2018 19:59:56 +0200 Subject: [Development] Deprecated functions / procedure of removal in Qt6? Message-ID: Hi, there are a lot of deprecated functions in qtbase which are only marked as deprecated/obsolete in the documentation but don't have a Q_DECL_DEPRECATED. Most of them were deprecated in the pre Qt5-era. What's the 'correct' way to make sure they can be removed with Qt6? Must they marked as QT_DEPRECATED_SINCE(5,x) or is the comment in the documentation enough? Thx, Christian From Ch.Ehrlicher at gmx.de Sun Oct 21 20:07:38 2018 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Sun, 21 Oct 2018 20:07:38 +0200 Subject: [Development] Un-inlining members allowed? Message-ID: <4dc3ad8d-a5a1-bcaa-2a5b-979d57a8f001@gmx.de> Hi, one more question - is it ok to un-inline a function? For example I want to move QListWidgetItem::isSelected() to the cpp file so I can properly mark QListWidget::isItemSelected() as deprecated but I'm unsure if this is allowed. Thx, Christian From thiago.macieira at intel.com Sun Oct 21 22:12:21 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 21 Oct 2018 13:12:21 -0700 Subject: [Development] Un-inlining members allowed? In-Reply-To: <4dc3ad8d-a5a1-bcaa-2a5b-979d57a8f001@gmx.de> References: <4dc3ad8d-a5a1-bcaa-2a5b-979d57a8f001@gmx.de> Message-ID: <1683606.qhyJTPArz6@tjmaciei-mobl1> On Sunday, 21 October 2018 11:07:38 PDT Christian Ehrlicher wrote: > Hi, > > one more question - is it ok to un-inline a function? For example I want > to move QListWidgetItem::isSelected() to the cpp file so I can properly > mark QListWidget::isItemSelected() as deprecated but I'm unsure if this > is allowed. De-inlining is binary and source compatible, so long as you accept that the old code that did inline the function continues to do what it used o do. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From giuseppe.dangelo at kdab.com Mon Oct 22 00:14:16 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 22 Oct 2018 00:14:16 +0200 Subject: [Development] Deprecated functions / procedure of removal in Qt6? In-Reply-To: References: Message-ID: <55576ef3-700a-f20d-f259-b6236ccb7fcb@kdab.com> Hi, Il 21/10/18 19:59, Christian Ehrlicher ha scritto: > there are a lot of deprecated functions in qtbase which are only marked > as deprecated/obsolete in the documentation but don't have a > Q_DECL_DEPRECATED. Most of them were deprecated in the pre Qt5-era. > What's the 'correct' way to make sure they can be removed with Qt6? Must > they marked as QT_DEPRECATED_SINCE(5,x) or is the comment in the > documentation enough? The documentation comment is enough for us to justify the removal -- in other words, "formally", we have informed the user to move away, and the rule is that we can drop deprecated functions any time we want to break source compatibility. However, it's nowhere enough to 1) make users _aware_ of the fact that they're using deprecated APIs; 2) make us _remember_ to remove those functions when we have the chance (like in Qt 6). Thus, adding deprecation warnings is definitely the right thing to do: users get the deprecation warnings (*), and we have an easy way to find and drop all those functions. The other ways to achieve 2) at the moment are: * If possible, all the code to be killed in Qt 6 should already be protected via > #if QT_VERSION < QT_VERSION_CHECK(6, 0, 0) * Add some comment in the source code like // ### Qt 6: remove this Both ways are more general and apply to functions we can't just deprecate or remove (f.i., marking an overload to be merged with another one via a default argument, getting rid of useless special member function declarations, and the like). Of course, simply leaving a comment requires us to remember find those usages and act on those, and the code is still full of such TODOs for Qt 5... (*) I don't like that the deprecation warnings are opt-in and not opt-out. People deserve to know as soon as possible that they're using deprecated functionality, rather than have a gigantic unpleasant surprise ("you're using lots of deprecated stuff that got removed!") when Qt 6 comes. My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From jani.heikkinen at qt.io Mon Oct 22 06:30:27 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 22 Oct 2018 04:30:27 +0000 Subject: [Development] HEADS UP : Qt 5.12 string freeze In-Reply-To: References: , Message-ID: Hi, As informed earlier string freeze for Qt 5.12 is now in effect. So please, no changes to translatable strings from this point, unless approved by the documentation team. br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Thursday, October 11, 2018 7:50 AM To: localization at qt-project.org Cc: development at qt-project.org; releasing at qt-project.org Subject: [Development] HEADS UP : Qt 5.12 soft string freeze Hi all, First beta release from Qt 5.12 is already out so it is time to start keeping translatable strings as it is. And let's have official string freeze Fri 19th October 2018. br, Jani From Ch.Ehrlicher at gmx.de Mon Oct 22 07:05:37 2018 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Mon, 22 Oct 2018 07:05:37 +0200 Subject: [Development] Deprecated functions / procedure of removal in Qt6? In-Reply-To: <55576ef3-700a-f20d-f259-b6236ccb7fcb@kdab.com> References: <55576ef3-700a-f20d-f259-b6236ccb7fcb@kdab.com> Message-ID: <180f1276-a395-951d-7a7f-b57a1430728b@gmx.de> Am 22.10.2018 um 00:14 schrieb Giuseppe D'Angelo via Development: > Hi, > > Thus, adding deprecation warnings is definitely the right thing to do: > users get the deprecation warnings (*), and we have an easy way to > find and drop all those functions. > Ok, I'll go on with adding Q_DECL_DEPRECATED + QT_VERSION < QT_VERSION_CHECK(6, 0, 0) in the places where only the documentation states that this function is deprecated then. Otherwise they might get forgotten again :) Thx, Christian From elvstone at gmail.com Mon Oct 22 08:15:50 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Mon, 22 Oct 2018 08:15:50 +0200 Subject: [Development] Deprecated functions / procedure of removal in Qt6? In-Reply-To: <55576ef3-700a-f20d-f259-b6236ccb7fcb@kdab.com> References: <55576ef3-700a-f20d-f259-b6236ccb7fcb@kdab.com> Message-ID: Den mån 22 okt. 2018 kl 00:14 skrev Giuseppe D'Angelo via Development : > > Hi, > > Il 21/10/18 19:59, Christian Ehrlicher ha scritto: > > there are a lot of deprecated functions in qtbase which are only marked > > as deprecated/obsolete in the documentation but don't have a > > Q_DECL_DEPRECATED. Most of them were deprecated in the pre Qt5-era. > > What's the 'correct' way to make sure they can be removed with Qt6? Must > > they marked as QT_DEPRECATED_SINCE(5,x) or is the comment in the > > documentation enough? > > The documentation comment is enough for us to justify the removal -- in > other words, "formally", we have informed the user to move away, and the > rule is that we can drop deprecated functions any time we want to break > source compatibility. > > > However, it's nowhere enough to > > 1) make users _aware_ of the fact that they're using deprecated APIs; > 2) make us _remember_ to remove those functions when we have the chance > (like in Qt 6). > > Thus, adding deprecation warnings is definitely the right thing to do: > users get the deprecation warnings (*), and we have an easy way to find > and drop all those functions. > > The other ways to achieve 2) at the moment are: > > * If possible, all the code to be killed in Qt 6 should already be > protected via > > > #if QT_VERSION < QT_VERSION_CHECK(6, 0, 0) > > > * Add some comment in the source code like > > // ### Qt 6: remove this > > > Both ways are more general and apply to functions we can't just > deprecate or remove (f.i., marking an overload to be merged with another > one via a default argument, getting rid of useless special member > function declarations, and the like). > > Of course, simply leaving a comment requires us to remember find those > usages and act on those, and the code is still full of such TODOs for Qt > 5... > > > (*) I don't like that the deprecation warnings are opt-in and not > opt-out. People deserve to know as soon as possible that they're using > deprecated functionality, rather than have a gigantic unpleasant > surprise ("you're using lots of deprecated stuff that got removed!") > when Qt 6 comes. +1 for opt-out from a user. I had forgotten to add this to the build of our application. Will be interesting to see what it'll turn up :p Elvis > > > My 2 c, > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From kde at carewolf.com Mon Oct 22 09:55:48 2018 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Mon, 22 Oct 2018 09:55:48 +0200 Subject: [Development] Un-inlining members allowed? In-Reply-To: <4dc3ad8d-a5a1-bcaa-2a5b-979d57a8f001@gmx.de> References: <4dc3ad8d-a5a1-bcaa-2a5b-979d57a8f001@gmx.de> Message-ID: <11191178.O9o76ZdvQC@twilight> On Sonntag, 21. Oktober 2018 20:07:38 CEST Christian Ehrlicher wrote: > Hi, > > one more question - is it ok to un-inline a function? For example I want > to move QListWidgetItem::isSelected() to the cpp file so I can properly > mark QListWidget::isItemSelected() as deprecated but I'm unsure if this > is allowed. > That should work, though it seems unnecessary. In any case you will need to disable the warnings around the code using the deprecated API. 'Allan From giuseppe.dangelo at kdab.com Mon Oct 22 10:00:36 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 22 Oct 2018 10:00:36 +0200 Subject: [Development] Deprecated functions / procedure of removal in Qt6? In-Reply-To: <180f1276-a395-951d-7a7f-b57a1430728b@gmx.de> References: <55576ef3-700a-f20d-f259-b6236ccb7fcb@kdab.com> <180f1276-a395-951d-7a7f-b57a1430728b@gmx.de> Message-ID: <5ffa8421-f323-00de-010b-4afd2ef07642@kdab.com> Il 22/10/18 07:05, Christian Ehrlicher ha scritto: > Ok, I'll go on with adding Q_DECL_DEPRECATED + QT_VERSION < > QT_VERSION_CHECK(6, 0, 0) in the places where only the documentation > states that this function is deprecated then. Otherwise they might get > forgotten again :) Q_DEPRECATED_SINCE should be enough in this case -- as in Qt 6 we can just bump it to "5.99" and kill all the deprecated code in one go, effectively achieving the same thing one does with QT_VERSION_CHECK. Thanks, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From edward.welbourne at qt.io Mon Oct 22 11:52:52 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 22 Oct 2018 09:52:52 +0000 Subject: [Development] Un-inlining members allowed? In-Reply-To: <11191178.O9o76ZdvQC@twilight> References: <4dc3ad8d-a5a1-bcaa-2a5b-979d57a8f001@gmx.de>, <11191178.O9o76ZdvQC@twilight> Message-ID: On Sonntag, 21. Oktober 2018 20:07:38 CEST Christian Ehrlicher wrote: >>> one more question - is it ok to un-inline a function? For example I >>> want to move QListWidgetItem::isSelected() to the cpp file so I can >>> properly mark QListWidget::isItemSelected() as deprecated but I'm >>> unsure if this is allowed. Please be sure to summarise the change in a [ChangeLog][Potentially Source-Incompatible Changes] in your commit message; see [QUIP 6] * [QUIP 6] https://quips-qt-io.herokuapp.com/quip-0006.html Thiago Macieira (21 October 2018 22:12) replied: >> De-inlining is binary and source compatible, so long as you accept >> that the old code that did inline the function continues to do what it >> used o do. and (independently) Allan Sandfeld Jensen (22 October 2018 09:55) replied: > That should work, though it seems unnecessary. In any case you will > need to disable the warnings around the code using the deprecated API. This appears to be an instance of [QUIP 6]'s Examples section saying: Issues not listed here should be discussed on the mailing-list and then added here. Unless someone else (e.g. Allan or Thiago) beats me to it (I'm busy with a 3rd-party review ...), I guess I'll try to summarise the above as another example; apparently this is in Category A. If someone else gets there first, please add me as a reviewer, so I know when to update the published version. (hmm ... I think an update may be in order anyway.) Eddy. From jani.heikkinen at qt.io Mon Oct 22 17:45:01 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 22 Oct 2018 15:45:01 +0000 Subject: [Development] HEADS-UP: Branching from '5.12' to '5.12.0' started Message-ID: Hi, We have soft branched '5.12.0' from '5.12'. Please start using '5.12.0' for new changes targeted to Qt 5.12.0 release. Final downmerge from '5.12' to '5.12.0' will happen Mon 29th October so there should be enough time to finalize ongoing changes in '5.12' and start using '5.12.0'. Target is to release Qt 5.12.0 RC mid November so it is time to fix remaining blockers from blocker list (https://bugreports.qt.io/issues/?filter=19961) BR, Jani From apoenitz at t-online.de Mon Oct 22 21:40:29 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Mon, 22 Oct 2018 21:40:29 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> Message-ID: <20181022194029.GA2661@klara.mpi.htwm.de> On Sun, Oct 21, 2018 at 04:15:58PM +0200, Elvis Stansvik wrote: > In order to try out the unsafe usage you suggested in your other mail, > and also another unsafe usage pointed out in an SO question > (https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612), > I made the following test program. > > The output when running is: > > [estan at newton move-to-const-test]$ ./move-to-const-test > without moveToConst: > FooPrivate constr from vector > Foo constr with arg 0x7fffdb627200 > Foo begin 0x7fffdb627200 > Foo end 0x7fffdb627200 > Foo destr 0x7fffdb627200 > FooPrivate destr > > with moveToConst: > FooPrivate constr from vector > Foo constr with arg 0x7fffdb627208 > Foo move constr 0x7fffdb627210 > Foo destr 0x7fffdb627208 > Foo begin const 0x7fffdb627210 > Foo end const 0x7fffdb627210 > Foo destr 0x7fffdb627210 > FooPrivate destr > [estan at newton move-to-const-test]$ > > Which just shows it's working as intended. I have (a) no example that triggers obviously bad behaviour and (b) a bad gut feeling nevertheless. The problem is that a 'move' could be a 'swap' in practice, with the to-be-destroyed object held 'for a while', effectively turning C++'s rather deterministic destruction behaviour into something resembling garbage collection. I wouldn't be surprised if one can cause real problems with 'random' destruction orders on non-memory resources, like files. Simple memory might be safe(r), as releasing order does typically not matter. Andre' From giuseppe.dangelo at kdab.com Mon Oct 22 21:45:40 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 22 Oct 2018 21:45:40 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <20181022194029.GA2661@klara.mpi.htwm.de> References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> <20181022194029.GA2661@klara.mpi.htwm.de> Message-ID: <0105a78f-9590-cd7d-97a0-18efdaaeac86@kdab.com> Hi, Il 22/10/18 21:40, André Pönitz ha scritto: >> Which just shows it's working as intended. > I have (a) no example that triggers obviously bad behaviour and (b) > a bad gut feeling nevertheless. What bad behaviour are we referring to here? > > The problem is that a 'move' could be a 'swap' in practice, with the > to-be-destroyed object held 'for a while', effectively turning C++'s > rather deterministic destruction behaviour into something resembling > garbage collection. > > I wouldn't be surprised if one can cause real problems with 'random' > destruction orders on non-memory resources, like files. Simple memory > might be safe(r), as releasing order does typically not matter. Oh, it absolutely does. That's why in Qt we implement move assignment in terms of pure swap if and only if the only resource that a container holds is memory (e.g. QString, QByteArray). For all other cases (e.g. QVector) we implement move assignment as move-and-swap, to be sure that resources are deterministically destroyed when the move happens. My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From jani.heikkinen at qt.io Tue Oct 23 10:57:25 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 23 Oct 2018 08:57:25 +0000 Subject: [Development] Qt 5.9.7 released In-Reply-To: References: Message-ID: Hi, We have released Qt 5.9.7 today, see http://blog.qt.io/blog/2018/10/23/qt-5-9-7-released/ Big thanks to everyone involved! br, Jani Heikkinen Release Manager From Richard.Gustavsen at qt.io Tue Oct 23 15:32:35 2018 From: Richard.Gustavsen at qt.io (Richard Gustavsen) Date: Tue, 23 Oct 2018 13:32:35 +0000 Subject: [Development] Un-inlining members allowed? In-Reply-To: References: <4dc3ad8d-a5a1-bcaa-2a5b-979d57a8f001@gmx.de>, <11191178.O9o76ZdvQC@twilight>, Message-ID: Even if it's binary compatible, it sounds fragile. If the inlined function is e.g accessing symbols from the private class, someone might later come along and remove those symbols if they appear not to be used from anywhere, unknowingly of the fact that some apps still do through an old inlined version. -Richard ________________________________ Fra: Development på vegne av Edward Welbourne Sendt: mandag 22. oktober 2018 11.52.52 Til: Christian Ehrlicher Kopi: development at qt-project.org; Allan at qt-project.org; Thiago Macieira Emne: Re: [Development] Un-inlining members allowed? On Sonntag, 21. Oktober 2018 20:07:38 CEST Christian Ehrlicher wrote: >>> one more question - is it ok to un-inline a function? For example I >>> want to move QListWidgetItem::isSelected() to the cpp file so I can >>> properly mark QListWidget::isItemSelected() as deprecated but I'm >>> unsure if this is allowed. Please be sure to summarise the change in a [ChangeLog][Potentially Source-Incompatible Changes] in your commit message; see [QUIP 6] * [QUIP 6] https://quips-qt-io.herokuapp.com/quip-0006.html Thiago Macieira (21 October 2018 22:12) replied: >> De-inlining is binary and source compatible, so long as you accept >> that the old code that did inline the function continues to do what it >> used o do. and (independently) Allan Sandfeld Jensen (22 October 2018 09:55) replied: > That should work, though it seems unnecessary. In any case you will > need to disable the warnings around the code using the deprecated API. This appears to be an instance of [QUIP 6]'s Examples section saying: Issues not listed here should be discussed on the mailing-list and then added here. Unless someone else (e.g. Allan or Thiago) beats me to it (I'm busy with a 3rd-party review ...), I guess I'll try to summarise the above as another example; apparently this is in Category A. If someone else gets there first, please add me as a reviewer, so I know when to update the published version. (hmm ... I think an update may be in order anyway.) Eddy. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf.hermann at qt.io Wed Oct 24 09:17:09 2018 From: ulf.hermann at qt.io (Ulf Hermann) Date: Wed, 24 Oct 2018 07:17:09 +0000 Subject: [Development] QUIP 12: Code of Conduct Message-ID: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Hi, regarding our earlier discussions on a possible Code of Conduct, here as well as at the Contributors' Summit 2017, I've pushed a QUIP with the necessary rules and definitions: https://codereview.qt-project.org/243623 Please review it. regards, Ulf From announce at qt-project.org Wed Oct 24 14:14:32 2018 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Wed, 24 Oct 2018 12:14:32 +0000 Subject: [Development] [Announce] Qt Creator 4.7.2 released Message-ID: We are happy to announce the release of Qt Creator 4.7.2! https://blog.qt.io/blog/2018/10/24/qt-creator-4-7-2-released/ -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From announce at qt-project.org Wed Oct 24 14:29:14 2018 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Wed, 24 Oct 2018 12:29:14 +0000 Subject: [Development] [Announce] Qt Creator 4.7.2 released Message-ID: We are happy to announce the release of Qt Creator 4.7.2! https://blog.qt.io/blog/2018/10/24/qt-creator-4-7-2-released/ -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From hgoldfish at gmail.com Wed Oct 24 15:51:09 2018 From: hgoldfish at gmail.com (=?UTF-8?B?6buE5YW25rO9?=) Date: Wed, 24 Oct 2018 21:51:09 +0800 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: I think the committee should reserve a seat for women. It must be a woman or a woman's dresser to be appointed. This must be written into Code Of Conduct. Ulf Hermann 于2018年10月24日周三 下午3:17写道: > Hi, > > regarding our earlier discussions on a possible Code of Conduct, here as > well as at the Contributors' Summit 2017, I've pushed a QUIP with the > necessary rules and definitions: > > https://codereview.qt-project.org/243623 > > Please review it. > > regards, > Ulf > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Python及Qt相关Blog:http://hgoldfish.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhihn at gmx.com Wed Oct 24 17:09:58 2018 From: jhihn at gmx.com (Jason H) Date: Wed, 24 Oct 2018 17:09:58 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: I am whole-heartedly against a Code of Conduct. While well-intentioned, anyone following the shit-show that is the Linux kernel code of conduct fiasco, I also think would be against the code of conduct as well. Immediately after imposing the Code of Conduct, past tweets by contributors and the accusations started flying and it devolved from there. In addition to several authorities on Open Source weighed in that yes, contributors can revoke the copyright of their prior contributions, which was threatened by those accused. Which would leave any software in a lurch. Now, it looks like those contributors might go to BSD... Having been interested in software from a very young age, and later specifically Open Source, one thing that appealed to me was that it was a meritocracy. The best code survives, your code contributions are limited only by your code being the best. Now we're saying it's not just your code, but also your behavior. We had an ideal, we had THE ideal - a place where only our ideas mattered. A place where nothing else mattered - not your gentatilia, your sexual identity, not your partner preference, not your political party - none of it. It was purely about lines of code. It was elegant and beautiful, and brutally simple. And now the social justice warriors are contaminating that perfection with code+conduct. So it goes from "this is the best code that could be written" to "this is the best code that could be written from an individual whose political ideals match our own". If we adopt this, does that mean there is a [git commit hook| gerrit review] installed that evaluates the contributor's social media to find controversial posts? If we adopt this, how do we assure we don't wind up in a Sarah Jeong situation (She's racist against white people, but the New York Times says that's "ok")? - How do assure that white people are adequately protected against reverse racism? -- Do we even agree that reverse racism [is possible to] exist(s) If we adopt this, what exactly are the political ideas a Qt contributor must espouse? - Are stances against illegal immigration "racist"? - Is "Sceintific racism" actual racism or just statistics? -- In a matter closer to home, where are we on James Damore situation? Would he be banned from this community? NONE of those questions should need to be contemplated by an Open Source software project. Open Source is about the Source. Not the source of the Source. In case it needs to be said- I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. But I am also against people judging other people's code for factors that have nothing to do with the code itself. I find that adding a value judgement of conduct to code to be intolerant. We had the ideal. I am FOR inclusion. I want everyone to feel welcome here. Everyone. We might identify as a "community" as we are people, but really we're an open source project, and at the end of the day what matters the most is what is in git. I oppose any Code of Conduct. And demand the answers be provided to the above questions PRIOR to passage (if it happens). I really want to know where we are with James Damore because I thought his paper was well-researched with a scientific basis? > Sent: Wednesday, October 24, 2018 at 3:17 AM > From: "Ulf Hermann" > To: "development at qt-project.org" > Subject: [Development] QUIP 12: Code of Conduct > > Hi, > > regarding our earlier discussions on a possible Code of Conduct, here as > well as at the Contributors' Summit 2017, I've pushed a QUIP with the > necessary rules and definitions: > > https://codereview.qt-project.org/243623 > > Please review it. > > regards, > Ulf > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From aleixpol at kde.org Wed Oct 24 17:42:59 2018 From: aleixpol at kde.org (Aleix Pol) Date: Wed, 24 Oct 2018 17:42:59 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: On Wed, Oct 24, 2018 at 5:10 PM Jason H wrote: > > I am whole-heartedly against a Code of Conduct. While well-intentioned, anyone following the shit-show that is the Linux kernel code of conduct fiasco, I also think would be against the code of conduct as well. > > Immediately after imposing the Code of Conduct, past tweets by contributors and the accusations started flying and it devolved from there. In addition to several authorities on Open Source weighed in that yes, contributors can revoke the copyright of their prior contributions, which was threatened by those accused. Which would leave any software in a lurch. Now, it looks like those contributors might go to BSD... > > Having been interested in software from a very young age, and later specifically Open Source, one thing that appealed to me was that it was a meritocracy. The best code survives, your code contributions are limited only by your code being the best. Now we're saying it's not just your code, but also your behavior. We had an ideal, we had THE ideal - a place where only our ideas mattered. A place where nothing else mattered - not your gentatilia, your sexual identity, not your partner preference, not your political party - none of it. It was purely about lines of code. It was elegant and beautiful, and brutally simple. And now the social justice warriors are contaminating that perfection with code+conduct. So it goes from "this is the best code that could be written" to "this is the best code that could be written from an individual whose political ideals match our own". > > If we adopt this, does that mean there is a [git commit hook| gerrit review] installed that evaluates the contributor's social media to find controversial posts? > If we adopt this, how do we assure we don't wind up in a Sarah Jeong situation (She's racist against white people, but the New York Times says that's "ok")? > - How do assure that white people are adequately protected against reverse racism? > -- Do we even agree that reverse racism [is possible to] exist(s) > If we adopt this, what exactly are the political ideas a Qt contributor must espouse? > - Are stances against illegal immigration "racist"? > - Is "Sceintific racism" actual racism or just statistics? > -- In a matter closer to home, where are we on James Damore situation? Would he be banned from this community? > > NONE of those questions should need to be contemplated by an Open Source software project. Open Source is about the Source. Not the source of the Source. > > In case it needs to be said- > I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. But I am also against people judging other people's code for factors that have nothing to do with the code itself. I find that adding a value judgement of conduct to code to be intolerant. We had the ideal. > I am FOR inclusion. I want everyone to feel welcome here. Everyone. > > We might identify as a "community" as we are people, but really we're an open source project, and at the end of the day what matters the most is what is in git. > > I oppose any Code of Conduct. And demand the answers be provided to the above questions PRIOR to passage (if it happens). > > I really want to know where we are with James Damore because I thought his paper was well-researched with a scientific basis? > > > > > Sent: Wednesday, October 24, 2018 at 3:17 AM > > From: "Ulf Hermann" > > To: "development at qt-project.org" > > Subject: [Development] QUIP 12: Code of Conduct > > > > Hi, > > > > regarding our earlier discussions on a possible Code of Conduct, here as > > well as at the Contributors' Summit 2017, I've pushed a QUIP with the > > necessary rules and definitions: > > > > https://codereview.qt-project.org/243623 > > > > Please review it. > > > > regards, > > Ulf Dear Jason, I fail to see how you can feel entitled to give your opinion when you've done nothing to earn that right (I can't find any significant contribution by you), especially when it comes to oppose something that was agreed together with the rest of the contributors. I don't think you have even read the proposal. If you want to play with the grown-ups, act like one first. Aleix From jhihn at gmx.com Wed Oct 24 17:51:11 2018 From: jhihn at gmx.com (Jason H) Date: Wed, 24 Oct 2018 17:51:11 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: Under the Code of Conduct, Can Aleix Pol receive discipline for his/her/their message? > Sent: Wednesday, October 24, 2018 at 11:42 AM > From: "Aleix Pol" > To: development > Subject: Re: [Development] QUIP 12: Code of Conduct > > On Wed, Oct 24, 2018 at 5:10 PM Jason H wrote: > > > > I am whole-heartedly against a Code of Conduct. While well-intentioned, anyone following the shit-show that is the Linux kernel code of conduct fiasco, I also think would be against the code of conduct as well. > > > > Immediately after imposing the Code of Conduct, past tweets by contributors and the accusations started flying and it devolved from there. In addition to several authorities on Open Source weighed in that yes, contributors can revoke the copyright of their prior contributions, which was threatened by those accused. Which would leave any software in a lurch. Now, it looks like those contributors might go to BSD... > > > > Having been interested in software from a very young age, and later specifically Open Source, one thing that appealed to me was that it was a meritocracy. The best code survives, your code contributions are limited only by your code being the best. Now we're saying it's not just your code, but also your behavior. We had an ideal, we had THE ideal - a place where only our ideas mattered. A place where nothing else mattered - not your gentatilia, your sexual identity, not your partner preference, not your political party - none of it. It was purely about lines of code. It was elegant and beautiful, and brutally simple. And now the social justice warriors are contaminating that perfection with code+conduct. So it goes from "this is the best code that could be written" to "this is the best code that could be written from an individual whose political ideals match our own". > > > > If we adopt this, does that mean there is a [git commit hook| gerrit review] installed that evaluates the contributor's social media to find controversial posts? > > If we adopt this, how do we assure we don't wind up in a Sarah Jeong situation (She's racist against white people, but the New York Times says that's "ok")? > > - How do assure that white people are adequately protected against reverse racism? > > -- Do we even agree that reverse racism [is possible to] exist(s) > > If we adopt this, what exactly are the political ideas a Qt contributor must espouse? > > - Are stances against illegal immigration "racist"? > > - Is "Sceintific racism" actual racism or just statistics? > > -- In a matter closer to home, where are we on James Damore situation? Would he be banned from this community? > > > > NONE of those questions should need to be contemplated by an Open Source software project. Open Source is about the Source. Not the source of the Source. > > > > In case it needs to be said- > > I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. But I am also against people judging other people's code for factors that have nothing to do with the code itself. I find that adding a value judgement of conduct to code to be intolerant. We had the ideal. > > I am FOR inclusion. I want everyone to feel welcome here. Everyone. > > > > We might identify as a "community" as we are people, but really we're an open source project, and at the end of the day what matters the most is what is in git. > > > > I oppose any Code of Conduct. And demand the answers be provided to the above questions PRIOR to passage (if it happens). > > > > I really want to know where we are with James Damore because I thought his paper was well-researched with a scientific basis? > > > > > > > > > Sent: Wednesday, October 24, 2018 at 3:17 AM > > > From: "Ulf Hermann" > > > To: "development at qt-project.org" > > > Subject: [Development] QUIP 12: Code of Conduct > > > > > > Hi, > > > > > > regarding our earlier discussions on a possible Code of Conduct, here as > > > well as at the Contributors' Summit 2017, I've pushed a QUIP with the > > > necessary rules and definitions: > > > > > > https://codereview.qt-project.org/243623 > > > > > > Please review it. > > > > > > regards, > > > Ulf > > Dear Jason, > I fail to see how you can feel entitled to give your opinion when > you've done nothing to earn that right (I can't find any significant > contribution by you), especially when it comes to oppose something > that was agreed together with the rest of the contributors. > > I don't think you have even read the proposal. If you want to play > with the grown-ups, act like one first. > > Aleix > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From Marco.Bubke at qt.io Wed Oct 24 18:20:56 2018 From: Marco.Bubke at qt.io (Marco Bubke) Date: Wed, 24 Oct 2018 16:20:56 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io>, Message-ID: Hallo Jason > It was purely about lines of code. It was elegant and beautiful, and brutally simple. This is aesthetics and if you would reflect about it with other you could find out that is very context sensitive. My experience in this area is that their are many people who prefer interaction with computer to interaction with different people. 😉 Many people use a platonic language all the time without any reflection about the problems of that language. And this is creating friction, much friction, and not the kind of productive friction. Is it not nice to understand if other people have a different aesthetic view of how code should look? It's my experience which is shaping my context. And I believe it's the same for you. So I think that our context is different. So if we work together should we not respect different contexts and try to understand them. Use that difference to create something better. Is that not better than connect our work with our self and let discussion easily get highly emotional? What do you think is the outcome of this culture? I don't believe that this highly emotional, sometimes rude, culture is creating the best source code! I think it is driving many talented people away. Best, Marco ________________________________ From: Development on behalf of Jason H Sent: Wednesday, October 24, 2018 5:09:58 PM To: Ulf Hermann Cc: development at qt-project.org Subject: Re: [Development] QUIP 12: Code of Conduct I am whole-heartedly against a Code of Conduct. While well-intentioned, anyone following the shit-show that is the Linux kernel code of conduct fiasco, I also think would be against the code of conduct as well. Immediately after imposing the Code of Conduct, past tweets by contributors and the accusations started flying and it devolved from there. In addition to several authorities on Open Source weighed in that yes, contributors can revoke the copyright of their prior contributions, which was threatened by those accused. Which would leave any software in a lurch. Now, it looks like those contributors might go to BSD... Having been interested in software from a very young age, and later specifically Open Source, one thing that appealed to me was that it was a meritocracy. The best code survives, your code contributions are limited only by your code being the best. Now we're saying it's not just your code, but also your behavior. We had an ideal, we had THE ideal - a place where only our ideas mattered. A place where nothing else mattered - not your gentatilia, your sexual identity, not your partner preference, not your political party - none of it. It was purely about lines of code. It was elegant and beautiful, and brutally simple. And now the social justice warriors are contaminating that perfection with code+conduct. So it goes from "this is the best code that could be written" to "this is the best code that could be written from an individual whose political ideals match our own". If we adopt this, does that mean there is a [git commit hook| gerrit review] installed that evaluates the contributor's social media to find controversial posts? If we adopt this, how do we assure we don't wind up in a Sarah Jeong situation (She's racist against white people, but the New York Times says that's "ok")? - How do assure that white people are adequately protected against reverse racism? -- Do we even agree that reverse racism [is possible to] exist(s) If we adopt this, what exactly are the political ideas a Qt contributor must espouse? - Are stances against illegal immigration "racist"? - Is "Sceintific racism" actual racism or just statistics? -- In a matter closer to home, where are we on James Damore situation? Would he be banned from this community? NONE of those questions should need to be contemplated by an Open Source software project. Open Source is about the Source. Not the source of the Source. In case it needs to be said- I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. But I am also against people judging other people's code for factors that have nothing to do with the code itself. I find that adding a value judgement of conduct to code to be intolerant. We had the ideal. I am FOR inclusion. I want everyone to feel welcome here. Everyone. We might identify as a "community" as we are people, but really we're an open source project, and at the end of the day what matters the most is what is in git. I oppose any Code of Conduct. And demand the answers be provided to the above questions PRIOR to passage (if it happens). I really want to know where we are with James Damore because I thought his paper was well-researched with a scientific basis? > Sent: Wednesday, October 24, 2018 at 3:17 AM > From: "Ulf Hermann" > To: "development at qt-project.org" > Subject: [Development] QUIP 12: Code of Conduct > > Hi, > > regarding our earlier discussions on a possible Code of Conduct, here as > well as at the Contributors' Summit 2017, I've pushed a QUIP with the > necessary rules and definitions: > > https://codereview.qt-project.org/243623 > > Please review it. > > regards, > Ulf > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhihn at gmx.com Wed Oct 24 18:22:35 2018 From: jhihn at gmx.com (Jason H) Date: Wed, 24 Oct 2018 18:22:35 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: 1. The code of conduct or invitation to contribute says nothing about "earning a right" 2. What are considered qualifying "contributions"? I've been using Qt since 2004. I assure you I've had some influence, be it bug reports, participating in the mailing lists (like now.) 3. How many of these contributions do I need? How are they measured? 4. I was given the opportunity to contribute at this time by a open invite. I have accounts on the various services to be able to contribute. So I did. 5. I wonder if you have even read the proposal yourself. You seem very entitled to have an opinion, so I assume you would, but why then would you write a message that clearly is in violation of acceptable behavior? Lines 52, 53, 56. Examples of unacceptable behavior by participants include: 49 50 * The use of sexualized language or imagery and unwelcome sexual attention or advances 51 * Trolling, insulting/derogatory comments, and personal or political attacks 52 * Public or private harassment 53 * Publishing others’ private information, such as a physical or electronic address, without explicit 54 permission 55 * Other conduct which could reasonably be considered inappropriate in a professional setting 56 Your email raises several questions, and both of my eyebrows. 1. You seem to think that there is an "entitlement" mechanic at work. If so, we need to define that? 2. You seem to have a metric for "contributions" we need to define that? 3. How does your message contribute to a "positive environment"? Examples of behavior that contributes to creating a positive environment include: 41 42 * Using welcoming and inclusive language 43 * Being respectful of differing viewpoints and experiences 44 * Gracefully accepting constructive criticism 45 * Focusing on what is best for the community 46 * Showing empathy towards other community members I didn't expect everyone to agree with me. But I did not expect your message to be the way it was. > Sent: Wednesday, October 24, 2018 at 11:42 AM > From: "Aleix Pol" > To: development > Subject: Re: [Development] QUIP 12: Code of Conduct > > On Wed, Oct 24, 2018 at 5:10 PM Jason H wrote: > > > > I am whole-heartedly against a Code of Conduct. While well-intentioned, anyone following the shit-show that is the Linux kernel code of conduct fiasco, I also think would be against the code of conduct as well. > > > > Immediately after imposing the Code of Conduct, past tweets by contributors and the accusations started flying and it devolved from there. In addition to several authorities on Open Source weighed in that yes, contributors can revoke the copyright of their prior contributions, which was threatened by those accused. Which would leave any software in a lurch. Now, it looks like those contributors might go to BSD... > > > > Having been interested in software from a very young age, and later specifically Open Source, one thing that appealed to me was that it was a meritocracy. The best code survives, your code contributions are limited only by your code being the best. Now we're saying it's not just your code, but also your behavior. We had an ideal, we had THE ideal - a place where only our ideas mattered. A place where nothing else mattered - not your gentatilia, your sexual identity, not your partner preference, not your political party - none of it. It was purely about lines of code. It was elegant and beautiful, and brutally simple. And now the social justice warriors are contaminating that perfection with code+conduct. So it goes from "this is the best code that could be written" to "this is the best code that could be written from an individual whose political ideals match our own". > > > > If we adopt this, does that mean there is a [git commit hook| gerrit review] installed that evaluates the contributor's social media to find controversial posts? > > If we adopt this, how do we assure we don't wind up in a Sarah Jeong situation (She's racist against white people, but the New York Times says that's "ok")? > > - How do assure that white people are adequately protected against reverse racism? > > -- Do we even agree that reverse racism [is possible to] exist(s) > > If we adopt this, what exactly are the political ideas a Qt contributor must espouse? > > - Are stances against illegal immigration "racist"? > > - Is "Sceintific racism" actual racism or just statistics? > > -- In a matter closer to home, where are we on James Damore situation? Would he be banned from this community? > > > > NONE of those questions should need to be contemplated by an Open Source software project. Open Source is about the Source. Not the source of the Source. > > > > In case it needs to be said- > > I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. But I am also against people judging other people's code for factors that have nothing to do with the code itself. I find that adding a value judgement of conduct to code to be intolerant. We had the ideal. > > I am FOR inclusion. I want everyone to feel welcome here. Everyone. > > > > We might identify as a "community" as we are people, but really we're an open source project, and at the end of the day what matters the most is what is in git. > > > > I oppose any Code of Conduct. And demand the answers be provided to the above questions PRIOR to passage (if it happens). > > > > I really want to know where we are with James Damore because I thought his paper was well-researched with a scientific basis? > > > > > > > > > Sent: Wednesday, October 24, 2018 at 3:17 AM > > > From: "Ulf Hermann" > > > To: "development at qt-project.org" > > > Subject: [Development] QUIP 12: Code of Conduct > > > > > > Hi, > > > > > > regarding our earlier discussions on a possible Code of Conduct, here as > > > well as at the Contributors' Summit 2017, I've pushed a QUIP with the > > > necessary rules and definitions: > > > > > > https://codereview.qt-project.org/243623 > > > > > > Please review it. > > > > > > regards, > > > Ulf > > Dear Jason, > I fail to see how you can feel entitled to give your opinion when > you've done nothing to earn that right (I can't find any significant > contribution by you), especially when it comes to oppose something > that was agreed together with the rest of the contributors. > > I don't think you have even read the proposal. If you want to play > with the grown-ups, act like one first. > > Aleix > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From denis.shienkov at gmail.com Wed Oct 24 18:31:59 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Wed, 24 Oct 2018 19:31:59 +0300 Subject: [Development] Does QGeoPositionInfoSource work from an Android service? Message-ID: Hi all, I tried to make it work from the Android service: #include #include #include #include Q_LOGGING_CATEGORY(APP, "bug.svc") int main(int argc, char *argv[]) { QAndroidService::setAttribute(Qt::AA_EnableHighDpiScaling); QAndroidService app(argc, argv); qCDebug(APP) << "I'm service"; const auto t = new QTimer(qApp); QCoreApplication::connect(t, &QTimer::timeout, []() { static int counter = 0; qCWarning(APP) << "CNT:" << counter; ++counter; }); t->start(1000); const auto ps = QGeoPositionInfoSource::createDefaultSource(qApp); QCoreApplication::connect(ps, &QGeoPositionInfoSource::positionUpdated, [=](const QGeoPositionInfo &update) { const auto coord = update.coordinate(); qCDebug(APP) << "CRD:" << coord; }); ps->setUpdateInterval(3000); ps->startUpdates(); return app.exec(); } but a service, seems, crashed at all (at least I did not see any debugging log from the logcat). But if I try to cemment out all code, related to the locations, and keep a code with the timer, then I see the counters output. I tried it on Android x86 && Qt 5.11.2 && Android API 21. E.g. from here: https://stackoverflow.com/questions/13345002/locationmanager-in-service I see that it is possible to wotk with Android's LocationManager from the service... BUT, it does not work with QGeoPositionInfoSource! BR, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From nassian at bitshift-dynamics.com Wed Oct 24 18:58:46 2018 From: nassian at bitshift-dynamics.com (Alexander Nassian) Date: Wed, 24 Oct 2018 18:58:46 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: <1CE147F8-502E-4C1E-B2B0-746BAC28F288@bitshift-dynamics.com> Arrogant mails like this from you are the reason why CoD are popping even up. Talking about the right of „playing with the grown ups“ but writing so much BS that would already violate the proposed CoD. > Am 24.10.2018 um 17:42 schrieb Aleix Pol : > > On Wed, Oct 24, 2018 at 5:10 PM Jason H wrote: >> >> I am whole-heartedly against a Code of Conduct. While well-intentioned, anyone following the shit-show that is the Linux kernel code of conduct fiasco, I also think would be against the code of conduct as well. >> >> Immediately after imposing the Code of Conduct, past tweets by contributors and the accusations started flying and it devolved from there. In addition to several authorities on Open Source weighed in that yes, contributors can revoke the copyright of their prior contributions, which was threatened by those accused. Which would leave any software in a lurch. Now, it looks like those contributors might go to BSD... >> >> Having been interested in software from a very young age, and later specifically Open Source, one thing that appealed to me was that it was a meritocracy. The best code survives, your code contributions are limited only by your code being the best. Now we're saying it's not just your code, but also your behavior. We had an ideal, we had THE ideal - a place where only our ideas mattered. A place where nothing else mattered - not your gentatilia, your sexual identity, not your partner preference, not your political party - none of it. It was purely about lines of code. It was elegant and beautiful, and brutally simple. And now the social justice warriors are contaminating that perfection with code+conduct. So it goes from "this is the best code that could be written" to "this is the best code that could be written from an individual whose political ideals match our own". >> >> If we adopt this, does that mean there is a [git commit hook| gerrit review] installed that evaluates the contributor's social media to find controversial posts? >> If we adopt this, how do we assure we don't wind up in a Sarah Jeong situation (She's racist against white people, but the New York Times says that's "ok")? >> - How do assure that white people are adequately protected against reverse racism? >> -- Do we even agree that reverse racism [is possible to] exist(s) >> If we adopt this, what exactly are the political ideas a Qt contributor must espouse? >> - Are stances against illegal immigration "racist"? >> - Is "Sceintific racism" actual racism or just statistics? >> -- In a matter closer to home, where are we on James Damore situation? Would he be banned from this community? >> >> NONE of those questions should need to be contemplated by an Open Source software project. Open Source is about the Source. Not the source of the Source. >> >> In case it needs to be said- >> I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. But I am also against people judging other people's code for factors that have nothing to do with the code itself. I find that adding a value judgement of conduct to code to be intolerant. We had the ideal. >> I am FOR inclusion. I want everyone to feel welcome here. Everyone. >> >> We might identify as a "community" as we are people, but really we're an open source project, and at the end of the day what matters the most is what is in git. >> >> I oppose any Code of Conduct. And demand the answers be provided to the above questions PRIOR to passage (if it happens). >> >> I really want to know where we are with James Damore because I thought his paper was well-researched with a scientific basis? >> >> >> >>> Sent: Wednesday, October 24, 2018 at 3:17 AM >>> From: "Ulf Hermann" >>> To: "development at qt-project.org" >>> Subject: [Development] QUIP 12: Code of Conduct >>> >>> Hi, >>> >>> regarding our earlier discussions on a possible Code of Conduct, here as >>> well as at the Contributors' Summit 2017, I've pushed a QUIP with the >>> necessary rules and definitions: >>> >>> https://codereview.qt-project.org/243623 >>> >>> Please review it. >>> >>> regards, >>> Ulf > > Dear Jason, > I fail to see how you can feel entitled to give your opinion when > you've done nothing to earn that right (I can't find any significant > contribution by you), especially when it comes to oppose something > that was agreed together with the rest of the contributors. > > I don't think you have even read the proposal. If you want to play > with the grown-ups, act like one first. > > Aleix > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: info at bitshift-dynamics.com Technischer Support: support at bitshift-dynamics.com Buchhaltung: invoice at bitshift-dynamics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhihn at gmx.com Wed Oct 24 19:20:35 2018 From: jhihn at gmx.com (Jason H) Date: Wed, 24 Oct 2018 19:20:35 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Wed Oct 24 19:21:12 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 24 Oct 2018 17:21:12 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io>, Message-ID: Jason H (24 October 2018 17:09) > - Is "Sceintific racism" actual racism or just statistics? If it's racism, it's racism, however qualified. Extrapolation from populations to individuals misuses statistics. It isn't scientific, it just abuses tools lifted out of science. > I really want to know where we are with James Damore because I thought > his paper was well-researched with a scientific basis? I had to look that name up. While no source is unbiased, I'll take [0] as a tolerable source. They do, at least, have a fairly solid understanding of what science is (and isn't). * [0] https://rationalwiki.org/wiki/James_Damore Apparently he fails to understand the difference between very minor statistical differences between broad populations and the details of individuals. Specifically: though the proportion of women who are good at certain tech jobs might be marginally smaller than the proportion of men who are, a recruiter who has the economic power of Google and commits to recruiting equally should be able to do so, without compromising its recruitment standards, provided there aren't *other factors* at play that prevent it from doing so. The crucial detail here is that Google employs a tiny proportion of the population from which it could draw recruits. So half of Google's relevant technical staff - which is how many women Google would need to hire to meet the given goal - fits well within the available pool of suitably-skilled women. Google would (in this hypothetical world) have to work a little harder and pay a little more (but it's only a little, since the statistical effect is quite small in fact) to find the women than to find the men, but it's not short of applicants and Google, in particular, has expertise in the field of selecting the best few from a plethora of candidates - at least when it comes to pointing one at web pages. The fact that Google doesn't manage to hire equally many good women as men in various tech positions *is* evidence that there are other factors at play, aside from the scientific evidence of very minor differences in aptitude (mostly stemming from differences in interest). It is, furthermore, patently clear that the world does have other factors that contribute to the gender divide in various jobs. When boards are dominated by men, it is no great surprise that women aren't as widely represented in upper management, from the ranks of which most boards are drawn, to take just one example. But this is something of a digression. > Having been interested in software from a very young age, and later > specifically Open Source, one thing that appealed to me was that it > was a meritocracy. Well, many software practitioners at least aim to make software projects meritocratic. However, their ability to do so may be compromised by social dynamics (and economics) in various ways. > The best code survives, your code contributions are limited only by > your code being the best. If those evaluating how good something is are, unwittingly, operating in an environment that some folk find hostile, those folk get driven off and the evaluators fail to see how good their contributions would have been, if they'd only felt at ease. The aim of a code of conduct is to avoid that. I endure rudery from others moderately calmly, partly because I come from a highly-privileged background that gives me the confidence to not worry that the rudery will actually cause problems I can't handle. I prefer, and usually manage, to work in environments in which I and those around me don't need to endure such rudery - partly because, while I can endure it, I don't like it; but also because I don't want others to be driven away, whose contributions I might welcome. There may be bad codes of conduct out there; please don't let that put you off trying to think about what a good code of conduct would look like. In particular, note that there are some "entrenched interests" that don't seem to like codes of conduct; and they've taken pains to talk up the misadventures of groups struggling to make them work. Other groups, garnering far less publicity, have bumbled along quite happily for years with codes of conduct that seem to work fine. So please don't just write off the code of conduct as a bad plan; try to help us make a good code of conduct and a good process around it. In particular, please at least read it before criticising it, Eddy. From jhihn at gmx.com Wed Oct 24 19:49:28 2018 From: jhihn at gmx.com (Jason H) Date: Wed, 24 Oct 2018 19:49:28 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: Thank you Edward. I am doing that, but "out loud" if you will, on this group. I am asking questions and getting answers (you're the first to actually answer any of my questions). I am committed to having a free and inclusive community, but with Linux Kernel just having gone through this, and the fall-out still on going, I personally would have us wait to see how that turns out before proceeding with our own. I would like to learn from their mistakes. So far (but after your email was written) I replied with concerns about 1) the Committee, -- the allocation of seats to specific birth demographics -- the politics of said committee ---- members having to embrace the politics of the said committee. -- the personal weight of members being affected by their contributions, in terms of testimony or punishment. 2) having received a message from someone who was pro-CoC, but whose message clearly in violation of the CoC. -- If that is acceptable, then why have a CoC at all? I'm asking a lot of questions and reading all the answers. I appreciate your substantive reply. Here's an operable suggestion: Choose the committee members at random, per each incident, from the list active users at random. Keep choosing until 3 users have indicated they would participate. That would be the best way to avoid most of the concerns I questioned about. > Sent: Wednesday, October 24, 2018 at 1:21 PM > From: "Edward Welbourne" > To: "Jason H" > Cc: "development at qt-project.org" , "Ulf Hermann" > Subject: Re: [Development] QUIP 12: Code of Conduct > > Jason H (24 October 2018 17:09) > > - Is "Sceintific racism" actual racism or just statistics? > > If it's racism, it's racism, however qualified. > Extrapolation from populations to individuals misuses statistics. > It isn't scientific, it just abuses tools lifted out of science. > > > I really want to know where we are with James Damore because I thought > > his paper was well-researched with a scientific basis? > > I had to look that name up. > While no source is unbiased, I'll take [0] as a tolerable source. > They do, at least, have a fairly solid understanding of what science is > (and isn't). > > * [0] https://rationalwiki.org/wiki/James_Damore > > Apparently he fails to understand the difference between very minor > statistical differences between broad populations and the details of > individuals. > > Specifically: though the proportion of women who are good at certain > tech jobs might be marginally smaller than the proportion of men who > are, a recruiter who has the economic power of Google and commits to > recruiting equally should be able to do so, without compromising its > recruitment standards, provided there aren't *other factors* at play > that prevent it from doing so. The crucial detail here is that Google > employs a tiny proportion of the population from which it could draw > recruits. So half of Google's relevant technical staff - which is how > many women Google would need to hire to meet the given goal - fits well > within the available pool of suitably-skilled women. > > Google would (in this hypothetical world) have to work a little harder > and pay a little more (but it's only a little, since the statistical > effect is quite small in fact) to find the women than to find the men, > but it's not short of applicants and Google, in particular, has > expertise in the field of selecting the best few from a plethora of > candidates - at least when it comes to pointing one at web pages. The > fact that Google doesn't manage to hire equally many good women as men > in various tech positions *is* evidence that there are other factors at > play, aside from the scientific evidence of very minor differences in > aptitude (mostly stemming from differences in interest). > > It is, furthermore, patently clear that the world does have other > factors that contribute to the gender divide in various jobs. When > boards are dominated by men, it is no great surprise that women aren't > as widely represented in upper management, from the ranks of which most > boards are drawn, to take just one example. > But this is something of a digression. > > > Having been interested in software from a very young age, and later > > specifically Open Source, one thing that appealed to me was that it > > was a meritocracy. > > Well, many software practitioners at least aim to make software projects > meritocratic. However, their ability to do so may be compromised by > social dynamics (and economics) in various ways. > > > The best code survives, your code contributions are limited only by > > your code being the best. > > If those evaluating how good something is are, unwittingly, operating in > an environment that some folk find hostile, those folk get driven off > and the evaluators fail to see how good their contributions would have > been, if they'd only felt at ease. The aim of a code of conduct is to > avoid that. > > I endure rudery from others moderately calmly, partly because I come > from a highly-privileged background that gives me the confidence to not > worry that the rudery will actually cause problems I can't handle. I > prefer, and usually manage, to work in environments in which I and those > around me don't need to endure such rudery - partly because, while I can > endure it, I don't like it; but also because I don't want others to be > driven away, whose contributions I might welcome. > > There may be bad codes of conduct out there; please don't let that put > you off trying to think about what a good code of conduct would look > like. In particular, note that there are some "entrenched interests" > that don't seem to like codes of conduct; and they've taken pains to > talk up the misadventures of groups struggling to make them work. Other > groups, garnering far less publicity, have bumbled along quite happily > for years with codes of conduct that seem to work fine. > > So please don't just write off the code of conduct as a bad plan; try to > help us make a good code of conduct and a good process around it. > In particular, please at least read it before criticising it, > > Eddy. > From aapo.keskimolo at qt.io Wed Oct 24 20:16:49 2018 From: aapo.keskimolo at qt.io (=?iso-8859-1?Q?Aapo_Keskim=F6l=F6?=) Date: Wed, 24 Oct 2018 18:16:49 +0000 Subject: [Development] Coin production update Message-ID: Good evening dear Qt Developers, Coin production has been updated on Wed Oct 20 21:09 EEST 2018. See attached change log for related patches. Ystävällisin terveisin / Kind regards, Aapo Keskimölö | Senior Software Engineer | Coin Software Lead aapo.keskimolo at qt.io | +358 44 559 2378 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: product_baseline_20181024.log Type: application/octet-stream Size: 25937 bytes Desc: product_baseline_20181024.log URL: From apoenitz at t-online.de Wed Oct 24 20:32:08 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Wed, 24 Oct 2018 20:32:08 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: <20181024183208.GA30598@klara.mpi.htwm.de> On Wed, Oct 24, 2018 at 05:42:59PM +0200, Aleix Pol wrote: > On Wed, Oct 24, 2018 at 5:10 PM Jason H wrote: > > > > I am whole-heartedly against a Code of Conduct. [...] > > > > > > Hi, > > > > > > regarding our earlier discussions on a possible Code of Conduct, here as > > > well as at the Contributors' Summit 2017, I've pushed a QUIP with the > > > necessary rules and definitions: > > > > > > https://codereview.qt-project.org/243623 > > > > > > Please review it. > > > > > > regards, Ulf > > Dear Jason, I fail to see how you can feel entitled to give your opinion when > you've done nothing to earn that right The Governance Model states that "The Qt Project is a meritocratic, consensus-based community interested in Qt. "Anyone who shares that interest can join the community, participate in its decision making processes, and contribute to Qt's development. " Jason has shown his interest in Qt multiple times. According to this definition he is clearly a member of the community, he is under the current rules fully entitled to take part in the decision making process and state his opinion. Andre' PS: > (I can't find any significant contribution by you), especially when it comes > to oppose something that was agreed together with the rest of the contributors. > > I don't think you have even read the proposal. If you want to play with the > grown-ups, act like one first. I refrain from commenting this further. From enmarantispam at gmail.com Wed Oct 24 20:40:40 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Wed, 24 Oct 2018 21:40:40 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <20181024183208.GA30598@klara.mpi.htwm.de> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <20181024183208.GA30598@klara.mpi.htwm.de> Message-ID: Looking from outside: Qt has always seemed the community that just dpesn't need something like that to regulate itself. Explicit Code seems like an alien entity and ppl already trying to enforce "at least one female" rise all kinds of warning flags in my eyes. Personally, I only see the potential to strangle creativity and turning ppl off from joining in enforcing such a code without any benefit other than "to look civilized" On Wed, Oct 24, 2018 at 9:32 PM André Pönitz wrote: > On Wed, Oct 24, 2018 at 05:42:59PM +0200, Aleix Pol wrote: > > On Wed, Oct 24, 2018 at 5:10 PM Jason H wrote: > > > > > > I am whole-heartedly against a Code of Conduct. [...] > > > > > > > > Hi, > > > > > > > > regarding our earlier discussions on a possible Code of Conduct, > here as > > > > well as at the Contributors' Summit 2017, I've pushed a QUIP with the > > > > necessary rules and definitions: > > > > > > > > https://codereview.qt-project.org/243623 > > > > > > > > Please review it. > > > > > > > > regards, Ulf > > > > Dear Jason, I fail to see how you can feel entitled to give your opinion > when > > you've done nothing to earn that right > > The Governance Model states that > > "The Qt Project is a meritocratic, consensus-based community interested > in Qt. > > "Anyone who shares that interest can join the community, participate in > its > decision making processes, and contribute to Qt's development. " > > Jason has shown his interest in Qt multiple times. According to this > definition > he is clearly a member of the community, he is under the current rules > fully > entitled to take part in the decision making process and state his opinion. > > Andre' > > PS: > > > (I can't find any significant contribution by you), especially when it > comes > > to oppose something that was agreed together with the rest of the > contributors. > > > > I don't think you have even read the proposal. If you want to play with > the > > grown-ups, act like one first. > > I refrain from commenting this further. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kshegunov at gmail.com Thu Oct 25 01:19:26 2018 From: kshegunov at gmail.com (Konstantin Shegunov) Date: Thu, 25 Oct 2018 02:19:26 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: I think you're over-engineering the whole thing and you don't drive the point of such a document home. My best suggestion is to simplify (heavily) the process and the phrasing. Firstly and most importantly drop the heavy and redundant wording, e.g. " ... pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, ..." "everyone" is already all those things. Unless your point was to write a constitution, just state what you mean simply, plainly and succinctly. Helps in reading, understanding and proceeding to implement. On that note hardly will I be convinced that a new (or seasoned) contributor waste the time to read through something that's longer than half a page instead of diving into the heart of the matter, which is to write code, improve docs or w/e. Addendum: There's too much vague phrasing. When I was reading through the text I read things of the sort: "Showing empathy towards other community members" and "Other conduct which could reasonably be considered inappropriate in a professional setting" and what I thought was "What's that nonsense?! empathy?!". What is wrong with stating it directly - "Don't be mean, respect others."? Here's what Tero wrote on the boards (shortened the tips about language, which shrunk it by about 5%-10%) as a guideline for moderators: *The short moderation and banning guideline for the Qt Forum* > First, the Qt Community is in general a friendly place. When you applied > or were called to be a moderator, several other moderators read a good > section of your posts, and agreed that you are very friendly towards to > community in addition to being knowledgeable in Qt. Thank you, and keep up > the friendly attitude! Always assume that the person asking has a real valid problem. Trolls and > ranters are very rare here, so it's best to assume that a person sounding > aggressive is just having a bad day, or that english is their third or > second language. The language barrier may cause the question to sound > strange. [...] In general the following types of posts will be deleted > obvious spam > 'support' phone numbers > obviously non-Qt services and sites > backlink spam (spam with links to a completely non-Qt site, with the > intention of raising search engine rankings) > swearing > completely off topic posting > posting the same question in multiple subforums (remember to post a note > on the one you leave up) > Banning is in place when: > The user posts harmful spam > Abusive behaviour, swearing and being offensive > It's reasonable, short enough, easy to comprehend and apply. Secondly, that whole committee thing is somewhat of a stretch in my mind. It's going to be much more practical to have one contact person to "shuffle the paper" and consider complaints/issues, answering questions about and for the community, helping newer persons to get on with the program and so on. Election can be by majority voting ran for a reasonable time period (say 1 week) from a pool of proposed candidates. Alternatively, as the community is somewhat dispersed over different media - forums, mailing lists, IRC and so on a person for each of the channels mentioned can be elected. On that note the proposed CoC doesn't take into account that specific, for one we mostly police ourselves in the forum, and I imagine people have an operator on IRC, but it's not clear how the committee is supposed to operate on the different channels, are they to be omnipresent? Thirdly, and I'll stop with my ramblings, there will always be grating between people that work on something together for extended periods, no matter if it's a huge C++ library or some triviality. If you try to stop all of it, what my feeling of the proposed document is, brace yourselves, you're going to fail miserably. I'd rather suggest handling the extreme cases only and leave people blow off steam once in a while. Disruptions to good order are more often than not correctable by a simple private notice. Or to quote Sze-Howe Koh: There are 2 ways to ensure that things don't get done in an open project: > > 1. Spend so much time molly-coddling everyone such that there is > little time left to do actual work > 2. Drive so many (potential) contributors away such that there are few > people left to do actual work > > Somewhere in the middle of these two extremes is the sweet spot where > people are neither molly-coddled nor driven away, and maximal work gets > done. That is the spot a project wants to reach. PS I don't know why that (half-)political argument about women, hiring, google, and whatnot, spun off but I see no relevance to the document, nor did I read anything remotely related to it in the text. So let's drop it, shall we? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf.hermann at qt.io Thu Oct 25 07:52:20 2018 From: ulf.hermann at qt.io (Ulf Hermann) Date: Thu, 25 Oct 2018 05:52:20 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: <7e5d95d2-4c6e-45c2-ff45-38f17f8c29d0@qt.io> > 1. The code of conduct or invitation to contribute says nothing about "earning a right" The QUIP process follows the lazy consensus mechanism. See QUIP 2 and QUIP 3. Jason Hihn is not an Approver. Ulf From ulf.hermann at qt.io Thu Oct 25 07:56:53 2018 From: ulf.hermann at qt.io (Ulf Hermann) Date: Thu, 25 Oct 2018 05:56:53 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: <1dcf8ce4-d161-a995-74f5-4383f8521b9b@qt.io> On 10/24/18 3:51 PM, 黄其泽 wrote: > I think the committee should reserve a seat for women. It must be a > woman or a woman's dresser to be appointed. This must be written into > Code Of Conduct. This should not be codified in the QUIP. It would make the respective language much more complicated and possibly open loopholes that we can't foresee. The barrier of having one woman on the Committee is very low already. All it takes (following the current proposal) is two Approvers to second an initial proposal. So, if only 3 Approvers feel the way you do, we will have a woman on the Committee. Ulf From ulf.hermann at qt.io Thu Oct 25 08:06:15 2018 From: ulf.hermann at qt.io (Ulf Hermann) Date: Thu, 25 Oct 2018 06:06:15 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: On 10/25/18 1:19 AM, Konstantin Shegunov wrote: > I  think you're over-engineering the whole thing and you don't drive the > point of such a document home. My best suggestion is to simplify > (heavily) the process and the phrasing. The CoC is not only a guide on how to behave, but also a "welcome" message to new contributors. Therefore, there may be slightly redundant language in there which specifically addresses people currently under-represented in the Qt community. > Secondly, that whole committee thing is somewhat of a stretch in my > mind. It's going to be much more practical to have one contact person to > "shuffle the paper" and consider complaints/issues, answering questions > about and for the community, helping newer persons to get on with the > program and so on. Election can be by majority voting ran for a > reasonable time period (say 1 week) from a pool of proposed candidates. > Alternatively, as the community is somewhat dispersed over different > media - forums, mailing lists, IRC and so on a person for each of the > channels mentioned can be elected. On that note the proposed CoC doesn't > take into account that specific, for one we mostly police ourselves in > the forum, and I imagine people have an operator on IRC, but it's not > clear how the committee is supposed to operate on the differen > channels, are they to be omnipresent? Phrasing this proposal in a water-proof way would require more wording and a much more complicated process than the current proposal. The CoC has to withstand conflict, and in a conflict each party will try to find loop holes. > Thirdly, and I'll stop with my ramblings, there will always be grating > between people that work on something together for extended periods, no > matter if it's a huge C++ library or some triviality. If you try to stop > all of it, what my feeling of the proposed document is, brace > yourselves, you're going to fail miserably. I'd rather suggest handling > the extreme cases only and leave people blow off steam once in a while. > Disruptions to good order are more often than not correctable by a > simple private notice. The Committee has the option of only handing out "a private reprimand" in case of minor misconduct. See section "Resolutions". Ulf From thiago.macieira at intel.com Thu Oct 25 08:12:03 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 24 Oct 2018 23:12:03 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <7e5d95d2-4c6e-45c2-ff45-38f17f8c29d0@qt.io> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <7e5d95d2-4c6e-45c2-ff45-38f17f8c29d0@qt.io> Message-ID: <2335266.GDr32fRLeu@tjmaciei-mobl1> On Wednesday, 24 October 2018 22:52:20 PDT Ulf Hermann wrote: > The QUIP process follows the lazy consensus mechanism. See QUIP 2 and > QUIP 3. Jason Hihn is not an Approver. Approvership or maintainership are not required to state opinions. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ulf.hermann at qt.io Thu Oct 25 08:17:52 2018 From: ulf.hermann at qt.io (Ulf Hermann) Date: Thu, 25 Oct 2018 06:17:52 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2335266.GDr32fRLeu@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <7e5d95d2-4c6e-45c2-ff45-38f17f8c29d0@qt.io> <2335266.GDr32fRLeu@tjmaciei-mobl1> Message-ID: > On Wednesday, 24 October 2018 22:52:20 PDT Ulf Hermann wrote: >> The QUIP process follows the lazy consensus mechanism. See QUIP 2 and >> QUIP 3. Jason Hihn is not an Approver. > > Approvership or maintainership are not required to state opinions. Correct. However, someone who is not an Approver can neither give a -2 nor a +2 for a change on gerrit. Therefore the invitation to review the QUIP does implicitly say something about "earning a right". Ulf From Ryan.Chu at qt.io Thu Oct 25 08:31:03 2018 From: Ryan.Chu at qt.io (Ryan Chu) Date: Thu, 25 Oct 2018 06:31:03 +0000 Subject: [Development] Does QGeoPositionInfoSource work from an Android service? Message-ID: Hi Denis, > but a service, seems, crashed at all (at least I did not see any debugging log from the logcat). Regarding to the "crashed symptom", have you checked the value of 'ps' before setting setUpdateInterval? (Qt Docs - QGeoPositionInfoSource::createDefaultSource) "Returns 0 if the system has no default position source, no valid plugins could be found or the user does not have the permission to access the current position." Best regards, Ryan ________________________________ From: Development on behalf of Denis Shienkov Sent: Wednesday, October 24, 2018 6:31 PM To: development at qt-project.org; Alex Blasche; BogDan Vatra Subject: [Development] Does QGeoPositionInfoSource work from an Android service? Hi all, I tried to make it work from the Android service: #include #include #include #include Q_LOGGING_CATEGORY(APP, "bug.svc") int main(int argc, char *argv[]) { QAndroidService::setAttribute(Qt::AA_EnableHighDpiScaling); QAndroidService app(argc, argv); qCDebug(APP) << "I'm service"; const auto t = new QTimer(qApp); QCoreApplication::connect(t, &QTimer::timeout, []() { static int counter = 0; qCWarning(APP) << "CNT:" << counter; ++counter; }); t->start(1000); const auto ps = QGeoPositionInfoSource::createDefaultSource(qApp); QCoreApplication::connect(ps, &QGeoPositionInfoSource::positionUpdated, [=](const QGeoPositionInfo &update) { const auto coord = update.coordinate(); qCDebug(APP) << "CRD:" << coord; }); ps->setUpdateInterval(3000); ps->startUpdates(); return app.exec(); } but a service, seems, crashed at all (at least I did not see any debugging log from the logcat). But if I try to cemment out all code, related to the locations, and keep a code with the timer, then I see the counters output. I tried it on Android x86 && Qt 5.11.2 && Android API 21. E.g. from here: https://stackoverflow.com/questions/13345002/locationmanager-in-service [https://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-icon at 2.png?v=73d79a89bded] android - LocationManager in service - Stack Overflow stackoverflow.com Tour Start here for a quick overview of the site Help Center Detailed answers to any questions you might have Meta Discuss the workings and policies of this site ... I see that it is possible to wotk with Android's LocationManager from the service... BUT, it does not work with QGeoPositionInfoSource! BR, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at qt.io Thu Oct 25 08:31:19 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Thu, 25 Oct 2018 06:31:19 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: > On 24 Oct 2018, at 17:09, Jason H wrote: > > In case it needs to be said- > I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. But I am also against people judging other people's code for factors that have nothing to do with the code itself. I find that adding a value judgement of conduct to code to be intolerant. We had the ideal. > I am FOR inclusion. I want everyone to feel welcome here. Everyone. I agree. It seems to be about fixing something that isn’t broken, or as in that story in the Bible where the people came to a consensus that every other country around them had a king, so they should have a king too. Nothing good came out of it in any cases where we have seen this kind of illogic applied. “Most other big corporations have a deep hierarchy of management, with too much power concentrated at the top, and we want to be a big corporation, so we need to replicate that.” “The other lemmings are running away so maybe we’d better follow.” It’s not the open source way, which seemed to be working well enough already. If you give power to a committee of 3 people, they will probably abuse it eventually, misjudge, cause bitterness, create factions, and some developers will end up walking away. Seems predictable, doesn’t it? From thiago.macieira at intel.com Thu Oct 25 08:34:56 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 24 Oct 2018 23:34:56 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <2335266.GDr32fRLeu@tjmaciei-mobl1> Message-ID: <3934503.9pbxuRyCSd@tjmaciei-mobl1> On Wednesday, 24 October 2018 23:17:52 PDT Ulf Hermann wrote: > > On Wednesday, 24 October 2018 22:52:20 PDT Ulf Hermann wrote: > >> The QUIP process follows the lazy consensus mechanism. See QUIP 2 and > >> QUIP 3. Jason Hihn is not an Approver. > > > > Approvership or maintainership are not required to state opinions. > > Correct. However, someone who is not an Approver can neither give a -2 > nor a +2 for a change on gerrit. Therefore the invitation to review the > QUIP does implicitly say something about "earning a right". What you state is correct, but also besides the point. QUIPs are the writing down of community decisions. They were created to summarise conclusions from the mailing list discussions. Approvership is not required to participate in those. The Gerrit review system is later used to perfect the language of the text, but not to change its essence. And you don't need to be an approver to post comments there, or give +1 and -1 for that matter. I don't know of any contributions of code that Jason H may have made, nonetheless his email deserves to be read and answered. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ulf.hermann at qt.io Thu Oct 25 08:39:09 2018 From: ulf.hermann at qt.io (Ulf Hermann) Date: Thu, 25 Oct 2018 06:39:09 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: <290e4179-4791-31a6-7eb6-3b44c087e60f@qt.io> > Here's what Tero wrote on the boards (shortened the tips about language, > which shrunk it by about 5%-10%) as a guideline for moderators: > > *The short moderation and banning guideline for the Qt Forum* > First, the Qt Community is in general a friendly place. When you > applied or were called to be a moderator, several other moderators > read a good section of your posts, and agreed that you are very > friendly towards to community in addition to being knowledgeable in > Qt. Thank you, and keep up the friendly attitude! > > Always assume that the person asking has a real valid problem. > Trolls and ranters are very rare here, so it's best to assume that a > person sounding aggressive is just having a bad day, or that english > is their third or second language. The language barrier may cause > the question to sound strange. > >  [...] > > In general the following types of posts will be deleted > obvious spam > 'support' phone numbers > obviously non-Qt services and sites > backlink spam (spam with links to a completely non-Qt site, with the > intention of raising search engine rankings) > swearing > completely off topic posting > posting the same question in multiple subforums (remember to post a > note on the one you leave up) > Banning is in place when: > The user posts harmful spam > Abusive behaviour, swearing and being offensive > > > It's reasonable, short enough, easy to comprehend and apply. Most of the problems listed there are much too harmless to invoke the code of conduct about them and the "abuse" clause is too vague: * Spammers of all kinds are generally not long time community members and will just disappear when you confront them. There is no point in designing an elaborate process for removing spam. That should just stay as it is. * Offtopic and multi-posting is not a thing the Code of Conduct should cover. The Code of Conduct is for behavior that's actually hurtful to someone. * Swearing is one of the things the Committee might handle with a private reprimand. This is sufficiently covered by the current proposal. * Abusive behavior is what the code of conduct is actually about and that needs to be defined in more detail. Hence the more elaborate wording. Ulf From alexander.blasche at qt.io Thu Oct 25 08:42:18 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Thu, 25 Oct 2018 06:42:18 +0000 Subject: [Development] Does QGeoPositionInfoSource work from an Android service? In-Reply-To: References: Message-ID: Hi Denis, At least in the past it worked as I remember having tested the use case. Do you have a backtrace? And yes, Ryan's comment is correct in that you are missing essential error checking in your code. -- Alex ________________________________________ From: Denis Shienkov Sent: Wednesday, 24 October 2018 6:31:59 PM To: development at qt-project.org; Alex Blasche; BogDan Vatra Subject: Does QGeoPositionInfoSource work from an Android service? Hi all, I tried to make it work from the Android service: #include #include #include #include Q_LOGGING_CATEGORY(APP, "bug.svc") int main(int argc, char *argv[]) { QAndroidService::setAttribute(Qt::AA_EnableHighDpiScaling); QAndroidService app(argc, argv); qCDebug(APP) << "I'm service"; const auto t = new QTimer(qApp); QCoreApplication::connect(t, &QTimer::timeout, []() { static int counter = 0; qCWarning(APP) << "CNT:" << counter; ++counter; }); t->start(1000); const auto ps = QGeoPositionInfoSource::createDefaultSource(qApp); QCoreApplication::connect(ps, &QGeoPositionInfoSource::positionUpdated, [=](const QGeoPositionInfo &update) { const auto coord = update.coordinate(); qCDebug(APP) << "CRD:" << coord; }); ps->setUpdateInterval(3000); ps->startUpdates(); return app.exec(); } but a service, seems, crashed at all (at least I did not see any debugging log from the logcat). But if I try to cemment out all code, related to the locations, and keep a code with the timer, then I see the counters output. I tried it on Android x86 && Qt 5.11.2 && Android API 21. E.g. from here: https://stackoverflow.com/questions/13345002/locationmanager-in-service I see that it is possible to wotk with Android's LocationManager from the service... BUT, it does not work with QGeoPositionInfoSource! BR, Denis From Simon.Hausmann at qt.io Thu Oct 25 09:11:42 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 25 Oct 2018 07:11:42 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: <857668e0-6209-244a-732f-2415263e6551@qt.io> Am 25.10.18 um 08:31 schrieb Shawn Rutledge: > >> On 24 Oct 2018, at 17:09, Jason H wrote: >> >> In case it needs to be said- >> I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. But I am also against people judging other people's code for factors that have nothing to do with the code itself. I find that adding a value judgement of conduct to code to be intolerant. We had the ideal. >> I am FOR inclusion. I want everyone to feel welcome here. Everyone. > I agree. It seems to be about fixing something that isn’t broken, or as in that story in the Bible where the people came to a consensus that every other country around them had a king, so they should have a king too. Nothing good came out of it in any cases where we have seen this kind of illogic applied. “Most other big corporations have a deep hierarchy of management, with too much power concentrated at the top, and we want to be a big corporation, so we need to replicate that.” “The other lemmings are running away so maybe we’d better follow.” It’s not the open source way, which seemed to be working well enough already. > > If you give power to a committee of 3 people, they will probably abuse it eventually, misjudge, cause bitterness, create factions, and some developers will end up walking away. Seems predictable, doesn’t it? > You claim that this is about fixing something that isn't broken. Your statement that a committee will predictably and eventually abuse their powers and misjudge is, I feel, a statement that is spreading fear, doubt and uncertainty, without any evidence within the scope of this community. On the other hand I am aware of at least one concrete case where the behavior of a reviewer has caused a contributor (with a track record of accepted patches, btw) to turn away from the project and even resulted in an email of complaint sent to the community manager. The lack of tools, written understanding and common agreement on what is good behavior resulted in that nothing happened at all and the contributor in question has stayed away from the project since then. I do think that this is the exception, but it is crucial that we have the right tools and mechanisms in place when unlikely exceptions happen, in order to deal with them instead of ignoring them. After having seen this with my own eyes, I am convinced of that. Whether it is a code of conduct or kindness guidelines - anything like that is something that I welcome as an improvement. Simon From volker.krause at kdab.com Thu Oct 25 09:51:00 2018 From: volker.krause at kdab.com (Volker Krause) Date: Thu, 25 Oct 2018 09:51:00 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <857668e0-6209-244a-732f-2415263e6551@qt.io> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> Message-ID: <2539432.vSGsD3zg6Y@vkpc19> On Thursday, 25 October 2018 09:11:42 CEST Simon Hausmann wrote: > Am 25.10.18 um 08:31 schrieb Shawn Rutledge: > > > > > > >> On 24 Oct 2018, at 17:09, Jason H wrote: > >> > >> > >> > >> In case it needs to be said- > >> I am AGAINST racism, sexism, bigotry, and all the other exclusionary > >> things. But I am also against people judging other people's code for > >> factors that have nothing to do with the code itself. I find that adding > >> a value judgement of conduct to code to be intolerant. We had the > >> ideal. I am FOR inclusion. I want everyone to feel welcome here. > >> Everyone.> > > I agree. It seems to be about fixing something that isn’t broken, or as > > in that story in the Bible where the people came to a consensus that > > every other country around them had a king, so they should have a king > > too. Nothing good came out of it in any cases where we have seen this > > kind of illogic applied. “Most other big corporations have a deep > > hierarchy of management, with too much power concentrated at the top, and > > we want to be a big corporation, so we need to replicate that.” “The > > other lemmings are running away so maybe we’d better follow.” It’s not > > the open source way, which seemed to be working well enough already. > > > > > > > If you give power to a committee of 3 people, they will probably abuse it > > eventually, misjudge, cause bitterness, create factions, and some > > developers will end up walking away. Seems predictable, doesn’t it? > > > > > > You claim that this is about fixing something that isn't broken. Your > statement that a committee will predictably and eventually abuse their > powers and misjudge is, I feel, a > > statement that is spreading fear, doubt and uncertainty, without any > evidence within the scope of this community. > > > On the other hand I am aware of at least one concrete case where the > behavior of a reviewer has caused a contributor (with a track record of > accepted patches, btw) to > > turn away from the project and even resulted in an email of complaint > sent to the community manager. The lack of tools, written understanding > and common agreement > > on what is good behavior resulted in that nothing happened at all and > the contributor in question has stayed away from the project since then. > > > I do think that this is the exception, but it is crucial that we have > the right tools and mechanisms in place when unlikely exceptions happen, > in order to deal with them > > instead of ignoring them. After having seen this with my own eyes, I am > convinced of that. > > > Whether it is a code of conduct or kindness guidelines - anything like > that is something that I welcome as an improvement. > > > Simon +1 We do have a Code of Conduct at KDE for about 10 years now, and this hasn't led to abuse of power, suppression of free speech, racism against white people or whatever other nonsense people seem to attribute to CoCs nowadays. On the contrary, it gave us a solid foundation to act against the (very few, fortunately) cases of abusive behavior to protect our contributors. As Simon I have seen the damage such behavior can do, and therefore would also welcome tools/rules to be in place to deal with such situations. Regards, Volker -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4664 bytes Desc: not available URL: From lars.knoll at qt.io Thu Oct 25 09:58:25 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 25 Oct 2018 07:58:25 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2539432.vSGsD3zg6Y@vkpc19> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> Message-ID: On 25 Oct 2018, at 09:51, Volker Krause via Development > wrote: On Thursday, 25 October 2018 09:11:42 CEST Simon Hausmann wrote: Am 25.10.18 um 08:31 schrieb Shawn Rutledge: On 24 Oct 2018, at 17:09, Jason H > wrote: In case it needs to be said- I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. But I am also against people judging other people's code for factors that have nothing to do with the code itself. I find that adding a value judgement of conduct to code to be intolerant. We had the ideal. I am FOR inclusion. I want everyone to feel welcome here. Everyone.> I agree. It seems to be about fixing something that isn’t broken, or as in that story in the Bible where the people came to a consensus that every other country around them had a king, so they should have a king too. Nothing good came out of it in any cases where we have seen this kind of illogic applied. “Most other big corporations have a deep hierarchy of management, with too much power concentrated at the top, and we want to be a big corporation, so we need to replicate that.” “The other lemmings are running away so maybe we’d better follow.” It’s not the open source way, which seemed to be working well enough already. If you give power to a committee of 3 people, they will probably abuse it eventually, misjudge, cause bitterness, create factions, and some developers will end up walking away. Seems predictable, doesn’t it? You claim that this is about fixing something that isn't broken. Your statement that a committee will predictably and eventually abuse their powers and misjudge is, I feel, a statement that is spreading fear, doubt and uncertainty, without any evidence within the scope of this community. On the other hand I am aware of at least one concrete case where the behavior of a reviewer has caused a contributor (with a track record of accepted patches, btw) to turn away from the project and even resulted in an email of complaint sent to the community manager. The lack of tools, written understanding and common agreement on what is good behavior resulted in that nothing happened at all and the contributor in question has stayed away from the project since then. I do think that this is the exception, but it is crucial that we have the right tools and mechanisms in place when unlikely exceptions happen, in order to deal with them instead of ignoring them. After having seen this with my own eyes, I am convinced of that. Whether it is a code of conduct or kindness guidelines - anything like that is something that I welcome as an improvement. Simon +1 We do have a Code of Conduct at KDE for about 10 years now, and this hasn't led to abuse of power, suppression of free speech, racism against white people or whatever other nonsense people seem to attribute to CoCs nowadays. On the contrary, it gave us a solid foundation to act against the (very few, fortunately) cases of abusive behavior to protect our contributors. As Simon I have seen the damage such behavior can do, and therefore would also welcome tools/rules to be in place to deal with such situations. Regards, Volker I fully agree. And btw, we have had a clear majority in favour of adding a CoC at the Contributor Summit, and explicitly agreed that a group of people will work on creating it. I’m happy we now have a first version, that we can use as a basis for further discussions. Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Thu Oct 25 10:48:35 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 25 Oct 2018 08:48:35 +0000 Subject: [Development] Qt 5.12 beta3 released Message-ID: Hi everyone! We have released Qt 5.12.0 beta3 today. As earlier you can get it via online installer. Delta to beta2 attached. With beta3 we will publish MSVC2017 32bit prebuilt binaries as well as 64bit Android ones. So please check those packages as well to see if those are working as expected. MSVC2015 32bit packages aren't delivered anymore. And as usual please make sure you will report all findings in Jira. Please make sure all Qt 5.12.0 release blockers are visible in release blocker list (https://bugreports.qt.io/issues/?filter=19961) br, Jani Heikkinen Release Manager -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: delta_qt5.12.0-beta2-qt5.12.0-beta3.txt URL: From denis.shienkov at gmail.com Thu Oct 25 11:30:22 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Thu, 25 Oct 2018 12:30:22 +0300 Subject: [Development] Does QGeoPositionInfoSource work from an Android service? In-Reply-To: References: Message-ID: Alex, I have created a bug: https://bugreports.qt.io/browse/QTBUG-71396 Please look on... Denis чт, 25 окт. 2018 г. в 9:42, Alex Blasche : > Hi Denis, > > At least in the past it worked as I remember having tested the use case. > Do you have a backtrace? > > And yes, Ryan's comment is correct in that you are missing essential error > checking in your code. > > -- > Alex > > ________________________________________ > From: Denis Shienkov > Sent: Wednesday, 24 October 2018 6:31:59 PM > To: development at qt-project.org; Alex Blasche; BogDan Vatra > Subject: Does QGeoPositionInfoSource work from an Android service? > > Hi all, > > I tried to make it work from the Android service: > > > #include > > #include > > #include > > #include > > > Q_LOGGING_CATEGORY(APP, "bug.svc") > > > int main(int argc, char *argv[]) > > { > > QAndroidService::setAttribute(Qt::AA_EnableHighDpiScaling); > > QAndroidService app(argc, argv); > > > qCDebug(APP) << "I'm service"; > > > const auto t = new QTimer(qApp); > > QCoreApplication::connect(t, &QTimer::timeout, []() { > > static int counter = 0; > > qCWarning(APP) << "CNT:" << counter; > > ++counter; > > }); > > t->start(1000); > > > const auto ps = QGeoPositionInfoSource::createDefaultSource(qApp); > > QCoreApplication::connect(ps, &QGeoPositionInfoSource::positionUpdated, > > [=](const QGeoPositionInfo &update) { > > const auto coord = update.coordinate(); > > qCDebug(APP) << "CRD:" << coord; > > }); > > ps->setUpdateInterval(3000); > > ps->startUpdates(); > > > return app.exec(); > > } > > but a service, seems, crashed at all (at least I did not see any debugging > log from the logcat). > > But if I try to cemment out all code, related to the locations, and keep a > code with the timer, > then I see the counters output. > > I tried it on Android x86 && Qt 5.11.2 && Android API 21. > > E.g. from here: > https://stackoverflow.com/questions/13345002/locationmanager-in-service > I see that it is possible to wotk with Android's LocationManager from the > service... BUT, > it does not work with QGeoPositionInfoSource! > > BR, > Denis > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafael at roquetto.com Thu Oct 25 11:50:05 2018 From: rafael at roquetto.com (Rafael Roquetto) Date: Thu, 25 Oct 2018 19:50:05 +1000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> Message-ID: <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> I understand this has already been set in stone, and I am not here in the hopes this will change. However, I do feel like I should voice my own humble opinion - perhaps it can be useful, or maybe not... I would like to start by saying I fully agree with Shawn: what exactly are we trying to fix? That is not to say problems never happened, but these things have side effects - sometimes the most unintended ones. As C++ programmers, we should know well that unintended side-effects steaming from well-intentioned constructs are no exception (pun intended). So I will go back to my question: what is it we are trying to solve? Or rather, what is it that happened, that we are trying to prevent from happening again? There will always be lunatics, and a CoC won't stop them. Perhaps it will improve things... but... perhaps it will do more harm than good. Or is it proven technology? Which brings to my second point, a very personal one: more or less in line with what Jason said, programming *to me* has always been about bits and bytes, about the code, about computers, about being able to make things appear on the screen and to control the machine. Free Software has been about.... free software and that's it. I find it extremely off-putting to see that the Qt project is embarking in this sort of politics - again, if things were broken and a CoC could fix them, I would be more than happy to join the train, but that doesn't seem to be the case. At least from my humble perspective. During all these years contributing to Qt I have encountered many times strong criticism in gerrit - some people were very harsh or *seemingly* rude - or that was what I thought, until I realized that: 1) it was just their modus operandi; 2) at the end of the day, their comments made sense and improved my code; 3) they were not butt hurt when roles were reversed. Communication/criticism just like this is unambiguously straightforward and I *personally* prefer it this way. Unfortunately I could not make it to the QtCS, but had I been there, I would have voted against the CoC, for sure. I hate to see politics tainting the project. But, that is my view, and in spite of that, I do hope that in the end I am wrong and that the CoC is another step on the right direction. Let's remain positive and hope it won't even be necessary to invoke it after all, and that respect and common-sense shall prevail. - Rafael PS: if you have read this far (sorry!), you may also be interested in donating a tad more of your time and help with reviewing this https://codereview.qt-project.org/#/c/241598/ ;) On 10/25/18 5:58 PM, Lars Knoll wrote: >> On 25 Oct 2018, at 09:51, Volker Krause via Development >> > wrote: >> >> On Thursday, 25 October 2018 09:11:42 CEST Simon Hausmann wrote: >>> Am 25.10.18 um 08:31 schrieb Shawn Rutledge: >>> >>>> >>>> >>>>> On 24 Oct 2018, at 17:09, Jason H >>>> > wrote: >>>>> >>>>> >>>>> >>>>> In case it needs to be said- >>>>> I am AGAINST racism, sexism, bigotry, and all the other exclusionary >>>>> things. But I am also against people judging other people's code for >>>>> factors that have nothing to do with the code itself. I find that >>>>> adding >>>>> a value judgement of conduct to code to be intolerant. We had the >>>>> ideal. >> I am FOR inclusion. I want everyone to feel welcome here. >>>>> Everyone.>  >>>> I agree.  It seems to be about fixing something that isn’t broken, or as >>>> in that story in the Bible where the people came to a consensus that >>>> every other country around them had a king, so they should have a king >>>> too.  Nothing good came out of it in any cases where we have seen this >>>> kind of illogic applied.  “Most other big corporations have a deep >>>> hierarchy of management, with too much power concentrated at the >>>> top, and >>>> we want to be a big corporation, so we need to replicate that.”  “The >>>> other lemmings are running away so maybe we’d better follow.”  It’s not >>>> the open source way, which seemed to be working well enough already. >>> >>>> >>>> >>>> If you give power to a committee of 3 people, they will probably >>>> abuse it >>>> eventually, misjudge, cause bitterness, create factions, and some >>>> developers will end up walking away.  Seems predictable, doesn’t it? >>> >>>> >>> >>> >>> You claim that this is about fixing something that isn't broken. Your  >>> statement that a committee will predictably and eventually abuse their  >>> powers and misjudge is, I feel, a >>> >>> statement that is spreading fear, doubt and uncertainty, without any  >>> evidence within the scope of this community. >>> >>> >>> On the other hand I am aware of at least one concrete case where the  >>> behavior of a reviewer has caused a contributor (with a track record of  >>> accepted patches, btw) to >>> >>> turn away from the project and even resulted in an email of complaint  >>> sent to the community manager. The lack of tools, written understanding  >>> and common agreement >>> >>> on what is good behavior resulted in that nothing happened at all and  >>> the contributor in question has stayed away from the project since then. >>> >>> >>> I do think that this is the exception, but it is crucial that we have  >>> the right tools and mechanisms in place when unlikely exceptions happen,  >>> in order to deal with them >>> >>> instead of ignoring them. After having seen this with my own eyes, I am  >>> convinced of that. >>> >>> >>> Whether it is a code of conduct or kindness guidelines - anything like  >>> that is something that I welcome as an improvement. >>> >>> >>> Simon >> >> +1 >> >> We do have a Code of Conduct at KDE for about 10 years now, and this >> hasn't  >> led to abuse of power, suppression of free speech, racism against >> white people  >> or whatever other nonsense people seem to attribute to CoCs nowadays. >> >> On the contrary, it gave us a solid foundation to act against the >> (very few,  >> fortunately) cases of abusive behavior to protect our contributors. As >> Simon I  >> have seen the damage such behavior can do, and therefore would also >> welcome  >> tools/rules to be in place to deal with such situations. >> >> Regards, >> Volker > > I fully agree. > > And btw, we have had a clear majority in favour of adding a CoC at the > Contributor Summit, and explicitly agreed that a group of people will > work on creating it. I’m happy we now have a first version, that we can > use as a basis for further discussions. > > Cheers, > Lars > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From lorn.potter at gmail.com Thu Oct 25 12:00:58 2018 From: lorn.potter at gmail.com (Lorn Potter) Date: Thu, 25 Oct 2018 20:00:58 +1000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: <4449a09b-ce0b-f6a8-05bc-3299ddd5e542@gmail.com> On 25/10/18 9:19 am, Konstantin Shegunov wrote: > Addendum: There's too much vague phrasing. When I was reading through > the text I read things of the sort: > "Showing empathy towards other community members" > and > "Other conduct which could reasonably be considered inappropriate in a > professional setting" > and what I thought was "What's that nonsense?! empathy?!". What is wrong > with stating it directly - "Don't be mean, respect others."? Those do not mean the same as 'empathy', which is the "ability to understand and share the feelings of another", or "put yourself in the other persons shoes" I think empathy is a fine word for this, there is nothing vague about it. From enmarantispam at gmail.com Thu Oct 25 12:00:44 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Thu, 25 Oct 2018 13:00:44 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> Message-ID: > And btw, we have had a clear majority in favour of adding a CoC at the Contributor Summit It seems very wrong to make such decisions at conventions where only a small part of the contributors can participate. Especially for something as big and divisive On Thu, Oct 25, 2018 at 12:52 PM Rafael Roquetto wrote: > I understand this has already been set in stone, and I am not here in > the hopes this will change. However, I do feel like I should voice my > own humble opinion - perhaps it can be useful, or maybe not... > > I would like to start by saying I fully agree with Shawn: what exactly > are we trying to fix? That is not to say problems never happened, but > these things have side effects - sometimes the most unintended ones. As > C++ programmers, we should know well that unintended side-effects > steaming from well-intentioned constructs are no exception (pun intended). > > So I will go back to my question: what is it we are trying to solve? Or > rather, what is it that happened, that we are trying to prevent from > happening again? There will always be lunatics, and a CoC won't stop > them. Perhaps it will improve things... but... perhaps it will do more > harm than good. Or is it proven technology? > > Which brings to my second point, a very personal one: more or less in > line with what Jason said, programming *to me* has always been about > bits and bytes, about the code, about computers, about being able to > make things appear on the screen and to control the machine. Free > Software has been about.... free software and that's it. I find it > extremely off-putting to see that the Qt project is embarking in this > sort of politics - again, if things were broken and a CoC could fix > them, I would be more than happy to join the train, but that doesn't > seem to be the case. At least from my humble perspective. > > During all these years contributing to Qt I have encountered many times > strong criticism in gerrit - some people were very harsh or *seemingly* > rude - or that was what I thought, until I realized that: 1) it was just > their modus operandi; 2) at the end of the day, their comments made > sense and improved my code; 3) they were not butt hurt when roles were > reversed. > > Communication/criticism just like this is unambiguously straightforward > and I *personally* prefer it this way. Unfortunately I could not make it > to the QtCS, but had I been there, I would have voted against the CoC, > for sure. I hate to see politics tainting the project. But, that is my > view, and in spite of that, I do hope that in the end I am wrong and > that the CoC is another step on the right direction. Let's remain > positive and hope it won't even be necessary to invoke it after all, and > that respect and common-sense shall prevail. > > > - Rafael > > PS: if you have read this far (sorry!), you may also be interested in > donating a tad more of your time and help with reviewing this > > https://codereview.qt-project.org/#/c/241598/ > > ;) > > > On 10/25/18 5:58 PM, Lars Knoll wrote: > >> On 25 Oct 2018, at 09:51, Volker Krause via Development > >> > wrote: > >> > >> On Thursday, 25 October 2018 09:11:42 CEST Simon Hausmann wrote: > >>> Am 25.10.18 um 08:31 schrieb Shawn Rutledge: > >>> > >>>> > >>>> > >>>>> On 24 Oct 2018, at 17:09, Jason H >>>>> > wrote: > >>>>> > >>>>> > >>>>> > >>>>> In case it needs to be said- > >>>>> I am AGAINST racism, sexism, bigotry, and all the other exclusionary > >>>>> things. But I am also against people judging other people's code for > >>>>> factors that have nothing to do with the code itself. I find that > >>>>> adding > >>>>> a value judgement of conduct to code to be intolerant. We had the > >>>>> ideal. > >> I am FOR inclusion. I want everyone to feel welcome here. > >>>>> Everyone.> > >>>> I agree. It seems to be about fixing something that isn’t broken, or > as > >>>> in that story in the Bible where the people came to a consensus that > >>>> every other country around them had a king, so they should have a king > >>>> too. Nothing good came out of it in any cases where we have seen this > >>>> kind of illogic applied. “Most other big corporations have a deep > >>>> hierarchy of management, with too much power concentrated at the > >>>> top, and > >>>> we want to be a big corporation, so we need to replicate that.” “The > >>>> other lemmings are running away so maybe we’d better follow.” It’s > not > >>>> the open source way, which seemed to be working well enough already. > >>> > >>>> > >>>> > >>>> If you give power to a committee of 3 people, they will probably > >>>> abuse it > >>>> eventually, misjudge, cause bitterness, create factions, and some > >>>> developers will end up walking away. Seems predictable, doesn’t it? > >>> > >>>> > >>> > >>> > >>> You claim that this is about fixing something that isn't broken. Your > >>> statement that a committee will predictably and eventually abuse their > >>> powers and misjudge is, I feel, a > >>> > >>> statement that is spreading fear, doubt and uncertainty, without any > >>> evidence within the scope of this community. > >>> > >>> > >>> On the other hand I am aware of at least one concrete case where the > >>> behavior of a reviewer has caused a contributor (with a track record > of > >>> accepted patches, btw) to > >>> > >>> turn away from the project and even resulted in an email of complaint > >>> sent to the community manager. The lack of tools, written > understanding > >>> and common agreement > >>> > >>> on what is good behavior resulted in that nothing happened at all and > >>> the contributor in question has stayed away from the project since > then. > >>> > >>> > >>> I do think that this is the exception, but it is crucial that we have > >>> the right tools and mechanisms in place when unlikely exceptions > happen, > >>> in order to deal with them > >>> > >>> instead of ignoring them. After having seen this with my own eyes, I > am > >>> convinced of that. > >>> > >>> > >>> Whether it is a code of conduct or kindness guidelines - anything like > >>> that is something that I welcome as an improvement. > >>> > >>> > >>> Simon > >> > >> +1 > >> > >> We do have a Code of Conduct at KDE for about 10 years now, and this > >> hasn't > >> led to abuse of power, suppression of free speech, racism against > >> white people > >> or whatever other nonsense people seem to attribute to CoCs nowadays. > >> > >> On the contrary, it gave us a solid foundation to act against the > >> (very few, > >> fortunately) cases of abusive behavior to protect our contributors. As > >> Simon I > >> have seen the damage such behavior can do, and therefore would also > >> welcome > >> tools/rules to be in place to deal with such situations. > >> > >> Regards, > >> Volker > > > > I fully agree. > > > > And btw, we have had a clear majority in favour of adding a CoC at the > > Contributor Summit, and explicitly agreed that a group of people will > > work on creating it. I’m happy we now have a first version, that we can > > use as a basis for further discussions. > > > > Cheers, > > Lars > > > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Loehning at qt.io Thu Oct 25 12:05:04 2018 From: Robert.Loehning at qt.io (Robert Loehning) Date: Thu, 25 Oct 2018 10:05:04 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> Message-ID: Am 25.10.2018 um 09:58 schrieb Lars Knoll: > And btw, we have had a clear majority in favour of adding a CoC at the Contributor Summit, and explicitly agreed that a group of people will work on creating it. I’m happy we now have a first version, that we can use as a basis for further discussions. > Hi all, to be precise: We had a clear majority of the people who voted in this session. This might or might not correlate with a majority of the project's members. Cheers, Robert From annulen at yandex.ru Thu Oct 25 12:06:09 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 25 Oct 2018 13:06:09 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> Message-ID: <1230131540461969@iva5-750e13568e4d.qloud-c.yandex.net> 25.10.2018, 13:01, "NIkolai Marchenko" : >> And btw, we have had a clear majority in favour of adding a CoC at the Contributor Summit > > It seems very wrong to make such decisions at conventions where only a small part of the contributors can participate. > Especially for something as big and divisive +1 --  Regards, Konstantin From enmarantispam at gmail.com Thu Oct 25 12:13:24 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Thu, 25 Oct 2018 13:13:24 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <1230131540461969@iva5-750e13568e4d.qloud-c.yandex.net> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> <1230131540461969@iva5-750e13568e4d.qloud-c.yandex.net> Message-ID: I would also like to point out an extreme case: https://github.com/opal/opal/issues/941 Now, I am not saying the Code is going to transform into a shitstorm like this. But it's something to be aware of. Some clear boundaries must be set if Code is ever enforced. Also: a question needs to be answered: say, there's a contributor that does a lot. He's a rude ass, but he is a _productive_ rude ass and mostly everyone agrees that his contributions outweigh his particular quirk. What are you going to do under such a code of conduct? Remove his access to the project? This sounds ridiculous tbh. On Thu, Oct 25, 2018 at 1:06 PM Konstantin Tokarev wrote: > > > 25.10.2018, 13:01, "NIkolai Marchenko" : > >> And btw, we have had a clear majority in favour of adding a CoC at the > Contributor Summit > > > > It seems very wrong to make such decisions at conventions where only a > small part of the contributors can participate. > > Especially for something as big and divisive > > +1 > > -- > Regards, > Konstantin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.hilsheimer at qt.io Thu Oct 25 12:15:11 2018 From: volker.hilsheimer at qt.io (Volker Hilsheimer) Date: Thu, 25 Oct 2018 10:15:11 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> Message-ID: <61EE3F65-F30F-4163-9B63-43D5443FFEAB@qt.io> > On 25 Oct 2018, at 11:50, Rafael Roquetto wrote: > So I will go back to my question: what is it we are trying to solve? Or > rather, what is it that happened, that we are trying to prevent from > happening again? There will always be lunatics, and a CoC won't stop > them. Perhaps it will improve things... but... perhaps it will do more > harm than good. Or is it proven technology? Because not all of us have *observed* issues doesn’t mean that there have not been any issues. This community would not be the first from which people that feel assaulted or disrespected would rather quietly disappear than to raise the concern. > Which brings to my second point, a very personal one: more or less in > line with what Jason said, programming *to me* has always been about > bits and bytes, about the code, about computers, about being able to > make things appear on the screen and to control the machine. Free > Software has been about.... free software and that's it. I find it > extremely off-putting to see that the Qt project is embarking in this > sort of politics - again, if things were broken and a CoC could fix > them, I would be more than happy to join the train, but that doesn't > seem to be the case. At least from my humble perspective. Having clear communication about what we as a community care about, and what we don’t care about, creates clarity and sets expectations. What you are suggesting is a code of conduct, actually: “We only care about the quality of your code. You can behave in whichever way you want, and don’t have to fear that the community will sanction you for being yourself.” That’s a CoC, and if that’s the CoC we want, then we should write it down so that people know what to expect. > During all these years contributing to Qt I have encountered many times > strong criticism in gerrit - some people were very harsh or *seemingly* > rude - or that was what I thought, until I realized that: 1) it was just > their modus operandi; 2) at the end of the day, their comments made > sense and improved my code; 3) they were not butt hurt when roles were > reversed. So, programming for you has always only been about code, but you wrote a paragraph about how it is about people and their interactions anyway :) Especially in an Open Source project, coding is a social interaction, and not at all just about bits and bytes. You make pull requests that you want people to review and comment on. You have ideas that you want people to embrace and join. You write code that you want others to use. You want co-contributors that take ownership and responsibility when their changes happen to break your feature. Perhaps you even want to write software that is based on thorough insights into what people struggle with, This requires observing, communicating, and empathizing with your users, before you start hacking. > Communication/criticism just like this is unambiguously straightforward > and I *personally* prefer it this way. Unfortunately I could not make it > to the QtCS, but had I been there, I would have voted against the CoC, > for sure. I hate to see politics tainting the project. But, that is my > view, and in spite of that, I do hope that in the end I am wrong and > that the CoC is another step on the right direction. Let's remain > positive and hope it won't even be necessary to invoke it after all, and > that respect and common-sense shall prevail. Common sense is unfortunately not very common. Cheers, Volker > On 10/25/18 5:58 PM, Lars Knoll wrote: >>> On 25 Oct 2018, at 09:51, Volker Krause via Development >>> > wrote: >>> >>> On Thursday, 25 October 2018 09:11:42 CEST Simon Hausmann wrote: >>>> Am 25.10.18 um 08:31 schrieb Shawn Rutledge: >>>> >>>>> >>>>> >>>>>> On 24 Oct 2018, at 17:09, Jason H >>>>> > wrote: >>>>>> >>>>>> >>>>>> >>>>>> In case it needs to be said- >>>>>> I am AGAINST racism, sexism, bigotry, and all the other exclusionary >>>>>> things. But I am also against people judging other people's code for >>>>>> factors that have nothing to do with the code itself. I find that >>>>>> adding >>>>>> a value judgement of conduct to code to be intolerant. We had the >>>>>> ideal. >>> I am FOR inclusion. I want everyone to feel welcome here. >>>>>> Everyone.> >>>>> I agree. It seems to be about fixing something that isn’t broken, or as >>>>> in that story in the Bible where the people came to a consensus that >>>>> every other country around them had a king, so they should have a king >>>>> too. Nothing good came out of it in any cases where we have seen this >>>>> kind of illogic applied. “Most other big corporations have a deep >>>>> hierarchy of management, with too much power concentrated at the >>>>> top, and >>>>> we want to be a big corporation, so we need to replicate that.” “The >>>>> other lemmings are running away so maybe we’d better follow.” It’s not >>>>> the open source way, which seemed to be working well enough already. >>>> >>>>> >>>>> >>>>> If you give power to a committee of 3 people, they will probably >>>>> abuse it >>>>> eventually, misjudge, cause bitterness, create factions, and some >>>>> developers will end up walking away. Seems predictable, doesn’t it? >>>> >>>>> >>>> >>>> >>>> You claim that this is about fixing something that isn't broken. Your >>>> statement that a committee will predictably and eventually abuse their >>>> powers and misjudge is, I feel, a >>>> >>>> statement that is spreading fear, doubt and uncertainty, without any >>>> evidence within the scope of this community. >>>> >>>> >>>> On the other hand I am aware of at least one concrete case where the >>>> behavior of a reviewer has caused a contributor (with a track record of >>>> accepted patches, btw) to >>>> >>>> turn away from the project and even resulted in an email of complaint >>>> sent to the community manager. The lack of tools, written understanding >>>> and common agreement >>>> >>>> on what is good behavior resulted in that nothing happened at all and >>>> the contributor in question has stayed away from the project since then. >>>> >>>> >>>> I do think that this is the exception, but it is crucial that we have >>>> the right tools and mechanisms in place when unlikely exceptions happen, >>>> in order to deal with them >>>> >>>> instead of ignoring them. After having seen this with my own eyes, I am >>>> convinced of that. >>>> >>>> >>>> Whether it is a code of conduct or kindness guidelines - anything like >>>> that is something that I welcome as an improvement. >>>> >>>> >>>> Simon >>> >>> +1 >>> >>> We do have a Code of Conduct at KDE for about 10 years now, and this >>> hasn't >>> led to abuse of power, suppression of free speech, racism against >>> white people >>> or whatever other nonsense people seem to attribute to CoCs nowadays. >>> >>> On the contrary, it gave us a solid foundation to act against the >>> (very few, >>> fortunately) cases of abusive behavior to protect our contributors. As >>> Simon I >>> have seen the damage such behavior can do, and therefore would also >>> welcome >>> tools/rules to be in place to deal with such situations. >>> >>> Regards, >>> Volker >> >> I fully agree. >> >> And btw, we have had a clear majority in favour of adding a CoC at the >> Contributor Summit, and explicitly agreed that a group of people will >> work on creating it. I’m happy we now have a first version, that we can >> use as a basis for further discussions. >> >> Cheers, >> Lars >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Martin.Smith at qt.io Thu Oct 25 12:26:21 2018 From: Martin.Smith at qt.io (Martin Smith) Date: Thu, 25 Oct 2018 10:26:21 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com>, Message-ID: >It seems very wrong to make such decisions at conventions where only a small part of the contributors can participate. >Especially for something as big and divisive It isn't wrong if the adoption process allows everyone to vote on whether to adopt the eventual CoC. What seems wrong is to continue arguing about whether we should develop a CoC after the decision to develop a CoC has been taken. Let's focus on developing an acceptable CoC. You can't seriously claim no CoC can ever be acceptable. But maybe we won't arrive at an acceptable one. We won't know until we spend some time trying. Other groups seems to have succeeded. martin ________________________________________ From: Development on behalf of NIkolai Marchenko Sent: Thursday, October 25, 2018 12:00:44 PM To: rafael at roquetto.com Cc: Qt development mailing list Subject: Re: [Development] QUIP 12: Code of Conduct > And btw, we have had a clear majority in favour of adding a CoC at the Contributor Summit It seems very wrong to make such decisions at conventions where only a small part of the contributors can participate. Especially for something as big and divisive On Thu, Oct 25, 2018 at 12:52 PM Rafael Roquetto > wrote: I understand this has already been set in stone, and I am not here in the hopes this will change. However, I do feel like I should voice my own humble opinion - perhaps it can be useful, or maybe not... I would like to start by saying I fully agree with Shawn: what exactly are we trying to fix? That is not to say problems never happened, but these things have side effects - sometimes the most unintended ones. As C++ programmers, we should know well that unintended side-effects steaming from well-intentioned constructs are no exception (pun intended). So I will go back to my question: what is it we are trying to solve? Or rather, what is it that happened, that we are trying to prevent from happening again? There will always be lunatics, and a CoC won't stop them. Perhaps it will improve things... but... perhaps it will do more harm than good. Or is it proven technology? Which brings to my second point, a very personal one: more or less in line with what Jason said, programming *to me* has always been about bits and bytes, about the code, about computers, about being able to make things appear on the screen and to control the machine. Free Software has been about.... free software and that's it. I find it extremely off-putting to see that the Qt project is embarking in this sort of politics - again, if things were broken and a CoC could fix them, I would be more than happy to join the train, but that doesn't seem to be the case. At least from my humble perspective. During all these years contributing to Qt I have encountered many times strong criticism in gerrit - some people were very harsh or *seemingly* rude - or that was what I thought, until I realized that: 1) it was just their modus operandi; 2) at the end of the day, their comments made sense and improved my code; 3) they were not butt hurt when roles were reversed. Communication/criticism just like this is unambiguously straightforward and I *personally* prefer it this way. Unfortunately I could not make it to the QtCS, but had I been there, I would have voted against the CoC, for sure. I hate to see politics tainting the project. But, that is my view, and in spite of that, I do hope that in the end I am wrong and that the CoC is another step on the right direction. Let's remain positive and hope it won't even be necessary to invoke it after all, and that respect and common-sense shall prevail. - Rafael PS: if you have read this far (sorry!), you may also be interested in donating a tad more of your time and help with reviewing this https://codereview.qt-project.org/#/c/241598/ ;) On 10/25/18 5:58 PM, Lars Knoll wrote: >> On 25 Oct 2018, at 09:51, Volker Krause via Development >> >> wrote: >> >> On Thursday, 25 October 2018 09:11:42 CEST Simon Hausmann wrote: >>> Am 25.10.18 um 08:31 schrieb Shawn Rutledge: >>> >>>> >>>> >>>>> On 24 Oct 2018, at 17:09, Jason H >>>>> >> wrote: >>>>> >>>>> >>>>> >>>>> In case it needs to be said- >>>>> I am AGAINST racism, sexism, bigotry, and all the other exclusionary >>>>> things. But I am also against people judging other people's code for >>>>> factors that have nothing to do with the code itself. I find that >>>>> adding >>>>> a value judgement of conduct to code to be intolerant. We had the >>>>> ideal. >> I am FOR inclusion. I want everyone to feel welcome here. >>>>> Everyone.> >>>> I agree. It seems to be about fixing something that isn’t broken, or as >>>> in that story in the Bible where the people came to a consensus that >>>> every other country around them had a king, so they should have a king >>>> too. Nothing good came out of it in any cases where we have seen this >>>> kind of illogic applied. “Most other big corporations have a deep >>>> hierarchy of management, with too much power concentrated at the >>>> top, and >>>> we want to be a big corporation, so we need to replicate that.” “The >>>> other lemmings are running away so maybe we’d better follow.” It’s not >>>> the open source way, which seemed to be working well enough already. >>> >>>> >>>> >>>> If you give power to a committee of 3 people, they will probably >>>> abuse it >>>> eventually, misjudge, cause bitterness, create factions, and some >>>> developers will end up walking away. Seems predictable, doesn’t it? >>> >>>> >>> >>> >>> You claim that this is about fixing something that isn't broken. Your >>> statement that a committee will predictably and eventually abuse their >>> powers and misjudge is, I feel, a >>> >>> statement that is spreading fear, doubt and uncertainty, without any >>> evidence within the scope of this community. >>> >>> >>> On the other hand I am aware of at least one concrete case where the >>> behavior of a reviewer has caused a contributor (with a track record of >>> accepted patches, btw) to >>> >>> turn away from the project and even resulted in an email of complaint >>> sent to the community manager. The lack of tools, written understanding >>> and common agreement >>> >>> on what is good behavior resulted in that nothing happened at all and >>> the contributor in question has stayed away from the project since then. >>> >>> >>> I do think that this is the exception, but it is crucial that we have >>> the right tools and mechanisms in place when unlikely exceptions happen, >>> in order to deal with them >>> >>> instead of ignoring them. After having seen this with my own eyes, I am >>> convinced of that. >>> >>> >>> Whether it is a code of conduct or kindness guidelines - anything like >>> that is something that I welcome as an improvement. >>> >>> >>> Simon >> >> +1 >> >> We do have a Code of Conduct at KDE for about 10 years now, and this >> hasn't >> led to abuse of power, suppression of free speech, racism against >> white people >> or whatever other nonsense people seem to attribute to CoCs nowadays. >> >> On the contrary, it gave us a solid foundation to act against the >> (very few, >> fortunately) cases of abusive behavior to protect our contributors. As >> Simon I >> have seen the damage such behavior can do, and therefore would also >> welcome >> tools/rules to be in place to deal with such situations. >> >> Regards, >> Volker > > I fully agree. > > And btw, we have had a clear majority in favour of adding a CoC at the > Contributor Summit, and explicitly agreed that a group of people will > work on creating it. I’m happy we now have a first version, that we can > use as a basis for further discussions. > > Cheers, > Lars > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From robin.burchell at crimson.no Thu Oct 25 12:30:00 2018 From: robin.burchell at crimson.no (Robin Burchell) Date: Thu, 25 Oct 2018 12:30:00 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> Message-ID: <1540463400.3511833.1554104192.1ED8C416@webmail.messagingengine.com> On Thu, Oct 25, 2018, at 11:50 AM, Rafael Roquetto wrote: > So I will go back to my question: what is it we are trying to solve? Or > rather, what is it that happened, that we are trying to prevent from > happening again? There will always be lunatics, and a CoC won't stop > them. Perhaps it will improve things... but... perhaps it will do more > harm than good. Or is it proven technology? The problem with that question is that by the time you need to _solve_ something, or prevent it from happening _again_, it has already happened. The point of a code of conduct as I understand it is that it is supposed to help prevent situations from arising/escalating out of control in the first place, and if that ever does happen, provide a process to resolve it in a well defined (and ideally, minimally damaging) way. [ As an aside, I've seen communities go very bad - with or without a code of conduct - so the "code" alone won't save you- at the end of the day, it's all down to you, me, and everyone here to do the right thing and make this place a good one. ] > Which brings to my second point, a very personal one: more or less in > line with what Jason said, programming *to me* has always been about > bits and bytes, about the code, about computers, about being able to > make things appear on the screen and to control the machine. Free > Software has been about.... free software and that's it. I find it > extremely off-putting to see that the Qt project is embarking in this > sort of politics - again, if things were broken and a CoC could fix > them, I would be more than happy to join the train, but that doesn't > seem to be the case. At least from my humble perspective. I will first acknowledge that I am in a privileged position - I've never been on the bad end of any sort of discrimination - and for those that have been, or worse, are systematically in that position, it is much harder for them to effect any real change to that without the clear capability to show that this sort of thing is not OK. With that having been said: my own personal stance is that I would _like_ it to be possible for this stuff to not be needed. I would _like_ people to be smart enough to understand that they should do, or not do, certain things in order to cooperate and "get on". But everyone is different, after all, and a common sense of "correct" is not necessarily as common as we might think, or hope. So while I don't personally find it necessary, I do try put myself in the shoes of someone less "fortunate" than myself while considering it. What do you do if you are certain that your contributions are being ignored not because of technical merits, but because of [ your own ] personal characteristics? Without a clear guideline of how that sort of a situation is approached, the only real answer is, simply, "you stop contributing". Which is a losing proposition: the community loses a potentially valuable contributor, at the cost of a toxic environment that is not at all based around technical merit - the exact opposite of what we want to happen, I'd say. > Communication/criticism just like this is unambiguously straightforward > and I *personally* prefer it this way. Unfortunately I could not make it > to the QtCS, but had I been there, I would have voted against the CoC, > for sure. I hate to see politics tainting the project. I tried to spell this out, but I think it needs repeating. In my view, a code of conduct is not a political tool, nor a legal document (if it is done well). It is a codified form of what is acceptable to the project, which at the purest form might be: contributions good from all comers of all types, and if bad things happen, here's how they are resolved. -- Robin Burchell robin at crimson.no From Simon.Hausmann at qt.io Thu Oct 25 12:33:45 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 25 Oct 2018 10:33:45 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> Message-ID: <2d78d258-1e6c-79b1-62e8-43a85332d659@qt.io> Am 25.10.18 um 11:50 schrieb Rafael Roquetto: > I understand this has already been set in stone, and I am not here in > the hopes this will change. However, I do feel like I should voice my > own humble opinion - perhaps it can be useful, or maybe not... Your feedback is most certainly useful. (at least in my humble opinion ;-) > I would like to start by saying I fully agree with Shawn: what exactly > are we trying to fix? That is not to say problems never happened, but > these things have side effects - sometimes the most unintended ones. As > C++ programmers, we should know well that unintended side-effects > steaming from well-intentioned constructs are no exception (pun intended). You're right, there can be side-effects. We have to be careful about those, as much as we have to be careful to address the situation of uncaught exceptions. Those terminating the process of contribution and potentially causing further side-effects is what this is trying to "fix" or at least attempt to improve. I think the best way to minimize the side effects you may be concerned about is to ensure that the wording emphasizes the desire for a positive environment (for the purpose of reasoning) and also frames the part of handling violations as a last resort, as something that should be the exception. If, on the other hand, a CoC is not used as a last resort but at the beginning of every slight misunderstanding, then we would perhaps have failed. This is where input from other projects that have had a CoC, such as KDE, is beneficial in assessing the risks. > So I will go back to my question: what is it we are trying to solve? Or > rather, what is it that happened, that we are trying to prevent from > happening again? There will always be lunatics, and a CoC won't stop > them. Perhaps it will improve things... but... perhaps it will do more > harm than good. Or is it proven technology? As I also said in my earlier email, I'm aware of at least one case where terrible behavior resulted in a contributor with track record of patches being turned away and no consequence for the person responsible for it. That is unjust and I think doing _something_ about it is better than us - the community - keeping quiet and sweeping these exceptions under the carpet. The sweeping under the carpet, _that_ is what we must prevent from happening again. What are your thoughts about that? > > Which brings to my second point, a very personal one: more or less in > line with what Jason said, programming *to me* has always been about > bits and bytes, about the code, about computers, about being able to > make things appear on the screen and to control the machine. Free > Software has been about.... free software and that's it. I find it > extremely off-putting to see that the Qt project is embarking in this > sort of politics - again, if things were broken and a CoC could fix > them, I would be more than happy to join the train, but that doesn't > seem to be the case. At least from my humble perspective. I think it should be like that, at the heart of it. On the other hand much has happened in the world since the early days of free software projects. A much larger part of the population on the planet has access to the internet and education that makes it possible for them to join our community. I think that is a fantastic opportunity. It means that people different backgrounds, different cultures and different upbrinings are able to join. We must assume good faith, but we should be prepared to be able to explain what we would perhaps consider "common sense" in terms of behavior. A well worded document may be of tremendous help. This is one aspect I really like about the GNU Kind Communications Guidelines as an alternative. It's _something_ more than what we have today. > During all these years contributing to Qt I have encountered many times > strong criticism in gerrit - some people were very harsh or *seemingly* > rude - or that was what I thought, until I realized that: 1) it was just > their modus operandi; 2) at the end of the day, their comments made > sense and improved my code; 3) they were not butt hurt when roles were > reversed. > > Communication/criticism just like this is unambiguously straightforward > and I *personally* prefer it this way. Unfortunately I could not make it > to the QtCS, but had I been there, I would have voted against the CoC, > for sure. I hate to see politics tainting the project. But, that is my > view, and in spite of that, I do hope that in the end I am wrong and > that the CoC is another step on the right direction. Let's remain > positive and hope it won't even be necessary to invoke it after all, and > that respect and common-sense shall prevail. > Calm and well formulated emails like yours help big time to maintain a positive attitude in this discussion and increase chances of a good result for the project - thank you :) Simon > - Rafael > > PS: if you have read this far (sorry!), you may also be interested in > donating a tad more of your time and help with reviewing this > > https://codereview.qt-project.org/#/c/241598/ > > ;) > > > On 10/25/18 5:58 PM, Lars Knoll wrote: >>> On 25 Oct 2018, at 09:51, Volker Krause via Development >>> > wrote: >>> >>> On Thursday, 25 October 2018 09:11:42 CEST Simon Hausmann wrote: >>>> Am 25.10.18 um 08:31 schrieb Shawn Rutledge: >>>> >>>>> >>>>>> On 24 Oct 2018, at 17:09, Jason H >>>>> > wrote: >>>>>> >>>>>> >>>>>> >>>>>> In case it needs to be said- >>>>>> I am AGAINST racism, sexism, bigotry, and all the other exclusionary >>>>>> things. But I am also against people judging other people's code for >>>>>> factors that have nothing to do with the code itself. I find that >>>>>> adding >>>>>> a value judgement of conduct to code to be intolerant. We had the >>>>>> ideal. >>> I am FOR inclusion. I want everyone to feel welcome here. >>>>>> Everyone.> >>>>> I agree.  It seems to be about fixing something that isn’t broken, or as >>>>> in that story in the Bible where the people came to a consensus that >>>>> every other country around them had a king, so they should have a king >>>>> too.  Nothing good came out of it in any cases where we have seen this >>>>> kind of illogic applied.  “Most other big corporations have a deep >>>>> hierarchy of management, with too much power concentrated at the >>>>> top, and >>>>> we want to be a big corporation, so we need to replicate that.”  “The >>>>> other lemmings are running away so maybe we’d better follow.”  It’s not >>>>> the open source way, which seemed to be working well enough already. >>>>> >>>>> If you give power to a committee of 3 people, they will probably >>>>> abuse it >>>>> eventually, misjudge, cause bitterness, create factions, and some >>>>> developers will end up walking away.  Seems predictable, doesn’t it? >>>> >>>> You claim that this is about fixing something that isn't broken. Your >>>> statement that a committee will predictably and eventually abuse their >>>> powers and misjudge is, I feel, a >>>> >>>> statement that is spreading fear, doubt and uncertainty, without any >>>> evidence within the scope of this community. >>>> >>>> >>>> On the other hand I am aware of at least one concrete case where the >>>> behavior of a reviewer has caused a contributor (with a track record of >>>> accepted patches, btw) to >>>> >>>> turn away from the project and even resulted in an email of complaint >>>> sent to the community manager. The lack of tools, written understanding >>>> and common agreement >>>> >>>> on what is good behavior resulted in that nothing happened at all and >>>> the contributor in question has stayed away from the project since then. >>>> >>>> >>>> I do think that this is the exception, but it is crucial that we have >>>> the right tools and mechanisms in place when unlikely exceptions happen, >>>> in order to deal with them >>>> >>>> instead of ignoring them. After having seen this with my own eyes, I am >>>> convinced of that. >>>> >>>> >>>> Whether it is a code of conduct or kindness guidelines - anything like >>>> that is something that I welcome as an improvement. >>>> >>>> >>>> Simon >>> +1 >>> >>> We do have a Code of Conduct at KDE for about 10 years now, and this >>> hasn't >>> led to abuse of power, suppression of free speech, racism against >>> white people >>> or whatever other nonsense people seem to attribute to CoCs nowadays. >>> >>> On the contrary, it gave us a solid foundation to act against the >>> (very few, >>> fortunately) cases of abusive behavior to protect our contributors. As >>> Simon I >>> have seen the damage such behavior can do, and therefore would also >>> welcome >>> tools/rules to be in place to deal with such situations. >>> >>> Regards, >>> Volker >> I fully agree. >> >> And btw, we have had a clear majority in favour of adding a CoC at the >> Contributor Summit, and explicitly agreed that a group of people will >> work on creating it. I’m happy we now have a first version, that we can >> use as a basis for further discussions. >> >> Cheers, >> Lars >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From enmarantispam at gmail.com Thu Oct 25 13:15:36 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Thu, 25 Oct 2018 14:15:36 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2d78d258-1e6c-79b1-62e8-43a85332d659@qt.io> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> <2d78d258-1e6c-79b1-62e8-43a85332d659@qt.io> Message-ID: > This community would not be the first from which people that feel assaulted or disrespected would rather quietly disappear than to raise the concern. Innocent until proved guilty. This statement is hearsay in the context of this particular project, whereas there were already accounts of people saying a certain amount of "rudeness" never was a problem for them. I could also try to argue the case that thesame amount of ppl will leave quitely because their style of communication is explicitly prohibited by the code and they don't want to change it. On Thu, Oct 25, 2018 at 1:33 PM Simon Hausmann wrote: > > Am 25.10.18 um 11:50 schrieb Rafael Roquetto: > > I understand this has already been set in stone, and I am not here in > > the hopes this will change. However, I do feel like I should voice my > > own humble opinion - perhaps it can be useful, or maybe not... > > > Your feedback is most certainly useful. (at least in my humble opinion ;-) > > > > I would like to start by saying I fully agree with Shawn: what exactly > > are we trying to fix? That is not to say problems never happened, but > > these things have side effects - sometimes the most unintended ones. As > > C++ programmers, we should know well that unintended side-effects > > steaming from well-intentioned constructs are no exception (pun > intended). > > > You're right, there can be side-effects. We have to be careful about those, > > as much as we have to be careful to address the situation of uncaught > > exceptions. Those terminating the process of contribution and potentially > > causing further side-effects is what this is trying to "fix" or at least > attempt > > to improve. > > > I think the best way to minimize the side effects you may be concerned > about > > is to ensure that the wording emphasizes the desire for a positive > environment > > (for the purpose of reasoning) and also frames the part of handling > violations > > as a last resort, as something that should be the exception. > > > If, on the other hand, a CoC is not used as a last resort but at the > beginning of > > every slight misunderstanding, then we would perhaps have failed. > > > This is where input from other projects that have had a CoC, such as KDE, > is > > beneficial in assessing the risks. > > > > So I will go back to my question: what is it we are trying to solve? Or > > rather, what is it that happened, that we are trying to prevent from > > happening again? There will always be lunatics, and a CoC won't stop > > them. Perhaps it will improve things... but... perhaps it will do more > > harm than good. Or is it proven technology? > > > As I also said in my earlier email, I'm aware of at least one case > > where terrible behavior resulted in a contributor with track record > > of patches being turned away and no consequence for the person > > responsible for it. That is unjust and I think doing _something_ about it > > is better than us - the community - keeping quiet and sweeping these > > exceptions under the carpet. The sweeping under the carpet, _that_ is > > what we must prevent from happening again. > > > What are your thoughts about that? > > > > > > Which brings to my second point, a very personal one: more or less in > > line with what Jason said, programming *to me* has always been about > > bits and bytes, about the code, about computers, about being able to > > make things appear on the screen and to control the machine. Free > > Software has been about.... free software and that's it. I find it > > extremely off-putting to see that the Qt project is embarking in this > > sort of politics - again, if things were broken and a CoC could fix > > them, I would be more than happy to join the train, but that doesn't > > seem to be the case. At least from my humble perspective. > > > I think it should be like that, at the heart of it. > > > On the other hand much has happened in the world since the early > > days of free software projects. A much larger part of the population > > on the planet has access to the internet and education that makes it > > possible for them to join our community. I think that is a fantastic > > opportunity. It means that people different backgrounds, different cultures > > and different upbrinings are able to join. We must assume good faith, > > but we should be prepared to be able to explain what we would perhaps > > consider "common sense" in terms of behavior. A well worded document > > may be of tremendous help. > > > This is one aspect I really like about the GNU Kind Communications > Guidelines > > as an alternative. It's _something_ more than what we have today. > > > > During all these years contributing to Qt I have encountered many times > > strong criticism in gerrit - some people were very harsh or *seemingly* > > rude - or that was what I thought, until I realized that: 1) it was just > > their modus operandi; 2) at the end of the day, their comments made > > sense and improved my code; 3) they were not butt hurt when roles were > > reversed. > > > > Communication/criticism just like this is unambiguously straightforward > > and I *personally* prefer it this way. Unfortunately I could not make it > > to the QtCS, but had I been there, I would have voted against the CoC, > > for sure. I hate to see politics tainting the project. But, that is my > > view, and in spite of that, I do hope that in the end I am wrong and > > that the CoC is another step on the right direction. Let's remain > > positive and hope it won't even be necessary to invoke it after all, and > > that respect and common-sense shall prevail. > > > > Calm and well formulated emails like yours help big time to maintain > > a positive attitude in this discussion and increase chances of a good > > result for the project - thank you :) > > > > Simon > > > > - Rafael > > > > PS: if you have read this far (sorry!), you may also be interested in > > donating a tad more of your time and help with reviewing this > > > > https://codereview.qt-project.org/#/c/241598/ > > > > ;) > > > > > > On 10/25/18 5:58 PM, Lars Knoll wrote: > >>> On 25 Oct 2018, at 09:51, Volker Krause via Development > >>> > > wrote: > >>> > >>> On Thursday, 25 October 2018 09:11:42 CEST Simon Hausmann wrote: > >>>> Am 25.10.18 um 08:31 schrieb Shawn Rutledge: > >>>> > >>>>> > >>>>>> On 24 Oct 2018, at 17:09, Jason H >>>>>> > wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> In case it needs to be said- > >>>>>> I am AGAINST racism, sexism, bigotry, and all the other exclusionary > >>>>>> things. But I am also against people judging other people's code for > >>>>>> factors that have nothing to do with the code itself. I find that > >>>>>> adding > >>>>>> a value judgement of conduct to code to be intolerant. We had the > >>>>>> ideal. > >>> I am FOR inclusion. I want everyone to feel welcome here. > >>>>>> Everyone.> > >>>>> I agree. It seems to be about fixing something that isn’t broken, > or as > >>>>> in that story in the Bible where the people came to a consensus that > >>>>> every other country around them had a king, so they should have a > king > >>>>> too. Nothing good came out of it in any cases where we have seen > this > >>>>> kind of illogic applied. “Most other big corporations have a deep > >>>>> hierarchy of management, with too much power concentrated at the > >>>>> top, and > >>>>> we want to be a big corporation, so we need to replicate that.” “The > >>>>> other lemmings are running away so maybe we’d better follow.” It’s > not > >>>>> the open source way, which seemed to be working well enough already. > >>>>> > >>>>> If you give power to a committee of 3 people, they will probably > >>>>> abuse it > >>>>> eventually, misjudge, cause bitterness, create factions, and some > >>>>> developers will end up walking away. Seems predictable, doesn’t it? > >>>> > >>>> You claim that this is about fixing something that isn't broken. Your > >>>> statement that a committee will predictably and eventually abuse their > >>>> powers and misjudge is, I feel, a > >>>> > >>>> statement that is spreading fear, doubt and uncertainty, without any > >>>> evidence within the scope of this community. > >>>> > >>>> > >>>> On the other hand I am aware of at least one concrete case where the > >>>> behavior of a reviewer has caused a contributor (with a track record > of > >>>> accepted patches, btw) to > >>>> > >>>> turn away from the project and even resulted in an email of complaint > >>>> sent to the community manager. The lack of tools, written > understanding > >>>> and common agreement > >>>> > >>>> on what is good behavior resulted in that nothing happened at all and > >>>> the contributor in question has stayed away from the project since > then. > >>>> > >>>> > >>>> I do think that this is the exception, but it is crucial that we have > >>>> the right tools and mechanisms in place when unlikely exceptions > happen, > >>>> in order to deal with them > >>>> > >>>> instead of ignoring them. After having seen this with my own eyes, I > am > >>>> convinced of that. > >>>> > >>>> > >>>> Whether it is a code of conduct or kindness guidelines - anything like > >>>> that is something that I welcome as an improvement. > >>>> > >>>> > >>>> Simon > >>> +1 > >>> > >>> We do have a Code of Conduct at KDE for about 10 years now, and this > >>> hasn't > >>> led to abuse of power, suppression of free speech, racism against > >>> white people > >>> or whatever other nonsense people seem to attribute to CoCs nowadays. > >>> > >>> On the contrary, it gave us a solid foundation to act against the > >>> (very few, > >>> fortunately) cases of abusive behavior to protect our contributors. As > >>> Simon I > >>> have seen the damage such behavior can do, and therefore would also > >>> welcome > >>> tools/rules to be in place to deal with such situations. > >>> > >>> Regards, > >>> Volker > >> I fully agree. > >> > >> And btw, we have had a clear majority in favour of adding a CoC at the > >> Contributor Summit, and explicitly agreed that a group of people will > >> work on creating it. I’m happy we now have a first version, that we can > >> use as a basis for further discussions. > >> > >> Cheers, > >> Lars > >> > >> > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > >> > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch.curtis at qt.io Thu Oct 25 13:22:28 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Thu, 25 Oct 2018 11:22:28 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> <1230131540461969@iva5-750e13568e4d.qloud-c.yandex.net> Message-ID: > -----Original Message----- > From: Development project.org> On Behalf Of NIkolai Marchenko > Sent: Thursday, 25 October 2018 12:13 PM > To: Konstantin Tokarev > Cc: Qt development mailing list > Subject: Re: [Development] QUIP 12: Code of Conduct > > I would also like to point out an extreme case: > https://github.com/opal/opal/issues/941 > Now, I am not saying the Code is going to transform into a shitstorm like this. > But it's something to be aware of. > Some clear boundaries must be set if Code is ever enforced. > > > Also: a question needs to be answered: say, there's a contributor that does a > lot. > He's a rude ass, but he is a _productive_ rude ass and mostly everyone > agrees that his contributions outweigh his particular quirk. > What are you going to do under such a code of conduct? Remove his access > to the project? This sounds ridiculous tbh. It's a bit of a loaded question. First you call asocial behaviour a "quirk", as if someone who treats other people like crap is "quirky" - I prefer your phrase "rude arse". Should a code of conduct aim to stop "quirky" behaviour amongst contributors? No, of course not. That's what makes people interesting. A code of conduct should draw the line between quirky behaviour and "rude arse" behaviour. To answer your question: in my experience, nothing happens. They continue being a rude arse because: 1) That is who they are and they aren't interested in changing. 2) People have already decided that this person's technical contributions are worth enough that they can step on anyone, regardless of the fact that it's supposed to be a professional setting. 3) They're "actually a nice person in real life"... as if this excuses it. So if I write "You're a dumbarse" on a piece of paper and send it through the post, but a week later invite you over to my house for a home-cooked meal, it's OK? Are we really encouraging keyboard warriors? Rafael said: "During all these years contributing to Qt I have encountered many times strong criticism in gerrit - some people were very harsh or *seemingly* rude - or that was what I thought, until I realized that: 1) it was just their modus operandi; 2) at the end of the day, their comments made sense and improved my code; 3) they were not butt hurt when roles were reversed." To me it seems like you guys are saying: "I don't care if this person treats me like crap because they sure can code." I'm happy for you if you've gotten this far in life and decided that you like being insulted in exchange for someone reviewing your code (or even just asking a question on IRC), but personally I do not like it. I'm more than capable of standing up for myself, but other people who feel the same way may not feel comfortable speaking out. What you're also saying is: "You (the Qt Project) aren't going to do anything about their behaviour because they contribute good code." Which sadly is true. Really, your question seems almost rhetorical given this. It's even explicitly acknowledged on the home page of the thing that we're basing our code of conduct on: "People with “merit” are often excused for their bad behavior in public spaces based on the value of their technical contributions." - https://www.contributor-covenant.org/ Disregarding all of the other factors (racism, sexual identity, age, etc.) and just keeping it purely about treating other people with respect: the statement above is absolutely true. Honestly I have my doubts whether this code of conduct will actually achieve its most basic goal, given that many people have apparently tried to intervene with the people who treat others poorly and nothing has come of it (although people will tell you it's gotten better). I hope it does, but I've been in the community and around these people long enough to know that it probably won't. Reading through these replies, it's also clear that a large amount of the people responding are quite happy with the status quo, which, although not surprising to me, is always disheartening. I haven't seen any racism, discrimination, etc., but there are definitely people within the community whose behaviour is such that other developers will avoid interacting with them, even if it would have likely improved the quality of their work or got that work done faster. I doubt you'll hear from those people though, because they just want to get their job done -- which is perfectly understandable, but does not excuse the behaviour of the people they try to avoid. > On Thu, Oct 25, 2018 at 1:06 PM Konstantin Tokarev > wrote: > > > > > 25.10.2018, 13:01, "NIkolai Marchenko" >: > >> And btw, we have had a clear majority in favour of adding a CoC at > the Contributor Summit > > > > It seems very wrong to make such decisions at conventions where > only a small part of the contributors can participate. > > Especially for something as big and divisive > > +1 > > -- > Regards, > Konstantin > From yetanotherandreyev at gmail.com Thu Oct 25 13:28:07 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Thu, 25 Oct 2018 14:28:07 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> Message-ID: Hello! Young Qt fanboy, who worried about the future of the project: What problems are CoC trying to solve? Abusive behaviour? People are not social angels at all. But how many situations of problematic behaviour at the Qt project do we have with current terms? When it's ruined some tasks we still could not solve? Could it be compared to the successful situations? Is the relative number a zero, one-two, ten, hundred? Is the value grows, fixed or decreases somehow? Are there some internal and external reasons? Are CoC helping for other similar projects? Is there any research? I agree we should have defined common values as a community. And I want to contribute too. I guess we should think twice at least about new fancy CoC. I'm happy that nobody is forcing hard it for now. I like the discussion at codereview. >From my point of view, some rude words could be filtered automatically or semi-automatically if we want to and it's not a huge problem. So let's skip all the cases when it's just about swearing for now. Let's focus on situations, when conflict is about the meaning of the sentences. It's the case about ideology (a system of ideas and ideals, something opposite to science in some terms, but something completing it to form a community). From my point of view, our speech probably could not be ideology-free. And it's not some bad thing we should get rid of, ideology instead should help community to develop and survive as a single whole. Some "let's be free from well-defined ideology" is just yet another ideology. So about ideology point CoC is trying to provide: I could see it for now as "let's forbid "non-constructive" negative feedback and everyone will be happy" (feel free to correct me). My problem with that is that focusing on "negative feedback" as absolute evil ("non-constructive" is practically not the key, because it's not well defined). I guess we could all agree that some "sweet" feedback could ruin the community as easy as "direct offensive" feedback, if not faster. So do we really want to somehow restrict negative side of feedback without limiting positive? Is it practically possible to do it for the health of the community? Feel free to criticize me or skip a message if it's inappropriate. And thank you for your time! Sorry for a spelling, I'm not a native speaker. 2018-10-25 10:58 GMT+03:00, Lars Knoll : > On 25 Oct 2018, at 09:51, Volker Krause via Development > > wrote: > > On Thursday, 25 October 2018 09:11:42 CEST Simon Hausmann wrote: > Am 25.10.18 um 08:31 schrieb Shawn Rutledge: > > > > On 24 Oct 2018, at 17:09, Jason H > > wrote: > > > > In case it needs to be said- > I am AGAINST racism, sexism, bigotry, and all the other exclusionary > things. But I am also against people judging other people's code for > factors that have nothing to do with the code itself. I find that adding > a value judgement of conduct to code to be intolerant. We had the > ideal. > I am FOR inclusion. I want everyone to feel welcome here. > Everyone.> > I agree. It seems to be about fixing something that isn’t broken, or as > in that story in the Bible where the people came to a consensus that > every other country around them had a king, so they should have a king > too. Nothing good came out of it in any cases where we have seen this > kind of illogic applied. “Most other big corporations have a deep > hierarchy of management, with too much power concentrated at the top, and > we want to be a big corporation, so we need to replicate that.” “The > other lemmings are running away so maybe we’d better follow.” It’s not > the open source way, which seemed to be working well enough already. > > > > If you give power to a committee of 3 people, they will probably abuse it > eventually, misjudge, cause bitterness, create factions, and some > developers will end up walking away. Seems predictable, doesn’t it? > > > > > You claim that this is about fixing something that isn't broken. Your > statement that a committee will predictably and eventually abuse their > powers and misjudge is, I feel, a > > statement that is spreading fear, doubt and uncertainty, without any > evidence within the scope of this community. > > > On the other hand I am aware of at least one concrete case where the > behavior of a reviewer has caused a contributor (with a track record of > accepted patches, btw) to > > turn away from the project and even resulted in an email of complaint > sent to the community manager. The lack of tools, written understanding > and common agreement > > on what is good behavior resulted in that nothing happened at all and > the contributor in question has stayed away from the project since then. > > > I do think that this is the exception, but it is crucial that we have > the right tools and mechanisms in place when unlikely exceptions happen, > in order to deal with them > > instead of ignoring them. After having seen this with my own eyes, I am > convinced of that. > > > Whether it is a code of conduct or kindness guidelines - anything like > that is something that I welcome as an improvement. > > > Simon > > +1 > > We do have a Code of Conduct at KDE for about 10 years now, and this hasn't > led to abuse of power, suppression of free speech, racism against white > people > or whatever other nonsense people seem to attribute to CoCs nowadays. > > On the contrary, it gave us a solid foundation to act against the (very > few, > fortunately) cases of abusive behavior to protect our contributors. As Simon > I > have seen the damage such behavior can do, and therefore would also welcome > tools/rules to be in place to deal with such situations. > > Regards, > Volker > > I fully agree. > > And btw, we have had a clear majority in favour of adding a CoC at the > Contributor Summit, and explicitly agreed that a group of people will work > on creating it. I’m happy we now have a first version, that we can use as a > basis for further discussions. > > Cheers, > Lars > > From Tor.arne.Vestbo at qt.io Thu Oct 25 13:32:12 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Thu, 25 Oct 2018 11:32:12 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> <1230131540461969@iva5-750e13568e4d.qloud-c.yandex.net> Message-ID: <46D6117A-F2AC-4096-BDE3-8224E0CC2B99@qt.io> I 100% stand behind Mitch’s summary below. This is a real problem in this project that not only makes it a less than great place to work, but is also indirectly affecting the quality of the code, for those that care only about that part. Tor Arne > On 25 Oct 2018, at 13:22, Mitch Curtis wrote: > > It's a bit of a loaded question. First you call asocial behaviour a "quirk", as if someone who treats other people like crap is "quirky" - I prefer your phrase "rude arse". Should a code of conduct aim to stop "quirky" behaviour amongst contributors? No, of course not. That's what makes people interesting. A code of conduct should draw the line between quirky behaviour and "rude arse" behaviour. > > To answer your question: in my experience, nothing happens. They continue being a rude arse because: > > 1) That is who they are and they aren't interested in changing. > 2) People have already decided that this person's technical contributions are worth enough that they can step on anyone, regardless of the fact that it's supposed to be a professional setting. > 3) They're "actually a nice person in real life"... as if this excuses it. So if I write "You're a dumbarse" on a piece of paper and send it through the post, but a week later invite you over to my house for a home-cooked meal, it's OK? Are we really encouraging keyboard warriors? > > Rafael said: > > "During all these years contributing to Qt I have encountered many times strong criticism in gerrit - some people were very harsh or *seemingly* rude - or that was what I thought, until I realized that: 1) it was just their modus operandi; 2) at the end of the day, their comments made sense and improved my code; 3) they were not butt hurt when roles were reversed." > > To me it seems like you guys are saying: > > "I don't care if this person treats me like crap because they sure can code." > > I'm happy for you if you've gotten this far in life and decided that you like being insulted in exchange for someone reviewing your code (or even just asking a question on IRC), but personally I do not like it. I'm more than capable of standing up for myself, but other people who feel the same way may not feel comfortable speaking out. > > What you're also saying is: > > "You (the Qt Project) aren't going to do anything about their behaviour because they contribute good code." > > Which sadly is true. Really, your question seems almost rhetorical given this. It's even explicitly acknowledged on the home page of the thing that we're basing our code of conduct on: > > "People with “merit” are often excused for their bad behavior in public spaces based on the value of their technical contributions." > > - https://www.contributor-covenant.org/ > > Disregarding all of the other factors (racism, sexual identity, age, etc.) and just keeping it purely about treating other people with respect: the statement above is absolutely true. > > Honestly I have my doubts whether this code of conduct will actually achieve its most basic goal, given that many people have apparently tried to intervene with the people who treat others poorly and nothing has come of it (although people will tell you it's gotten better). I hope it does, but I've been in the community and around these people long enough to know that it probably won't. Reading through these replies, it's also clear that a large amount of the people responding are quite happy with the status quo, which, although not surprising to me, is always disheartening. > > I haven't seen any racism, discrimination, etc., but there are definitely people within the community whose behaviour is such that other developers will avoid interacting with them, even if it would have likely improved the quality of their work or got that work done faster. I doubt you'll hear from those people though, because they just want to get their job done -- which is perfectly understandable, but does not excuse the behaviour of the people they try to avoid. > >> On Thu, Oct 25, 2018 at 1:06 PM Konstantin Tokarev > > wrote: >> >> >> >> >> 25.10.2018, 13:01, "NIkolai Marchenko" > >: >> >> And btw, we have had a clear majority in favour of adding a CoC at >> the Contributor Summit >> > >> > It seems very wrong to make such decisions at conventions where >> only a small part of the contributors can participate. >> > Especially for something as big and divisive >> >> +1 >> >> -- >> Regards, >> Konstantin >> > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From enmarantispam at gmail.com Thu Oct 25 14:21:16 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Thu, 25 Oct 2018 15:21:16 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <46D6117A-F2AC-4096-BDE3-8224E0CC2B99@qt.io> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> <1230131540461969@iva5-750e13568e4d.qloud-c.yandex.net> <46D6117A-F2AC-4096-BDE3-8224E0CC2B99@qt.io> Message-ID: > To answer your question: in my experience, nothing happens. They continue being a rude arse because: And that's my problem with this code of conduct. If it's unenforceable then this should not be Code but Guidelines. If it's enforceable it should first be decided what is going to happen in the case I described. > This is a real problem in this project that not only makes it a less than great place to work, but is also indirectly affecting the quality of the code Multiple people have alrady asked for examples of what the code is trying to solve. If you have those, we'd like to hear about these exact cases. On Thu, Oct 25, 2018 at 2:32 PM Tor Arne Vestbø wrote: > I 100% stand behind Mitch’s summary below. This is a real problem in this > project that not only makes it a less than great place to work, but is also > indirectly affecting the quality of the code, for those that care only > about that part. > > Tor Arne > > > On 25 Oct 2018, at 13:22, Mitch Curtis wrote: > > > > It's a bit of a loaded question. First you call asocial behaviour a > "quirk", as if someone who treats other people like crap is "quirky" - I > prefer your phrase "rude arse". Should a code of conduct aim to stop > "quirky" behaviour amongst contributors? No, of course not. That's what > makes people interesting. A code of conduct should draw the line between > quirky behaviour and "rude arse" behaviour. > > > > To answer your question: in my experience, nothing happens. They > continue being a rude arse because: > > > > 1) That is who they are and they aren't interested in changing. > > 2) People have already decided that this person's technical > contributions are worth enough that they can step on anyone, regardless of > the fact that it's supposed to be a professional setting. > > 3) They're "actually a nice person in real life"... as if this excuses > it. So if I write "You're a dumbarse" on a piece of paper and send it > through the post, but a week later invite you over to my house for a > home-cooked meal, it's OK? Are we really encouraging keyboard warriors? > > > > Rafael said: > > > > "During all these years contributing to Qt I have encountered many times > strong criticism in gerrit - some people were very harsh or *seemingly* > rude - or that was what I thought, until I realized that: 1) it was just > their modus operandi; 2) at the end of the day, their comments made sense > and improved my code; 3) they were not butt hurt when roles were reversed." > > > > To me it seems like you guys are saying: > > > > "I don't care if this person treats me like crap because they sure can > code." > > > > I'm happy for you if you've gotten this far in life and decided that you > like being insulted in exchange for someone reviewing your code (or even > just asking a question on IRC), but personally I do not like it. I'm more > than capable of standing up for myself, but other people who feel the same > way may not feel comfortable speaking out. > > > > What you're also saying is: > > > > "You (the Qt Project) aren't going to do anything about their behaviour > because they contribute good code." > > > > Which sadly is true. Really, your question seems almost rhetorical given > this. It's even explicitly acknowledged on the home page of the thing that > we're basing our code of conduct on: > > > > "People with “merit” are often excused for their bad behavior in public > spaces based on the value of their technical contributions." > > > > - https://www.contributor-covenant.org/ > > > > Disregarding all of the other factors (racism, sexual identity, age, > etc.) and just keeping it purely about treating other people with respect: > the statement above is absolutely true. > > > > Honestly I have my doubts whether this code of conduct will actually > achieve its most basic goal, given that many people have apparently tried > to intervene with the people who treat others poorly and nothing has come > of it (although people will tell you it's gotten better). I hope it does, > but I've been in the community and around these people long enough to know > that it probably won't. Reading through these replies, it's also clear that > a large amount of the people responding are quite happy with the status > quo, which, although not surprising to me, is always disheartening. > > > > I haven't seen any racism, discrimination, etc., but there are > definitely people within the community whose behaviour is such that other > developers will avoid interacting with them, even if it would have likely > improved the quality of their work or got that work done faster. I doubt > you'll hear from those people though, because they just want to get their > job done -- which is perfectly understandable, but does not excuse the > behaviour of the people they try to avoid. > > > >> On Thu, Oct 25, 2018 at 1:06 PM Konstantin Tokarev >> > wrote: > >> > >> > >> > >> > >> 25.10.2018, 13:01, "NIkolai Marchenko" >> >: > >> >> And btw, we have had a clear majority in favour of adding a CoC > at > >> the Contributor Summit > >> > > >> > It seems very wrong to make such decisions at conventions where > >> only a small part of the contributors can participate. > >> > Especially for something as big and divisive > >> > >> +1 > >> > >> -- > >> Regards, > >> Konstantin > >> > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tor.arne.Vestbo at qt.io Thu Oct 25 14:30:31 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Thu, 25 Oct 2018 12:30:31 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> <1230131540461969@iva5-750e13568e4d.qloud-c.yandex.net> <46D6117A-F2AC-4096-BDE3-8224E0CC2B99@qt.io> Message-ID: <467E4E61-41F4-4952-B185-FD7A0A14D215@qt.io> > On 25 Oct 2018, at 14:21, NIkolai Marchenko wrote: > > Multiple people have alrady asked for examples of what the code is trying to solve. > If you have those, we'd like to hear about these exact cases. Mitch’s email describes this in a good way. I’m obviously not going to go into details about concrete cases. If the project/community can’t trust that these are real concerns coming from long standing contributors, without airing dirty laundry in the process, then we’re worse off than I thought. Tor Arne > > > > > On Thu, Oct 25, 2018 at 2:32 PM Tor Arne Vestbø wrote: > I 100% stand behind Mitch’s summary below. This is a real problem in this project that not only makes it a less than great place to work, but is also indirectly affecting the quality of the code, for those that care only about that part. > > Tor Arne > > > On 25 Oct 2018, at 13:22, Mitch Curtis wrote: > > > > It's a bit of a loaded question. First you call asocial behaviour a "quirk", as if someone who treats other people like crap is "quirky" - I prefer your phrase "rude arse". Should a code of conduct aim to stop "quirky" behaviour amongst contributors? No, of course not. That's what makes people interesting. A code of conduct should draw the line between quirky behaviour and "rude arse" behaviour. > > > > To answer your question: in my experience, nothing happens. They continue being a rude arse because: > > > > 1) That is who they are and they aren't interested in changing. > > 2) People have already decided that this person's technical contributions are worth enough that they can step on anyone, regardless of the fact that it's supposed to be a professional setting. > > 3) They're "actually a nice person in real life"... as if this excuses it. So if I write "You're a dumbarse" on a piece of paper and send it through the post, but a week later invite you over to my house for a home-cooked meal, it's OK? Are we really encouraging keyboard warriors? > > > > Rafael said: > > > > "During all these years contributing to Qt I have encountered many times strong criticism in gerrit - some people were very harsh or *seemingly* rude - or that was what I thought, until I realized that: 1) it was just their modus operandi; 2) at the end of the day, their comments made sense and improved my code; 3) they were not butt hurt when roles were reversed." > > > > To me it seems like you guys are saying: > > > > "I don't care if this person treats me like crap because they sure can code." > > > > I'm happy for you if you've gotten this far in life and decided that you like being insulted in exchange for someone reviewing your code (or even just asking a question on IRC), but personally I do not like it. I'm more than capable of standing up for myself, but other people who feel the same way may not feel comfortable speaking out. > > > > What you're also saying is: > > > > "You (the Qt Project) aren't going to do anything about their behaviour because they contribute good code." > > > > Which sadly is true. Really, your question seems almost rhetorical given this. It's even explicitly acknowledged on the home page of the thing that we're basing our code of conduct on: > > > > "People with “merit” are often excused for their bad behavior in public spaces based on the value of their technical contributions." > > > > - https://www.contributor-covenant.org/ > > > > Disregarding all of the other factors (racism, sexual identity, age, etc.) and just keeping it purely about treating other people with respect: the statement above is absolutely true. > > > > Honestly I have my doubts whether this code of conduct will actually achieve its most basic goal, given that many people have apparently tried to intervene with the people who treat others poorly and nothing has come of it (although people will tell you it's gotten better). I hope it does, but I've been in the community and around these people long enough to know that it probably won't. Reading through these replies, it's also clear that a large amount of the people responding are quite happy with the status quo, which, although not surprising to me, is always disheartening. > > > > I haven't seen any racism, discrimination, etc., but there are definitely people within the community whose behaviour is such that other developers will avoid interacting with them, even if it would have likely improved the quality of their work or got that work done faster. I doubt you'll hear from those people though, because they just want to get their job done -- which is perfectly understandable, but does not excuse the behaviour of the people they try to avoid. > > > >> On Thu, Oct 25, 2018 at 1:06 PM Konstantin Tokarev >> > wrote: > >> > >> > >> > >> > >> 25.10.2018, 13:01, "NIkolai Marchenko" >> >: > >> >> And btw, we have had a clear majority in favour of adding a CoC at > >> the Contributor Summit > >> > > >> > It seems very wrong to make such decisions at conventions where > >> only a small part of the contributors can participate. > >> > Especially for something as big and divisive > >> > >> +1 > >> > >> -- > >> Regards, > >> Konstantin > >> > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > From yetanotherandreyev at gmail.com Thu Oct 25 15:03:10 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Thu, 25 Oct 2018 16:03:10 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <467E4E61-41F4-4952-B185-FD7A0A14D215@qt.io> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> <1230131540461969@iva5-750e13568e4d.qloud-c.yandex.net> <46D6117A-F2AC-4096-BDE3-8224E0CC2B99@qt.io> <467E4E61-41F4-4952-B185-FD7A0A14D215@qt.io> Message-ID: I guess NIkolai point was not about the trust and some personal details. I guess everyone could agree that conflicts are possible. The question was is proposed CoC helping to solve them, or is it making things worse? Are there any objective metrics? P.S.: as I said, I personally not against any CoC/guidelines by default, but have problems with proposed implementation and want to help чт, 25 окт. 2018 г. в 15:30, Tor Arne Vestbø : > > > On 25 Oct 2018, at 14:21, NIkolai Marchenko > wrote: > > > > Multiple people have alrady asked for examples of what the code is > trying to solve. > > If you have those, we'd like to hear about these exact cases. > > Mitch’s email describes this in a good way. I’m obviously not going to go > into details about concrete cases. If the project/community can’t trust > that these are real concerns coming from long standing contributors, > without airing dirty laundry in the process, then we’re worse off than I > thought. > > Tor Arne > > > > > > > > > > > On Thu, Oct 25, 2018 at 2:32 PM Tor Arne Vestbø > wrote: > > I 100% stand behind Mitch’s summary below. This is a real problem in > this project that not only makes it a less than great place to work, but is > also indirectly affecting the quality of the code, for those that care only > about that part. > > > > Tor Arne > > > > > On 25 Oct 2018, at 13:22, Mitch Curtis wrote: > > > > > > It's a bit of a loaded question. First you call asocial behaviour a > "quirk", as if someone who treats other people like crap is "quirky" - I > prefer your phrase "rude arse". Should a code of conduct aim to stop > "quirky" behaviour amongst contributors? No, of course not. That's what > makes people interesting. A code of conduct should draw the line between > quirky behaviour and "rude arse" behaviour. > > > > > > To answer your question: in my experience, nothing happens. They > continue being a rude arse because: > > > > > > 1) That is who they are and they aren't interested in changing. > > > 2) People have already decided that this person's technical > contributions are worth enough that they can step on anyone, regardless of > the fact that it's supposed to be a professional setting. > > > 3) They're "actually a nice person in real life"... as if this excuses > it. So if I write "You're a dumbarse" on a piece of paper and send it > through the post, but a week later invite you over to my house for a > home-cooked meal, it's OK? Are we really encouraging keyboard warriors? > > > > > > Rafael said: > > > > > > "During all these years contributing to Qt I have encountered many > times strong criticism in gerrit - some people were very harsh or > *seemingly* rude - or that was what I thought, until I realized that: 1) it > was just their modus operandi; 2) at the end of the day, their comments > made sense and improved my code; 3) they were not butt hurt when roles were > reversed." > > > > > > To me it seems like you guys are saying: > > > > > > "I don't care if this person treats me like crap because they sure can > code." > > > > > > I'm happy for you if you've gotten this far in life and decided that > you like being insulted in exchange for someone reviewing your code (or > even just asking a question on IRC), but personally I do not like it. I'm > more than capable of standing up for myself, but other people who feel the > same way may not feel comfortable speaking out. > > > > > > What you're also saying is: > > > > > > "You (the Qt Project) aren't going to do anything about their > behaviour because they contribute good code." > > > > > > Which sadly is true. Really, your question seems almost rhetorical > given this. It's even explicitly acknowledged on the home page of the thing > that we're basing our code of conduct on: > > > > > > "People with “merit” are often excused for their bad behavior in > public spaces based on the value of their technical contributions." > > > > > > - https://www.contributor-covenant.org/ > > > > > > Disregarding all of the other factors (racism, sexual identity, age, > etc.) and just keeping it purely about treating other people with respect: > the statement above is absolutely true. > > > > > > Honestly I have my doubts whether this code of conduct will actually > achieve its most basic goal, given that many people have apparently tried > to intervene with the people who treat others poorly and nothing has come > of it (although people will tell you it's gotten better). I hope it does, > but I've been in the community and around these people long enough to know > that it probably won't. Reading through these replies, it's also clear that > a large amount of the people responding are quite happy with the status > quo, which, although not surprising to me, is always disheartening. > > > > > > I haven't seen any racism, discrimination, etc., but there are > definitely people within the community whose behaviour is such that other > developers will avoid interacting with them, even if it would have likely > improved the quality of their work or got that work done faster. I doubt > you'll hear from those people though, because they just want to get their > job done -- which is perfectly understandable, but does not excuse the > behaviour of the people they try to avoid. > > > > > >> On Thu, Oct 25, 2018 at 1:06 PM Konstantin Tokarev > >> > wrote: > > >> > > >> > > >> > > >> > > >> 25.10.2018, 13:01, "NIkolai Marchenko" > >> >: > > >> >> And btw, we have had a clear majority in favour of adding a > CoC at > > >> the Contributor Summit > > >> > > > >> > It seems very wrong to make such decisions at conventions where > > >> only a small part of the contributors can participate. > > >> > Especially for something as big and divisive > > >> > > >> +1 > > >> > > >> -- > > >> Regards, > > >> Konstantin > > >> > > > > > > _______________________________________________ > > > Development mailing list > > > Development at qt-project.org > > > http://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch.curtis at qt.io Thu Oct 25 15:05:09 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Thu, 25 Oct 2018 13:05:09 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> <1230131540461969@iva5-750e13568e4d.qloud-c.yandex.net> <46D6117A-F2AC-4096-BDE3-8224E0CC2B99@qt.io> Message-ID: > -----Original Message----- > From: NIkolai Marchenko > Sent: Thursday, 25 October 2018 2:21 PM > To: Tor Arne Vestbø > Cc: Mitch Curtis ; Konstantin Tokarev > ; Qt development mailing list project.org> > Subject: Re: [Development] QUIP 12: Code of Conduct > > > To answer your question: in my experience, nothing happens. They > continue being a rude arse because: > And that's my problem with this code of conduct. > If it's unenforceable then this should not be Code but Guidelines. > If it's enforceable it should first be decided what is going to happen in the > case I described. Call it whatever you like. If it were up to me I'd call it "Things Your Parents Should Have Taught You", just so that people can't attack it based on the boilerplate text that was copied in from that website. > > This is a real problem in this project that not only makes it a less than great > place to work, but is also indirectly affecting the quality of the code > Multiple people have alrady asked for examples of what the code is trying to > solve. > If you have those, we'd like to hear about these exact cases. - If someone asks a question, don't call their question stupid. This makes them far less likely to ask questions. Hopefully I don't need to tell you how important asking questions is for learning. If you care about code quality, you *want* people asking questions. - If someone pushes a patch, don't call their patch stupid. The person wrote that patch because they're trying to make Qt better, so even if you're "just" attacking the patch itself and not the person directly, you're still going to make them feel like crap. Review a patch by offering constructive feedback. You don't have to be super polite if that's not who you are, but you also don't need to be rude. If you really care about what you're doing, then why not focus that awf--delightful quirky attitude into objective feedback? I left a comment on the Gerrit patch if you care to see what this kind of communication looks like in practice. All of this is basically just "don't be a snarky arse". It's sad that it has to be mentioned at all, but... here we are. Also, yes, I realise that I'm being snarky, but as someone else mentioned, I'm sure everyone who this is meant for can take it as well as they dish it out. > > > On Thu, Oct 25, 2018 at 2:32 PM Tor Arne Vestbø > wrote: > > > I 100% stand behind Mitch’s summary below. This is a real problem in > this project that not only makes it a less than great place to work, but is also > indirectly affecting the quality of the code, for those that care only about that > part. > > Tor Arne > > > On 25 Oct 2018, at 13:22, Mitch Curtis > wrote: > > > > It's a bit of a loaded question. First you call asocial behaviour a > "quirk", as if someone who treats other people like crap is "quirky" - I prefer > your phrase "rude arse". Should a code of conduct aim to stop "quirky" > behaviour amongst contributors? No, of course not. That's what makes > people interesting. A code of conduct should draw the line between quirky > behaviour and "rude arse" behaviour. > > > > To answer your question: in my experience, nothing happens. They > continue being a rude arse because: > > > > 1) That is who they are and they aren't interested in changing. > > 2) People have already decided that this person's technical > contributions are worth enough that they can step on anyone, regardless of > the fact that it's supposed to be a professional setting. > > 3) They're "actually a nice person in real life"... as if this excuses it. > So if I write "You're a dumbarse" on a piece of paper and send it through the > post, but a week later invite you over to my house for a home-cooked meal, > it's OK? Are we really encouraging keyboard warriors? > > > > Rafael said: > > > > "During all these years contributing to Qt I have encountered many > times strong criticism in gerrit - some people were very harsh or *seemingly* > rude - or that was what I thought, until I realized that: 1) it was just their > modus operandi; 2) at the end of the day, their comments made sense and > improved my code; 3) they were not butt hurt when roles were reversed." > > > > To me it seems like you guys are saying: > > > > "I don't care if this person treats me like crap because they sure can > code." > > > > I'm happy for you if you've gotten this far in life and decided that > you like being insulted in exchange for someone reviewing your code (or > even just asking a question on IRC), but personally I do not like it. I'm more > than capable of standing up for myself, but other people who feel the same > way may not feel comfortable speaking out. > > > > What you're also saying is: > > > > "You (the Qt Project) aren't going to do anything about their > behaviour because they contribute good code." > > > > Which sadly is true. Really, your question seems almost rhetorical > given this. It's even explicitly acknowledged on the home page of the thing > that we're basing our code of conduct on: > > > > "People with “merit” are often excused for their bad behavior in > public spaces based on the value of their technical contributions." > > > > - https://www.contributor-covenant.org/ > > > > Disregarding all of the other factors (racism, sexual identity, age, > etc.) and just keeping it purely about treating other people with respect: the > statement above is absolutely true. > > > > Honestly I have my doubts whether this code of conduct will > actually achieve its most basic goal, given that many people have apparently > tried to intervene with the people who treat others poorly and nothing has > come of it (although people will tell you it's gotten better). I hope it does, but > I've been in the community and around these people long enough to know > that it probably won't. Reading through these replies, it's also clear that a > large amount of the people responding are quite happy with the status quo, > which, although not surprising to me, is always disheartening. > > > > I haven't seen any racism, discrimination, etc., but there are > definitely people within the community whose behaviour is such that other > developers will avoid interacting with them, even if it would have likely > improved the quality of their work or got that work done faster. I doubt you'll > hear from those people though, because they just want to get their job done > -- which is perfectly understandable, but does not excuse the behaviour of > the people they try to avoid. > > > >> On Thu, Oct 25, 2018 at 1:06 PM Konstantin Tokarev > > >> > > > wrote: > >> > >> > >> > >> > >> 25.10.2018, 13:01, "NIkolai Marchenko" > > >> > >: > >> >> And btw, we have had a clear majority in favour of adding a > CoC at > >> the Contributor Summit > >> > > >> > It seems very wrong to make such decisions at conventions > where > >> only a small part of the contributors can participate. > >> > Especially for something as big and divisive > >> > >> +1 > >> > >> -- > >> Regards, > >> Konstantin > >> > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org project.org> > > http://lists.qt-project.org/mailman/listinfo/development > > From Martin.Smith at qt.io Thu Oct 25 15:17:37 2018 From: Martin.Smith at qt.io (Martin Smith) Date: Thu, 25 Oct 2018 13:17:37 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: I suspect that most if not all of the commenters here who object to the CoC object to the attempt to define unacceptable behavior. It really has to be decided on a case by case basis, so remove the examples of unacceptable behavior, and don't attempt to define it at all. No one can object to the examples of positive behavior. No one can object to a CoC that simply promotes those positive examples and then establishes a complaint process and a CoC committee to rule on each complaint. martin ________________________________________ From: Development on behalf of Ulf Hermann Sent: Wednesday, October 24, 2018 9:17:09 AM To: development at qt-project.org Subject: [Development] QUIP 12: Code of Conduct Hi, regarding our earlier discussions on a possible Code of Conduct, here as well as at the Contributors' Summit 2017, I've pushed a QUIP with the necessary rules and definitions: https://codereview.qt-project.org/243623 Please review it. regards, Ulf _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From mitch.curtis at qt.io Thu Oct 25 15:32:16 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Thu, 25 Oct 2018 13:32:16 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> <1230131540461969@iva5-750e13568e4d.qloud-c.yandex.net> Message-ID: Just realised that you replied privately; let's take it back to the list. > -----Original Message----- > From: Mitch Curtis > Sent: Thursday, 25 October 2018 3:31 PM > To: Rafael Roquetto > Subject: RE: [Development] QUIP 12: Code of Conduct > > > -----Original Message----- > > From: Rafael Roquetto > > Sent: Thursday, 25 October 2018 2:42 PM > > To: Mitch Curtis > > Subject: Re: [Development] QUIP 12: Code of Conduct > > > > > > > > On 10/25/18 9:22 PM, Mitch Curtis wrote: > > > > > > > > >> -----Original Message----- > > >> From: Development > >> project.org> On Behalf Of NIkolai Marchenko > > >> Sent: Thursday, 25 October 2018 12:13 PM > > >> To: Konstantin Tokarev > > >> Cc: Qt development mailing list > > >> Subject: Re: [Development] QUIP 12: Code of Conduct > > > > > Rafael said: > > > > > > "During all these years contributing to Qt I have encountered many > > > times > > strong criticism in gerrit - some people were very harsh or > > *seemingly* rude > > - or that was what I thought, until I realized that: 1) it was just > > their modus operandi; 2) at the end of the day, their comments made > > sense and improved my code; 3) they were not butt hurt when roles were > reversed." > > > > > > To me it seems like you guys are saying: > > > > > > "I don't care if this person treats me like crap because they sure can > code." > > > > Exactly, I don't care as long as certain boundaries, such as name > > calling, are not crossed. > > Great! > > > And even if, it really depends on the context: > > Wait, what? > > > I would rather communicate with Linus Torvalds than having to on ice > > with someone else for the sake of politeness. And just to be clear, I > > am extrapolating here. > > That's a really odd analogy to choose. > > If you are reviewing a patch or communicating with someone within this > community, you're doing so by choice: either because you're being paid to or > you're here on your own free time. Both are choices. The point of this code > of conduct is not to limit *who* you communicate with, but *how* you treat > those people who you communicate with in the course of contributing. It's to > help people who are getting treated like crap by the "expert" developers > feel more safe in the community by making it clear what will not be accepted. > > > > > > > I'm happy for you if you've gotten this far in life and decided that > > > you like > > being insulted in exchange for someone reviewing your code (or even > > just asking a question on IRC), but personally I do not like it. I'm > > more than capable of standing up for myself, but other people who feel > > the same way may not feel comfortable speaking out. > > > > > > What you're also saying is: > > > > > > "You (the Qt Project) aren't going to do anything about their > > > behaviour > > because they contribute good code." > > > > I never said that. See my answer to Simon. Alas, this is something I > > vehemently oppose. Also, to be clear: I am not suggesting we suck it > > up and do not take action. I was just suggesting that maybe a CoC is > > not the way to go. > > It was meant for Nikolai, just bad quoting on my behalf. > > > > > > > Which sadly is true. Really, your question seems almost rhetorical > > > given > > this. It's even explicitly acknowledged on the home page of the thing > > that we're basing our code of conduct on: > > > > > > "People with “merit” are often excused for their bad behavior in > > > public > > spaces based on the value of their technical contributions." > > > > And they shouldn't be excused. But this goes both ways. There are a > > lot of people who like to turn everything into a speech problem. This > > is when we have to be tolerant and respectful. Sadly, indeed, in the > > real world things don't work quite like that. > > Yes, so: finding a balance. I agree. I just want to get my job done and improve > as a developer. I don't think anyone wants to force people to be overly > polite, they just don't want to be attacked. Constructive criticism without > snarkiness is personally all I'm asking for. > > > > > > > - https://www.contributor-covenant.org/ > > > > > > Disregarding all of the other factors (racism, sexual identity, age, > > > etc.) and > > just keeping it purely about treating other people with respect: the > > statement above is absolutely true. > > > > > > Honestly I have my doubts whether this code of conduct will actually > > achieve its most basic goal, given that many people have apparently > > tried to intervene with the people who treat others poorly and nothing > > has come of it (although people will tell you it's gotten better). I > > hope it does, but I've been in the community and around these people > > long enough to know that it probably won't. Reading through these > > replies, it's also clear that a large amount of the people responding > > are quite happy with the status quo, which, although not surprising to me, > is always disheartening. > > > > > > I haven't seen any racism, discrimination, etc., but there are > > > definitely > > people within the community whose behaviour is such that other > > developers will avoid interacting with them, even if it would have > > likely improved the quality of their work or got that work done > > faster. I doubt you'll hear from those people though, because they > > just want to get their job done -- which is perfectly understandable, > > but does not excuse the behaviour of the people they try to avoid. > > > > > >> On Thu, Oct 25, 2018 at 1:06 PM Konstantin Tokarev > > >> > wrote: > > >> > > >> > > >> > > >> > > >> 25.10.2018, 13:01, "NIkolai Marchenko" > >> >: > > >> >> And btw, we have had a clear majority in favour of adding a CoC > > >> at the Contributor Summit > > >> > > > >> > It seems very wrong to make such decisions at conventions where > > >> only a small part of the contributors can participate. > > >> > Especially for something as big and divisive > > >> > > >> +1 > > >> > > >> -- > > >> Regards, > > >> Konstantin > > >> > > > > > > _______________________________________________ > > > Development mailing list > > > Development at qt-project.org > > > http://lists.qt-project.org/mailman/listinfo/development > > > From edward.welbourne at qt.io Thu Oct 25 15:33:03 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 25 Oct 2018 13:33:03 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> , <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> Message-ID: Rafael Roquetto (25 October 2018 11:50) > I understand this has already been set in stone, I do not think you should take that for granted. We do have a process by which all contributors can contribute to the decision and should be listened to, so that the resulting decision can be shaped by any and all of us. > and I am not here in the hopes this will change. Speak and know you are heard. Persuasion is possible. > I would like to start by saying I fully agree with Shawn: what exactly > are we trying to fix? That sometimes folk have felt so intimidated that they give up on trying to make a contribution; and that, were potential worse conduct to cause distress to a contributor, we have no process in place that could give them confidence that their distress will be respected and honest efforts will be made to relieve it. Various variations and permutations on these themes may also be relevant; see Simon's mail. > That is not to say problems never happened, but these things have side > effects - sometimes the most unintended ones. As C++ programmers, we > should know well that unintended side-effects steaming from > well-intentioned constructs are no exception (pun intended). This is why we takes care about designing things and invite review. Which is exactly the process you see before you. > Or is it proven technology? See Volker's earlier post: KDE (among other communities) has been using a CoC for some time and has (on the thankfully rare occasions that it's mattered) found it does indeed work. Proof enough ? It's clearly possible to get a code of conduct wrong; we need to take care to avoid making those mistakes. It may be possible that a code of conduct wouldn't be any help in *this* community, 'though it has been in diverse others; if you believe that is the case, make the case for it. Some of us, at least, shall listen. > Which brings to my second point, a very personal one: more or less in > line with what Jason said, programming *to me* has always been about > bits and bytes, about the code, about computers, about being able to > make things appear on the screen and to control the machine. Free > Software has been about.... free software and that's it. Nothing is ever so simple: projects that fail to be welcoming to contributors get fewer contributions. > I find it extremely off-putting to see that the Qt project is > embarking in this sort of politics I'm not sure why you see it as politics, or what you mean by "politics". It's part of governance, ensuring we do have oversight of a process that surely does happen informally anyway - if I see another reviewer being (IMO) rude to a contributor I have been known to take that up with the reviewer, on my own initiative; but I might be out of line (I have no expertise in this area) in doing so, or might not go about it in the most constructive way; and I have no authority, so the reviewer might not pay attention to my poking. Having a Conduct Committee who (hopefully) have some clue about how to diplomatically invite someone to be gentler to their peers would be an improvement over my informal (and arguably also rude) attempt to deal with what I perceive as rude; it might also ensure that a consistent standard is applied for what *does* constitute rudery. > - again, if things were broken and a CoC could fix them, I would be > more than happy to join the train, but that doesn't seem to be the > case. At least from my humble perspective. I have seen a contributor despair at a reviewer, who they felt was being unfair, and give up on contributing. I have felt similarly about one reviewer, from time to time. > During all these years contributing to Qt I have encountered many > times strong criticism in gerrit - some people were very harsh or > *seemingly* rude - or that was what I thought, Note that some folk aren't going to get past that. The distinction between seeming rude and being rude is rather thin. You and I have the confidence to stand up to rudery and get past the initial impression to get constructive results despite it, but some folk do get put off by it and we do lose their contributions as a result. I have seen this happen. IIU Simon correctly, he has too. > until I realized that: 1) it was just their modus operandi; That may be: but if they learn to be at least somewhat friendly about it, they're less likely to scare off contributors. There should be no need for someone to tolerate intimidating conduct before they can get the good that is in their code recognised and, after any needed improvements, put to use. > 2) at the end of the day, their comments made sense and improved my > code; That is nice, but surely it would be better if they could steer you towards those improvements *without* making you uncomfortable on the way. In particular, for some potential contributors, that makes the difference between getting their contribution in and giving up; and a kinder process might leave more contributors eager to come back with further contributions, where an intimidating one is apt to discourage them from attempting further contributions. > 3) they were not butt hurt when roles were reversed. I do not find that an adequate excuse. Certainly, if they *were* upset they'd be guilty of hypocrisy. The fact that they can cope with abusive treatment isn't any kind of justification for dishing such treatment out to others. It is better to actually be considerate towards those whose code one reviews. I remember school-mates being singularly rude to each other all the time. Notably, on the football pitch, they threw about a barrage of insult, demand and blame - at their own team-mates, note - that made it unpleasant to play with them. In competitive leagues, being a small boy (until late in my time at school) and not much liked by the ones who got to pick teams, I got to be assigned to a team consisting mostly of boys a year younger; who, by virtue of my age, treated me with at least somewhat more respect; so I was quite happy to not be picked to be in the team of my peers, though I got dragged in enough times to see how they treated one another (and me, but that's how they always treated me). Eventually, once I'd grown and become rather good at what I did, my peers felt they should condescend to let me play in their team; but I declined, because I did not enjoy playing in the abusive environment they generated. This left me in a team of (mostly) younger boys, so I had to be captain, despite that being normally a forward's job, not a centre-back's. My first rule was that my team were not allowed to be rude to one another or blame each other for things that didn't go our way; we were on the playing field to get some exercise and have some fun; if we could also win, so much the better. This soon lead to a team that was enjoying playing and worked together better than most of the teams of our peers that we came up against. Despite being "less able" players in the fairly objective terms of various teachers, this team beat teams of "better" players because they were crushing their own team-mates' morale, while we were having fun (at their expense). That included sincerely congratulating them when they played well. In an abusive environment, the thick-skinned bullies rise to the top and keep the place abusive, so that their kind keeps on winning. In a more respectful environment, folk who treat others with respect gain respect and, feeling respected, are more able to deliver useful results. I think this community is considerably closer to the latter than the former, but the exact experience you describe is a shadow of the former, that I'd gladly banish. The questions I want addressed are: * Will a CoC help ? * If so *what* CoC do we want ? and * What surrounding process will lead to respectful resolution of such conflicts as do arise around the CoC ? > Communication/criticism just like this is unambiguously > straightforward and I *personally* prefer it this way. Would you prefer it yet more if you were treated more gracefully, even when someone is pointing out your errors ? Eddy. From yetanotherandreyev at gmail.com Thu Oct 25 15:56:18 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Thu, 25 Oct 2018 16:56:18 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: > I suspect that most if not all of the commenters here who object to the CoC object to the attempt to define unacceptable behavior. It really has to be decided on a case by case basis, so remove the examples of unacceptable behavior, and don't attempt to define it at all. I'm okay to develop the rules. I disagree though to leave an attempt to define unacceptable or acceptable behavior. What should we leave then? General recommendation about being conscious and think about future consequences? It could be written in one sentense. Why do we need the document then? > so remove the examples of unacceptable behavior I agree that just the examples are not helping > No one can object to the examples of positive behavior. No one can object to a CoC that simply promotes those positive examples and then establishes a complaint process and a CoC committee to rule on each complaint. CoC committee is just a people. They need some agreements how to make decisions. чт, 25 окт. 2018 г. в 16:17, Martin Smith : > I suspect that most if not all of the commenters here who object to the > CoC object to the attempt to define unacceptable behavior. It really has to > be decided on a case by case basis, so remove the examples of unacceptable > behavior, and don't attempt to define it at all. > > No one can object to the examples of positive behavior. No one can object > to a CoC that simply promotes those positive examples and then establishes > a complaint process and a CoC committee to rule on each complaint. > > martin > > ________________________________________ > From: Development > on behalf of Ulf Hermann > Sent: Wednesday, October 24, 2018 9:17:09 AM > To: development at qt-project.org > Subject: [Development] QUIP 12: Code of Conduct > > Hi, > > regarding our earlier discussions on a possible Code of Conduct, here as > well as at the Contributors' Summit 2017, I've pushed a QUIP with the > necessary rules and definitions: > > https://codereview.qt-project.org/243623 > > Please review it. > > regards, > Ulf > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Smith at qt.io Thu Oct 25 16:02:18 2018 From: Martin.Smith at qt.io (Martin Smith) Date: Thu, 25 Oct 2018 14:02:18 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> , Message-ID: >Why do we need the document then? We need the document to explain the complaint process and to establish the committee for dealing with complaints. >CoC committee is just a people. They need some agreements how to make decisions. We are adults. Despite the apparent tolerance of the bad behavior of Donald Trump, we all know what is bad behavior in this context. ________________________________________ From: Alexey Andreyev Sent: Thursday, October 25, 2018 3:56:18 PM To: Martin Smith Cc: Ulf Hermann; Qt development mailing list Subject: Re: [Development] QUIP 12: Code of Conduct > I suspect that most if not all of the commenters here who object to the CoC object to the attempt to define unacceptable behavior. It really has to be decided on a case by case basis, so remove the examples of unacceptable behavior, and don't attempt to define it at all. I'm okay to develop the rules. I disagree though to leave an attempt to define unacceptable or acceptable behavior. What should we leave then? General recommendation about being conscious and think about future consequences? It could be written in one sentense. Why do we need the document then? > so remove the examples of unacceptable behavior I agree that just the examples are not helping > No one can object to the examples of positive behavior. No one can object to a CoC that simply promotes those positive examples and then establishes a complaint process and a CoC committee to rule on each complaint. CoC committee is just a people. They need some agreements how to make decisions. чт, 25 окт. 2018 г. в 16:17, Martin Smith >: I suspect that most if not all of the commenters here who object to the CoC object to the attempt to define unacceptable behavior. It really has to be decided on a case by case basis, so remove the examples of unacceptable behavior, and don't attempt to define it at all. No one can object to the examples of positive behavior. No one can object to a CoC that simply promotes those positive examples and then establishes a complaint process and a CoC committee to rule on each complaint. martin ________________________________________ From: Development > on behalf of Ulf Hermann > Sent: Wednesday, October 24, 2018 9:17:09 AM To: development at qt-project.org Subject: [Development] QUIP 12: Code of Conduct Hi, regarding our earlier discussions on a possible Code of Conduct, here as well as at the Contributors' Summit 2017, I've pushed a QUIP with the necessary rules and definitions: https://codereview.qt-project.org/243623 Please review it. regards, Ulf _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From yetanotherandreyev at gmail.com Thu Oct 25 16:10:33 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Thu, 25 Oct 2018 17:10:33 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: > We need the document to explain the complaint process and to establish the committee for dealing with complaints. If we have a committee, probably they should have some statements and agreements about how to work (I'm okay if it should be discussed separately from CoC) > We are adults. Despite the apparent tolerance of the bad behavior of Donald Trump, we all know what is bad behavior in this context I'm afraid, provided example is not an exception of our behavior as adults чт, 25 окт. 2018 г. в 17:02, Martin Smith : > >Why do we need the document then? > > We need the document to explain the complaint process and to establish the > committee for dealing with complaints. > > >CoC committee is just a people. They need some agreements how to make > decisions. > > We are adults. Despite the apparent tolerance of the bad behavior of > Donald Trump, we all know what is bad behavior in this context. > > ________________________________________ > From: Alexey Andreyev > Sent: Thursday, October 25, 2018 3:56:18 PM > To: Martin Smith > Cc: Ulf Hermann; Qt development mailing list > Subject: Re: [Development] QUIP 12: Code of Conduct > > > I suspect that most if not all of the commenters here who object to the > CoC object to the attempt to define unacceptable behavior. It really has to > be decided on a case by case basis, so remove the examples of unacceptable > behavior, and don't attempt to define it at all. > > I'm okay to develop the rules. I disagree though to leave an attempt to > define unacceptable or acceptable behavior. What should we leave then? > General recommendation about being conscious and think about future > consequences? It could be written in one sentense. Why do we need the > document then? > > > so remove the examples of unacceptable behavior > I agree that just the examples are not helping > > > No one can object to the examples of positive behavior. No one can > object to a CoC that simply promotes those positive examples and then > establishes a complaint process and a CoC committee to rule on each > complaint. > > CoC committee is just a people. They need some agreements how to make > decisions. > > чт, 25 окт. 2018 г. в 16:17, Martin Smith Martin.Smith at qt.io>>: > I suspect that most if not all of the commenters here who object to the > CoC object to the attempt to define unacceptable behavior. It really has to > be decided on a case by case basis, so remove the examples of unacceptable > behavior, and don't attempt to define it at all. > > No one can object to the examples of positive behavior. No one can object > to a CoC that simply promotes those positive examples and then establishes > a complaint process and a CoC committee to rule on each complaint. > > martin > > ________________________________________ > From: Development > on behalf of Ulf Hermann > > Sent: Wednesday, October 24, 2018 9:17:09 AM > To: development at qt-project.org > Subject: [Development] QUIP 12: Code of Conduct > > Hi, > > regarding our earlier discussions on a possible Code of Conduct, here as > well as at the Contributors' Summit 2017, I've pushed a QUIP with the > necessary rules and definitions: > > https://codereview.qt-project.org/243623 > > Please review it. > > regards, > Ulf > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Uwe.Rathmann at tigertal.de Thu Oct 25 16:07:59 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Thu, 25 Oct 2018 14:07:59 +0000 (UTC) Subject: [Development] QUIP 12: Code of Conduct References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: On Wed, 24 Oct 2018 07:17:09 +0000, Ulf Hermann wrote: > Please review it. Qt Community, Qt Contributors, Qt Project, Qt Company - these are different things and whenever I see someone who is speaking in behalf of the Qt project I'm wondering who is actually speaking. The document already has the problem, that it seems to be legitimated by the Qt Contributor summit, what somehow implies that contributing is the criterion for having a voice in the Qt project. Furthermore you have this blurred line between the Qt project and the Qt company. IMHO a CoC for the Qt project is a chance to make things a bit clearer, by having a chapter about what type of business activities are seen as inappropriate in areas, that are owned by the Qt project. Or am I the only one who does not like being redirected to a page full of commercial content, when entering qt-project.org ? My 2 cents, Uwe From jhihn at gmx.com Thu Oct 25 16:43:53 2018 From: jhihn at gmx.com (Jason H) Date: Thu, 25 Oct 2018 16:43:53 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> <1230131540461969@iva5-750e13568e4d.qloud-c.yandex.net> Message-ID: Consolidated reply to multiple threads: Mitch, you wrote: > To me it seems like you guys are saying: >> "I don't care if this person treats me like crap because they sure can code." > I'm happy for you if you've gotten this far in life and decided that you like being insulted in exchange for someone reviewing your code (or even just asking a question on IRC), but personally I do not like it. I'm more than capable of standing up for myself, but other people who feel the same way may not feel comfortable speaking out. I do not want to contemplate the emotional state of being of the author when reviewing and leaving comments on gerrit. Many times when I an giving technical feedback, I have been told "[I] sound harsh." I'm just being factual. I never call into the matter anything about the person, but some people still do get butt-hurt when you talk about their code negatively because it is their art. They then can project that criticism of the code onto themself. This is nothing I want to be in the position of being responsible for. As long as my comments are accurate and not unduly harsh, they are (or at least should be deemed) appropriate. Next, we have the notion that the CoC was somehow agreed to at the Contributors summit. This is not a just action, as the summit was for the privileged few who had: 1) funding and 2) the allowable time away from work and life to attend 3) to the location of the event. Not everyone has a passport and is able to obtain a visa. As a member who wanted to attend but was not able to, I find the legitimacy of the vote questionable. I call for a vote (use gerrit?) on a measure to adopt a Code of Conduct, then if that passes, we can go on to debate what should be in it. Next there is a notion of the CoC being applied to profanity. I am also against this. This would violate my right to free speech, and it would be so vague to be unenforceable. So far in this thread I've used the terms "shit-show" (I contemplated more severe terms, but decided against it) and "butt-hurt". These terms were appropriate to convey the meaning intended. Similarly, I have been following the idea of Political Correctness and if it is even effective. We've had 20 years and it looks like it does not work, and overall isn't appreciated. Even if we could agree on what is offensive it would vary across populations and people would still be offended unless the most neutered language was used. Volker, You say your KDE CoC has "worked", but your KDE fellow demonstrated that in fact, it has not. From edward.welbourne at qt.io Thu Oct 25 17:13:22 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 25 Oct 2018 15:13:22 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> <1230131540461969@iva5-750e13568e4d.qloud-c.yandex.net> , Message-ID: Jason H (25 October 2018 16:43) contributed: Mitch, you wrote: >> To me it seems like you guys are saying: >>> "I don't care if this person treats me like crap because they sure >>> can code." >> I'm happy for you if you've gotten this far in life and decided that >> you like being insulted in exchange for someone reviewing your code >> (or even just asking a question on IRC), but personally I do not like >> it. I'm more than capable of standing up for myself, but other people >> who feel the same way may not feel comfortable speaking out. > I do not want to contemplate the emotional state of being of the > author when reviewing and leaving comments on gerrit. I do want to encourage you to think about how you phrase your criticisms of others' code; in particular, by "contemplating the emotional state of" an author being so criticised (this is what empathy is about). > Many times when I an giving technical feedback, I have been told "[I] > sound harsh." I'm just being factual. Two ways of saying the same thing may have identical information content (i.e. they're both "just being factual"), yet have different emotional content. One does not have to bend over backwards to treat folk gently: it is enough to just think about the ways of phrasing your feed-back that respectfully invite them to notice their error rather than just telling them they're wrong. With practice, it comes quite naturally to think in terms of "what can I say that will give this person the same understanding I have" rather than just proving that you know better than them. > I never call into the matter anything about the person, There are more ways to wind people up than direct ad hominem attacks. Phrasing may hint that you think no-one but an idiot would fail to notice the thing you happen to know, that they don't. You might not even intend that hint, but it may yet come across. In particular, if you *do* think that only an idiot would fail to see what you're pointing out, please pause to remember that contributors to Qt seldom actually are idiots and think about what might lead a perfectly reasonable and smart person to be unaware of the thing you are so familiar with that you take it for granted. > but some people still do get butt-hurt when you talk about their code > negatively because it is their art. They then can project that > criticism of the code onto themself. This is nothing I want to be in > the position of being responsible for. As long as my comments are > accurate and not unduly harsh, they are (or at least should be deemed) > appropriate. Leaving aside whether this should or shouldn't be covered by a code of conduct, that is an attitude I feel I have a duty to challenge. I am quite capable of forgetting that others can't keep up with some of what comes easily to me; and I have had decades of colleagues calmly pointing out to me that perhaps what's obvious to me might not be known by everyone else. Eventually I learned to stop and think about whether what was obvious to me was, in fact, obvious to everyone else. It turns out that, with the vast breadth and complexity of the world of software, that there are many of us who are used to taking for granted things that others don't know about; and, unless we stop to remind ourselves that those we're talking to might be less familiar with the matter, we end up being quite rude without even thinking about it. It is, indeed, the not thinking about it that *is* rude. I was annoyingly pedantic until I learned that, in fact, communication is at least as much (and, when done competently, more) about the other person's understanding than mine. > Next, we have the notion that the CoC was somehow agreed to at the > Contributors summit. Well, those at that meeting in the CS agreed to move forward with it. Ulf has, quite properly, done their bidding. He has also, quite properly, publicised this on the list *precisely* so that those who can't make it to Contributors summits, or at least missed that one, or were in one of the other parallel sessions at the time, have the chance to express their views on the matter. If nothing else, those who chose to attend that particular session, even among those at the CS, shall have been to some degree self-selecting as a group more likely to favour a CoC. So please don't interpret this as a steam-rolling of a CoC regardless of what folk want: it's the next step in a process started by some folk who did call for it; at this step, we get to see how the rest of the community feels about it, Eddy. From thiago.macieira at intel.com Thu Oct 25 17:36:32 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 25 Oct 2018 08:36:32 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> Message-ID: <1570316.fforNTilvb@tjmaciei-mobl1> On Thursday, 25 October 2018 03:00:44 PDT NIkolai Marchenko wrote: > > And btw, we have had a clear majority in favour of adding a CoC at the > > Contributor Summit > > It seems very wrong to make such decisions at conventions where only a > small part of the contributors can participate. > Especially for something as big and divisive That's why the QtCS consensus are not decisions of the Qt Project. The decision is left to the mailing list. It is a good indication of support, however. The instruction that came out of it was to write the text so the decision could be made. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From volker.hilsheimer at qt.io Thu Oct 25 17:38:43 2018 From: volker.hilsheimer at qt.io (Volker Hilsheimer) Date: Thu, 25 Oct 2018 15:38:43 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> <1230131540461969@iva5-750e13568e4d.qloud-c.yandex.net> Message-ID: <9AE0CFC6-1A34-41D0-B97C-C0BF196BA5F1@qt.io> > On 25 Oct 2018, at 16:43, Jason H wrote: > Next there is a notion of the CoC being applied to profanity. I am also against this. This would violate my right to free speech, and it would be so vague to be unenforceable. Oh dear. With your "right to free speech" you probably refer to the first amendment of the United States Constitution. "Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances." The Qt Community is not the US Congress (sadly, perhaps) or some instituation legimized by the US Congress. We can therefore not “violate your right to free speech”. Also, the right to free speech does not imply an obligation for any- or everyone to listen to your speech, no matter the opinions or density of profanities. A community of people can not only decide not to listen, it can also easily restrict your freedom of speech. Volker From kshegunov at gmail.com Thu Oct 25 18:02:56 2018 From: kshegunov at gmail.com (Konstantin Shegunov) Date: Thu, 25 Oct 2018 19:02:56 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <4449a09b-ce0b-f6a8-05bc-3299ddd5e542@gmail.com> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <4449a09b-ce0b-f6a8-05bc-3299ddd5e542@gmail.com> Message-ID: On Thu, Oct 25, 2018 at 1:01 PM Lorn Potter wrote: > Those do not mean the same as 'empathy', which is the "ability to > understand and share the feelings of another", or "put yourself in the > other persons shoes" > > I think empathy is a fine word for this, there is nothing vague about it. > Okay, let me rephrase then. Is empathy required or needed? If it's neither required nor needed, then I see no point in even mentioning it. It'd be one of those pointless redundancies and empty platitudes people seem to be so fond of these days. More to the point, is me feeling like crap, because you're feeling under the blues improve your code, or your perception of the community? I'd have hard time believing it. I'd much rather see people do right (and you can codify that) by other people than to mess with the psychobabble. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhihn at gmx.com Thu Oct 25 18:48:21 2018 From: jhihn at gmx.com (Jason H) Date: Thu, 25 Oct 2018 18:48:21 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> <1230131540461969@iva5-750e13568e4d.qloud-c.yandex.net> Message-ID: > Sent: Thursday, October 25, 2018 at 11:13 AM > From: "Edward Welbourne" > To: "Jason H" , "Mitch Curtis" > Cc: "Qt development mailing list" > Subject: Re: [Development] QUIP 12: Code of Conduct > > Jason H (25 October 2018 16:43) contributed: > > Mitch, you wrote: > >> To me it seems like you guys are saying: > > >>> "I don't care if this person treats me like crap because they sure > >>> can code." > > >> I'm happy for you if you've gotten this far in life and decided that > >> you like being insulted in exchange for someone reviewing your code > >> (or even just asking a question on IRC), but personally I do not like > >> it. I'm more than capable of standing up for myself, but other people > >> who feel the same way may not feel comfortable speaking out. > > > I do not want to contemplate the emotional state of being of the > > author when reviewing and leaving comments on gerrit. > > I do want to encourage you to think about how you phrase your criticisms > of others' code; in particular, by "contemplating the emotional state > of" an author being so criticised (this is what empathy is about). > > > Many times when I an giving technical feedback, I have been told "[I] > > sound harsh." I'm just being factual. > > Two ways of saying the same thing may have identical information content > (i.e. they're both "just being factual"), yet have different emotional > content. One does not have to bend over backwards to treat folk gently: > it is enough to just think about the ways of phrasing your feed-back > that respectfully invite them to notice their error rather than just > telling them they're wrong. With practice, it comes quite naturally to > think in terms of "what can I say that will give this person the same > understanding I have" rather than just proving that you know better than > them. > > > I never call into the matter anything about the person, > > There are more ways to wind people up than direct ad hominem attacks. > Phrasing may hint that you think no-one but an idiot would fail to > notice the thing you happen to know, that they don't. You might not > even intend that hint, but it may yet come across. In particular, if > you *do* think that only an idiot would fail to see what you're pointing > out, please pause to remember that contributors to Qt seldom actually > are idiots and think about what might lead a perfectly reasonable and > smart person to be unaware of the thing you are so familiar with that > you take it for granted. As a personal strategy I completely agree with you. However I've been at this for 20 years and it's not anything I've made significant progress on. I do not want to offend anyone, though I'm sure I have, inadvertently. I give you my word that I'm not going to verbally abuse anyone. I am continually humbled by the people in this community. They are brilliant. I often learn from being wrong on this and the other Qt lists, so I recognise this community has people of all different levels of ability. I still do however take issue with the idea that I am somehow responsible for someone's reaction to a factual observation or suggestion. It creates a slippery slope of judgement, and it creates a concern that maybe I'll be approached and be told to use kinder words, even when no unkind or inaccurate terms were used. I do however recognize that oser-use of violent profanity could turn people away. I do not know how to strike a balance. This is why I prefer to keep it all about the code. > > but some people still do get butt-hurt when you talk about their code > > negatively because it is their art. They then can project that > > criticism of the code onto themself. This is nothing I want to be in > > the position of being responsible for. As long as my comments are > > accurate and not unduly harsh, they are (or at least should be deemed) > > appropriate. > > Leaving aside whether this should or shouldn't be covered by a code of > conduct, that is an attitude I feel I have a duty to challenge. I am > quite capable of forgetting that others can't keep up with some of what > comes easily to me; and I have had decades of colleagues calmly pointing > out to me that perhaps what's obvious to me might not be known by > everyone else. Eventually I learned to stop and think about whether > what was obvious to me was, in fact, obvious to everyone else. It turns > out that, with the vast breadth and complexity of the world of software, > that there are many of us who are used to taking for granted things that > others don't know about; and, unless we stop to remind ourselves that > those we're talking to might be less familiar with the matter, we end up > being quite rude without even thinking about it. It is, indeed, the not > thinking about it that *is* rude. > > I was annoyingly pedantic until I learned that, in fact, communication > is at least as much (and, when done competently, more) about the other > person's understanding than mine. I would argue that taking criticism about code is a skill that *MUST* be learned for every developer. Giving effective criticism is also a skill to be learned by every developer, and is just a good life skill in general. How do we split the difference? Or, how we determine who is inappropriately offended? Likely when such situations occur it'll be split blame, because the reviewer *could* have used better language. But then you're effectively condoning the lack of skill in taking criticism. Can criticism be too harsh, surely. But it gets us onto a slippery slope and I prefer 1s and 0s. > > Next, we have the notion that the CoC was somehow agreed to at the > > Contributors summit. > > Well, those at that meeting in the CS agreed to move forward with it. > Ulf has, quite properly, done their bidding. He has also, quite properly, > publicised this on the list *precisely* so that those who can't make it > to Contributors summits, or at least missed that one, or were in one of > the other parallel sessions at the time, have the chance to express their > views on the matter. If nothing else, those who chose to attend that > particular session, even among those at the CS, shall have been to some > degree self-selecting as a group more likely to favour a CoC. > > So please don't interpret this as a steam-rolling of a CoC regardless of > what folk want: it's the next step in a process started by some folk who > did call for it; at this step, we get to see how the rest of the > community feels about it, I have no beef with Ulf, or anyone who wants a CoC. Clearly, he doing his duty. I do feel steam rolled as this was never put to the community at large and those in attendance were not duly elected representatives. It feels steamroller-ish because it seems like it's a foregone conclusion that we'll have one. Until you mentioned it just now I thought that ship had sailed. Why work on wording of it's not even a thing to happen? The cart is before the horse. The process should go[/have gone] like this: 1. At Summit, take a vote if this is something to be raised to the larger community. 2. Have the larger community vote on it using general terms as to what the goal would be, what it would contain. 3. If that passes move to specific phrasing. I am not against adopting measures to ensure that people who are abusive can be removed. As a matter of fact last night I was looking at stuff on community engagement that having a moderation is a good thing, but not entirely effective. In fact to break it down: rumination is .43** correlated with withdraw, moderator intervention is -.13** correlated with withdraw; ** p < .005. Here, rumination is 3 times more likely to produce withdraw than having a moderator. But still, I think it's good thing to document what abuses, if any, will get you removed from the community and how that process works. Such agreements would have to be shown as a click-through when joining a Qt property (mailing list, jira, gerrit, etc.) I'm still against it in general because it introduces slippery slopes and politics. In order for me to consider endorsing any such community conduct standards, it would have to have the following features: 1. No consideration given for off-Qt property actions. (social media sites, email, etc) 2. A non-standing Committee that exists for specific incidents, who 2a. members are chosen at random for each incident 2b. can somehow guarantee the confidentiality of evidence and proceedings, to protect the accuser and accused. 3. Limits slippery slope aspects the fewest possible aspects, and when on a slippery slope aspect, constrains them to their most boolean limits, construed in favor of the accused. Anything more will itself be a vehicle for abuse. I really, really hate that we've brought politics into this community. Likely, your opinions of me have changed. I just wanted my presence here to be about Qt. But now I've had to reveal my politics which will open me to judgements not related to my technological contributions. I realize the initial vote occured before that whole Linux ordeal started, I hope we can learn from what is currently playing out with Linux and avoid that. From jhihn at gmx.com Thu Oct 25 19:12:00 2018 From: jhihn at gmx.com (Jason H) Date: Thu, 25 Oct 2018 19:12:00 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <9AE0CFC6-1A34-41D0-B97C-C0BF196BA5F1@qt.io> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> <1230131540461969@iva5-750e13568e4d.qloud-c.yandex.net> <9AE0CFC6-1A34-41D0-B97C-C0BF196BA5F1@qt.io> Message-ID: > Sent: Thursday, October 25, 2018 at 11:38 AM > From: "Volker Hilsheimer" > To: "Jason H" , "Qt development mailing list" > Cc: "Mitch Curtis" > Subject: Re: [Development] QUIP 12: Code of Conduct > > > On 25 Oct 2018, at 16:43, Jason H wrote: > > Next there is a notion of the CoC being applied to profanity. I am also against this. This would violate my right to free speech, and it would be so vague to be unenforceable. > > > Oh dear. > > With your "right to free speech" you probably refer to the first amendment of the United States Constitution. > > "Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances." > > The Qt Community is not the US Congress (sadly, perhaps) or some instituation legimized by the US Congress. We can therefore not “violate your right to free speech”. Also, the right to free speech does not imply an obligation for any- or everyone to listen to your speech, no matter the opinions or density of profanities. > > A community of people can not only decide not to listen, it can also easily restrict your freedom of speech. Well, you have people of various legal jurisdictions that have differing ideas on what they are allowed to say. Even the US constitution does not grant the right to yell "Fire!" in a crowded theater. However being of such a jurisdiction I am accustomed to having responsible speech being permitted. You are correct that no one has to listen, but I have the right to express it. The concern that I have is if certain measures are enacted, I will lose my ability to "speak" because someone was offended. It's a slippery slope I'd rather not contend with. There are two ways to resolve this: either 1) Do not consider it, or 2) Define in excruciating detail, as to remove the "slippery" from the slope. From Martin.Smith at qt.io Thu Oct 25 19:19:18 2018 From: Martin.Smith at qt.io (Martin Smith) Date: Thu, 25 Oct 2018 17:19:18 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> <1230131540461969@iva5-750e13568e4d.qloud-c.yandex.net> <9AE0CFC6-1A34-41D0-B97C-C0BF196BA5F1@qt.io>, Message-ID: >There are two ways to resolve this: either >1) Do not consider it, or >2) Define in excruciating detail, as to remove the "slippery" from the slope. There is a 3rd way: 3) Don't define it because you already know what it is. Just explain the comp[laint process and create the committee to deal with each complaint on a case by case basis. ________________________________________ From: Development on behalf of Jason H Sent: Thursday, October 25, 2018 7:12:00 PM To: Volker Hilsheimer Cc: Qt development mailing list Subject: Re: [Development] QUIP 12: Code of Conduct > Sent: Thursday, October 25, 2018 at 11:38 AM > From: "Volker Hilsheimer" > To: "Jason H" , "Qt development mailing list" > Cc: "Mitch Curtis" > Subject: Re: [Development] QUIP 12: Code of Conduct > > > On 25 Oct 2018, at 16:43, Jason H wrote: > > Next there is a notion of the CoC being applied to profanity. I am also against this. This would violate my right to free speech, and it would be so vague to be unenforceable. > > > Oh dear. > > With your "right to free speech" you probably refer to the first amendment of the United States Constitution. > > "Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances." > > The Qt Community is not the US Congress (sadly, perhaps) or some instituation legimized by the US Congress. We can therefore not “violate your right to free speech”. Also, the right to free speech does not imply an obligation for any- or everyone to listen to your speech, no matter the opinions or density of profanities. > > A community of people can not only decide not to listen, it can also easily restrict your freedom of speech. Well, you have people of various legal jurisdictions that have differing ideas on what they are allowed to say. Even the US constitution does not grant the right to yell "Fire!" in a crowded theater. However being of such a jurisdiction I am accustomed to having responsible speech being permitted. You are correct that no one has to listen, but I have the right to express it. The concern that I have is if certain measures are enacted, I will lose my ability to "speak" because someone was offended. It's a slippery slope I'd rather not contend with. There are two ways to resolve this: either 1) Do not consider it, or 2) Define in excruciating detail, as to remove the "slippery" from the slope. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From apoenitz at t-online.de Thu Oct 25 19:39:45 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 25 Oct 2018 19:39:45 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2539432.vSGsD3zg6Y@vkpc19> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> Message-ID: <20181025173945.GA16670@klara.mpi.htwm.de> On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via Development wrote: > We do have a Code of Conduct at KDE for about 10 years now, and this hasn't > led to abuse of power, suppression of free speech, racism against white people > or whatever other nonsense people seem to attribute to CoCs nowadays. The KDE CoC is *friendly*. It contains words like "considerate", "pragmatic", "support". It doesn't push someone's personal political agenda. This is a completely different beast than the Contributor Covenant that's about "enforcing", "reporting", "banning". I think we'd see much less heat in the discussion if the proposed Qt CoC had been based on the KDE CoC. Andre' From yetanotherandreyev at gmail.com Thu Oct 25 19:48:19 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Thu, 25 Oct 2018 20:48:19 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> <1230131540461969@iva5-750e13568e4d.qloud-c.yandex.net> <9AE0CFC6-1A34-41D0-B97C-C0BF196BA5F1@qt.io> Message-ID: > Don't define it because you already know what it is. Just explain the complaint process and create the committee to deal with each complaint on a case by case basis. It could make sense, but then we should made a plan how the committee could work and how many resources could it take. Should it be the committee from professional developers? How many hours are they ready to spend for complaints comparing to other tasks? чт, 25 окт. 2018 г. в 20:19, Martin Smith : > >There are two ways to resolve this: either > >1) Do not consider it, or > >2) Define in excruciating detail, as to remove the "slippery" from the > slope. > > There is a 3rd way: > 3) Don't define it because you already know what it is. Just explain the > comp[laint process and create the committee to deal with each complaint on > a case by case basis. > > ________________________________________ > From: Development > on behalf of Jason H > Sent: Thursday, October 25, 2018 7:12:00 PM > To: Volker Hilsheimer > Cc: Qt development mailing list > Subject: Re: [Development] QUIP 12: Code of Conduct > > > > > Sent: Thursday, October 25, 2018 at 11:38 AM > > From: "Volker Hilsheimer" > > To: "Jason H" , "Qt development mailing list" < > development at qt-project.org> > > Cc: "Mitch Curtis" > > Subject: Re: [Development] QUIP 12: Code of Conduct > > > > > On 25 Oct 2018, at 16:43, Jason H wrote: > > > Next there is a notion of the CoC being applied to profanity. I am > also against this. This would violate my right to free speech, and it would > be so vague to be unenforceable. > > > > > > Oh dear. > > > > With your "right to free speech" you probably refer to the first > amendment of the United States Constitution. > > > > "Congress shall make no law respecting an establishment of religion, or > prohibiting the free exercise thereof; or abridging the freedom of speech, > or of the press; or the right of the people peaceably to assemble, and to > petition the Government for a redress of grievances." > > > > The Qt Community is not the US Congress (sadly, perhaps) or some > instituation legimized by the US Congress. We can therefore not “violate > your right to free speech”. Also, the right to free speech does not imply > an obligation for any- or everyone to listen to your speech, no matter the > opinions or density of profanities. > > > > A community of people can not only decide not to listen, it can also > easily restrict your freedom of speech. > > Well, you have people of various legal jurisdictions that have differing > ideas on what they are allowed to say. Even the US constitution does not > grant the right to yell "Fire!" in a crowded theater. However being of such > a jurisdiction I am accustomed to having responsible speech being > permitted. You are correct that no one has to listen, but I have the right > to express it. The concern that I have is if certain measures are enacted, > I will lose my ability to "speak" because someone was offended. It's a > slippery slope I'd rather not contend with. There are two ways to resolve > this: either > 1) Do not consider it, or > 2) Define in excruciating detail, as to remove the "slippery" from the > slope. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yetanotherandreyev at gmail.com Thu Oct 25 19:57:30 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Thu, 25 Oct 2018 20:57:30 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> <1230131540461969@iva5-750e13568e4d.qloud-c.yandex.net> <9AE0CFC6-1A34-41D0-B97C-C0BF196BA5F1@qt.io> Message-ID: I want to thank everyone who's spending their time trying to solve the raised questions. One more point I want to mention since we are collecting community feedback. Feel free to call me stupid and skip until the end. I'm pondering about ideas that controvertial CoC is appeared as some regular result of fight for profit, power and expantion between successful open communities and regular companies. And it's not about some specific persons or their characteristics at all. It looks like an attack on open communities and their values. I'm not talking about some conspiracy here, I'm talking that it's probably natural proccess, similar to non-IT historical situations around the world. Since open IT communities right now are successful enough to compete with regular "closed" communities, we are observing injecting some opposite ideas via CoC to "seduce" open communities and destroy them from inside and then outside. Like, yes, of cource we have conflicts! People are not social angels. But we had a much less of them right now comparing to some bad examples of ineffective companies (with similar size of tasks) with fancy rules and smiles imitation. Who said that there's any chances to minimize conflicts more with CoC? Where is professional scientific research that Qt community or Linux or KDE is slowly dying without CoC? I'm afraid that research could probably show the opposite. чт, 25 окт. 2018 г. в 20:48, Alexey Andreyev : > > Don't define it because you already know what it is. Just explain the > complaint process and create the committee to deal with each complaint on a > case by case basis. > It could make sense, but then we should made a plan how the committee > could work and how many resources could it take. > Should it be the committee from professional developers? How many hours > are they ready to spend for complaints comparing to other tasks? > > чт, 25 окт. 2018 г. в 20:19, Martin Smith : > >> >There are two ways to resolve this: either >> >1) Do not consider it, or >> >2) Define in excruciating detail, as to remove the "slippery" from the >> slope. >> >> There is a 3rd way: >> 3) Don't define it because you already know what it is. Just explain the >> comp[laint process and create the committee to deal with each complaint on >> a case by case basis. >> >> ________________________________________ >> From: Development >> on behalf of Jason H >> Sent: Thursday, October 25, 2018 7:12:00 PM >> To: Volker Hilsheimer >> Cc: Qt development mailing list >> Subject: Re: [Development] QUIP 12: Code of Conduct >> >> >> >> > Sent: Thursday, October 25, 2018 at 11:38 AM >> > From: "Volker Hilsheimer" >> > To: "Jason H" , "Qt development mailing list" < >> development at qt-project.org> >> > Cc: "Mitch Curtis" >> > Subject: Re: [Development] QUIP 12: Code of Conduct >> > >> > > On 25 Oct 2018, at 16:43, Jason H wrote: >> > > Next there is a notion of the CoC being applied to profanity. I am >> also against this. This would violate my right to free speech, and it would >> be so vague to be unenforceable. >> > >> > >> > Oh dear. >> > >> > With your "right to free speech" you probably refer to the first >> amendment of the United States Constitution. >> > >> > "Congress shall make no law respecting an establishment of religion, or >> prohibiting the free exercise thereof; or abridging the freedom of speech, >> or of the press; or the right of the people peaceably to assemble, and to >> petition the Government for a redress of grievances." >> > >> > The Qt Community is not the US Congress (sadly, perhaps) or some >> instituation legimized by the US Congress. We can therefore not “violate >> your right to free speech”. Also, the right to free speech does not imply >> an obligation for any- or everyone to listen to your speech, no matter the >> opinions or density of profanities. >> > >> > A community of people can not only decide not to listen, it can also >> easily restrict your freedom of speech. >> >> Well, you have people of various legal jurisdictions that have differing >> ideas on what they are allowed to say. Even the US constitution does not >> grant the right to yell "Fire!" in a crowded theater. However being of such >> a jurisdiction I am accustomed to having responsible speech being >> permitted. You are correct that no one has to listen, but I have the right >> to express it. The concern that I have is if certain measures are enacted, >> I will lose my ability to "speak" because someone was offended. It's a >> slippery slope I'd rather not contend with. There are two ways to resolve >> this: either >> 1) Do not consider it, or >> 2) Define in excruciating detail, as to remove the "slippery" from the >> slope. >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Oct 25 19:55:41 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 25 Oct 2018 10:55:41 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: <2367500.a6nhEUcpS0@tjmaciei-mobl1> On Thursday, 25 October 2018 03:05:04 PDT Robert Loehning wrote: > Am 25.10.2018 um 09:58 schrieb Lars Knoll: > > And btw, we have had a clear majority in favour of adding a CoC at the > > Contributor Summit, and explicitly agreed that a group of people will > > work on creating it. I’m happy we now have a first version, that we can > > use as a basis for further discussions. > Hi all, > > to be precise: We had a clear majority of the people who voted in this > session. This might or might not correlate with a majority of the > project's members. Let me just be clear: this was not a vote. It was a straw poll, to gather the attendees' opinion. The Qt Project has no voting. All decisions are made by consensus wherever possible, and failing to achieve that, we have an escalation route all the way to the Chief Maintainer. Please note point 3 of RFC 7282[1], which describes IETF's Consensus mechanism: Rough consensus is achieved when all issues are addressed, but not necessarily accommodated [1] https://tools.ietf.org/html/rfc7282 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Martin.Smith at qt.io Thu Oct 25 19:58:18 2018 From: Martin.Smith at qt.io (Martin Smith) Date: Thu, 25 Oct 2018 17:58:18 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <05914bcb-5cd6-cd62-843b-6fb48a5280d5@roquetto.com> <1230131540461969@iva5-750e13568e4d.qloud-c.yandex.net> <9AE0CFC6-1A34-41D0-B97C-C0BF196BA5F1@qt.io> , Message-ID: >Should it be the committee from professional developers? Volunteers >How many hours are they ready to spend for complaints comparing to other tasks? I don't think there will be many complaints. That's the main point of having a CoC. It reminds posters to be civil. When there is a complaint, it is sent to each member of the committee. They read it and agree whether it requires a response. If so, post a reminder of the CoC in the location where the alleged offense occurred. ________________________________________ From: Alexey Andreyev Sent: Thursday, October 25, 2018 7:48:19 PM To: Martin Smith Cc: jhihn at gmx.com; Volker Hilsheimer; Qt development mailing list Subject: Re: [Development] QUIP 12: Code of Conduct > Don't define it because you already know what it is. Just explain the complaint process and create the committee to deal with each complaint on a case by case basis. It could make sense, but then we should made a plan how the committee could work and how many resources could it take. Should it be the committee from professional developers? How many hours are they ready to spend for complaints comparing to other tasks? чт, 25 окт. 2018 г. в 20:19, Martin Smith >: >There are two ways to resolve this: either >1) Do not consider it, or >2) Define in excruciating detail, as to remove the "slippery" from the slope. There is a 3rd way: 3) Don't define it because you already know what it is. Just explain the comp[laint process and create the committee to deal with each complaint on a case by case basis. ________________________________________ From: Development > on behalf of Jason H > Sent: Thursday, October 25, 2018 7:12:00 PM To: Volker Hilsheimer Cc: Qt development mailing list Subject: Re: [Development] QUIP 12: Code of Conduct > Sent: Thursday, October 25, 2018 at 11:38 AM > From: "Volker Hilsheimer" > > To: "Jason H" >, "Qt development mailing list" > > Cc: "Mitch Curtis" > > Subject: Re: [Development] QUIP 12: Code of Conduct > > > On 25 Oct 2018, at 16:43, Jason H > wrote: > > Next there is a notion of the CoC being applied to profanity. I am also against this. This would violate my right to free speech, and it would be so vague to be unenforceable. > > > Oh dear. > > With your "right to free speech" you probably refer to the first amendment of the United States Constitution. > > "Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances." > > The Qt Community is not the US Congress (sadly, perhaps) or some instituation legimized by the US Congress. We can therefore not “violate your right to free speech”. Also, the right to free speech does not imply an obligation for any- or everyone to listen to your speech, no matter the opinions or density of profanities. > > A community of people can not only decide not to listen, it can also easily restrict your freedom of speech. Well, you have people of various legal jurisdictions that have differing ideas on what they are allowed to say. Even the US constitution does not grant the right to yell "Fire!" in a crowded theater. However being of such a jurisdiction I am accustomed to having responsible speech being permitted. You are correct that no one has to listen, but I have the right to express it. The concern that I have is if certain measures are enacted, I will lose my ability to "speak" because someone was offended. It's a slippery slope I'd rather not contend with. There are two ways to resolve this: either 1) Do not consider it, or 2) Define in excruciating detail, as to remove the "slippery" from the slope. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From annulen at yandex.ru Thu Oct 25 20:03:12 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 25 Oct 2018 21:03:12 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2367500.a6nhEUcpS0@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <2367500.a6nhEUcpS0@tjmaciei-mobl1> Message-ID: <8096751540490592@iva7-d29a8296bc3c.qloud-c.yandex.net> 25.10.2018, 20:56, "Thiago Macieira" : > The Qt Project has no voting. Nitpick: there is voting in privilege revocation procedure. -- Regards, Konstantin From thiago.macieira at intel.com Thu Oct 25 20:04:43 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 25 Oct 2018 11:04:43 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <9AE0CFC6-1A34-41D0-B97C-C0BF196BA5F1@qt.io> Message-ID: <2785455.RZFegi9tI1@tjmaciei-mobl1> On Thursday, 25 October 2018 10:12:00 PDT Jason H wrote: > Well, you have people of various legal jurisdictions that have differing > ideas on what they are allowed to say. Even the US constitution does not > grant the right to yell "Fire!" in a crowded theater. However being of such > a jurisdiction I am accustomed to having responsible speech being > permitted. You are correct that no one has to listen, but I have the right > to express it. You have the right to express it, but that does not imply the Qt Project has the obligation to convey it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From laszlo.agocs at qt.io Thu Oct 25 20:05:21 2018 From: laszlo.agocs at qt.io (Laszlo Agocs) Date: Thu, 25 Oct 2018 18:05:21 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <20181025173945.GA16670@klara.mpi.htwm.de> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19>, <20181025173945.GA16670@klara.mpi.htwm.de> Message-ID: Fully agree. Is it really necessary to dedicate ca. half of the proposed document to sections full of "enforcement", "ban", "violation", "danger", etc., which in the end leads to creating an overly dark and bureaucratic vibe? Laszlo ________________________________ From: Development on behalf of André Pönitz Sent: Thursday, October 25, 2018 7:39 PM To: Volker Krause Cc: development at qt-project.org Subject: Re: [Development] QUIP 12: Code of Conduct On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via Development wrote: > We do have a Code of Conduct at KDE for about 10 years now, and this hasn't > led to abuse of power, suppression of free speech, racism against white people > or whatever other nonsense people seem to attribute to CoCs nowadays. The KDE CoC is *friendly*. It contains words like "considerate", "pragmatic", "support". It doesn't push someone's personal political agenda. This is a completely different beast than the Contributor Covenant that's about "enforcing", "reporting", "banning". I think we'd see much less heat in the discussion if the proposed Qt CoC had been based on the KDE CoC. Andre' _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhihn at gmx.com Thu Oct 25 21:14:47 2018 From: jhihn at gmx.com (Jason H) Date: Thu, 25 Oct 2018 21:14:47 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <20181025173945.GA16670@klara.mpi.htwm.de> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <20181025173945.GA16670@klara.mpi.htwm.de> Message-ID: +1 this. I have no problems with the KDE CoC. > Sent: Thursday, October 25, 2018 at 1:39 PM > From: "André Pönitz" > To: "Volker Krause" > Cc: development at qt-project.org > Subject: Re: [Development] QUIP 12: Code of Conduct > > On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via Development wrote: > > We do have a Code of Conduct at KDE for about 10 years now, and this hasn't > > led to abuse of power, suppression of free speech, racism against white people > > or whatever other nonsense people seem to attribute to CoCs nowadays. > > The KDE CoC is *friendly*. It contains words like "considerate", "pragmatic", > "support". It doesn't push someone's personal political agenda. This is a > completely different beast than the Contributor Covenant that's about > "enforcing", "reporting", "banning". > > I think we'd see much less heat in the discussion if the proposed Qt CoC had > been based on the KDE CoC. > > Andre' > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From kshegunov at gmail.com Thu Oct 25 21:52:14 2018 From: kshegunov at gmail.com (Konstantin Shegunov) Date: Thu, 25 Oct 2018 22:52:14 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <20181025173945.GA16670@klara.mpi.htwm.de> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <20181025173945.GA16670@klara.mpi.htwm.de> Message-ID: +1 for the KDE CoC from me as well. Better written, clearer and to the point. On Thu, Oct 25, 2018 at 8:40 PM André Pönitz wrote: > On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via Development > wrote: > > We do have a Code of Conduct at KDE for about 10 years now, and this > hasn't > > led to abuse of power, suppression of free speech, racism against white > people > > or whatever other nonsense people seem to attribute to CoCs nowadays. > > The KDE CoC is *friendly*. It contains words like "considerate", > "pragmatic", > "support". It doesn't push someone's personal political agenda. This is a > completely different beast than the Contributor Covenant that's about > "enforcing", "reporting", "banning". > > I think we'd see much less heat in the discussion if the proposed Qt CoC > had > been based on the KDE CoC. > > Andre' > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Oct 26 07:14:44 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 25 Oct 2018 22:14:44 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: <4145998.dxsAPVRcBo@tjmaciei-mobl1> On Wednesday, 24 October 2018 00:17:09 PDT Ulf Hermann wrote: > Hi, > > regarding our earlier discussions on a possible Code of Conduct, here as > well as at the Contributors' Summit 2017, I've pushed a QUIP with the > necessary rules and definitions: > > https://codereview.qt-project.org/243623 Hello Ulf and everyone else on this thread I've posted a few comments here and there relating to the process of adopting anything in our community, but I haven't yet voiced my opinion on this subject. This email is it. Note that even though I am speaking for myself, I understand my opinion reflects on my employer. So I want to say this first: Intel does support Open Source Projects adopting Code of Conduct as well as actions leading to increasing access and diversity of ideas, hopefully leading to improved code. We also particularly like the Contributor Covenant text. I am also personally in favour of adopting a CoC and I support adopting either the Covenant text or KDE's. Both are fine to me. Another good one is Mozilla's[1], which the SQLite developers have just adopted too. In fact, I was there 10 years ago when KDE decided to adopt something. Back then, I was also of the opinion that we shouldn't need anything. The KDE community had always been a welcoming one: in my first Akademy, I was greeted by people I had only met online as an old friend. Moreover, the KDE community had always resisted any kind of formal structuring of anything, which led to the Technical Working Group being created and disbanding in 2006. Even today, the KDE e.V. takes great steps to make sure it is never seen as a ruling body. But the CoC was adopted, with no ill effects. I do not have direct knowledge of where they had to intervene, if at all, but I'm told it has happened. More importantly, I have also grown as a person since then. In a particularly telling moment, when a female colleague here in the office (located in a very affluent, liberal and progressive part of the US) once asked my opinion on the Python Donglegate incident and explained to me the reason why she interpreted it the way she did, I realised how my worldview was so very different from hers. I've come to understand how little things that did not bother me were highly offensive to her. I've seen basically three questions asked by the skepticals to this proposal: 1) if it ain't broke, why fix it? To put it simply: the CoC has as an objective make sure the community is always welcoming and inclusive. People have a limit on how much hostility (intended or not) they're going to put up with. If they reach that limit, they're going to simply avoid it and that can be anywhere from avoiding contributions to certain parts of the code to stopping contributing altogether (or worse). We don't want to lose them or their contributions. Think of the CoC as preventive maintenance: you don't do it because it's broken. You do it so it *won't* break in the first place. 2) why not let the code rule? Code does not exist in isolation and the Qt Project is not a set of files in Git. The Qt Project is a community that maintains that code, so we need rules beyond code. We have contributors who don't contribute a lot of code, but that does not make them any less important members of the community. Besides, any commit comes with a commit message. Any review comes with feedback and there are few that are simply "+2" with no text. We want good code, improving Qt and for that we need to interact with one another. Moreover, the major architectural issues are not discussed in code, but in prose via email. Finally, being good at C++ is not an excuse for being a jackass. No one should get a pass because they're experts at something. We can't make the cold calculus that "person X's productivity is worth 10 new contributors so we will allow X's behaviour to turn away 10 contributors". What happens on the 11th? And what if one of those turned out to be amazing after a few months? So clearly code is not enough. 3) how do we prevent ill side-effects and abuse? One ill side-effect would be the turning away of important contributors who feel that the adoption of the CoC stands in the way of their participation. But please note that has not happened to any significant manner in any of the big Open Source Projects that have adopted CoCs. That includes the Linux kernel: despite what you may have heard in the media, the kernel maintainers and Linus himself subscribe to the new CoC and Linus has returned to development. We can also work with that person to find a compromise solution. I find it hard to believe we couldn't, if that person is willing to see the other side of the coin. And I speak from experience on that. The rest should be in the CoC text itself and how it empowers the resolution committee to make its decisions as well as any checks-and-balances on the com committee itself. Specifically, the CoC should not be used to discriminate against one's political views any more than on another's sexual orientations. And what you do on your private time is your own business. [1] https://www.mozilla.org/en-US/about/governance/policies/participation/ -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From elvstone at gmail.com Fri Oct 26 08:55:09 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Fri, 26 Oct 2018 08:55:09 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <4145998.dxsAPVRcBo@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <4145998.dxsAPVRcBo@tjmaciei-mobl1> Message-ID: Even if I'm just living in the outskirts of the Qt Project (have for a long time) I just have to say I wholeheartedly agree with Thiago in his thoughts below. One comment inline below. Den fre 26 okt. 2018 07:14Thiago Macieira skrev: > On Wednesday, 24 October 2018 00:17:09 PDT Ulf Hermann wrote: > > Hi, > > > > regarding our earlier discussions on a possible Code of Conduct, here as > > well as at the Contributors' Summit 2017, I've pushed a QUIP with the > > necessary rules and definitions: > > > > https://codereview.qt-project.org/243623 > > Hello Ulf and everyone else on this thread > > I've posted a few comments here and there relating to the process of > adopting > anything in our community, but I haven't yet voiced my opinion on this > subject. This email is it. > > Note that even though I am speaking for myself, I understand my opinion > reflects on my employer. So I want to say this first: Intel does support > Open > Source Projects adopting Code of Conduct as well as actions leading to > increasing access and diversity of ideas, hopefully leading to improved > code. > We also particularly like the Contributor Covenant text. > > I am also personally in favour of adopting a CoC and I support adopting > either > the Covenant text or KDE's. Both are fine to me. Another good one is > Mozilla's[1], which the SQLite developers have just adopted too. > > In fact, I was there 10 years ago when KDE decided to adopt something. > Back > then, I was also of the opinion that we shouldn't need anything. The KDE > community had always been a welcoming one: in my first Akademy, I was > greeted > by people I had only met online as an old friend. Moreover, the KDE > community > had always resisted any kind of formal structuring of anything, which led > to > the Technical Working Group being created and disbanding in 2006. Even > today, > the KDE e.V. takes great steps to make sure it is never seen as a ruling > body. > > But the CoC was adopted, with no ill effects. I do not have direct > knowledge > of where they had to intervene, if at all, but I'm told it has happened. > More > importantly, I have also grown as a person since then. In a particularly > telling moment, when a female colleague here in the office (located in a > very > affluent, liberal and progressive part of the US) once asked my opinion on > the > Python Donglegate incident and explained to me the reason why she > interpreted > it the way she did, I realised how my worldview was so very different from > hers. I've come to understand how little things that did not bother me > were > highly offensive to her. > > I've seen basically three questions asked by the skepticals to this > proposal: > > 1) if it ain't broke, why fix it? > > To put it simply: the CoC has as an objective make sure the community is > always welcoming and inclusive. People have a limit on how much hostility > (intended or not) they're going to put up with. If they reach that limit, > they're going to simply avoid it and that can be anywhere from avoiding > contributions to certain parts of the code to stopping contributing > altogether > (or worse). We don't want to lose them or their contributions. > > Think of the CoC as preventive maintenance: you don't do it because it's > broken. You do it so it *won't* break in the first place. > > 2) why not let the code rule? > > Code does not exist in isolation and the Qt Project is not a set of files > in > Git. The Qt Project is a community that maintains that code, so we need > rules > beyond code. We have contributors who don't contribute a lot of code, but > that > does not make them any less important members of the community. > > Besides, any commit comes with a commit message. Any review comes with > feedback and there are few that are simply "+2" with no text. We want good > code, improving Qt and for that we need to interact with one another. > Absolutely. And one thing I've when doing code reviews at work is that it's _very_ effective to not only point out problem areas of where things should be done differently, but also point out parts that are particularly good, as encouragement. The reviewee will feel better, and be more productive, producing even better code. Humans are quite simple in that sense :) So it's absolutely not only about code. Elvis Moreover, the major architectural issues are not discussed in code, but in > prose via email. > > Finally, being good at C++ is not an excuse for being a jackass. No one > should > get a pass because they're experts at something. We can't make the cold > calculus that "person X's productivity is worth 10 new contributors so we > will > allow X's behaviour to turn away 10 contributors". What happens on the > 11th? > And what if one of those turned out to be amazing after a few months? > > So clearly code is not enough. > > 3) how do we prevent ill side-effects and abuse? > > One ill side-effect would be the turning away of important contributors > who > feel that the adoption of the CoC stands in the way of their > participation. > But please note that has not happened to any significant manner in any of > the > big Open Source Projects that have adopted CoCs. That includes the Linux > kernel: despite what you may have heard in the media, the kernel > maintainers > and Linus himself subscribe to the new CoC and Linus has returned to > development. > > We can also work with that person to find a compromise solution. I find it > hard to believe we couldn't, if that person is willing to see the other > side > of the coin. And I speak from experience on that. > > The rest should be in the CoC text itself and how it empowers the > resolution > committee to make its decisions as well as any checks-and-balances on the > com > committee itself. Specifically, the CoC should not be used to > discriminate > against one's political views any more than on another's sexual > orientations. > And what you do on your private time is your own business. > > [1] https://www.mozilla.org/en-US/about/governance/policies/participation/ > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Oliver.Wolff at qt.io Fri Oct 26 09:05:58 2018 From: Oliver.Wolff at qt.io (Oliver Wolff) Date: Fri, 26 Oct 2018 07:05:58 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <20181025173945.GA16670@klara.mpi.htwm.de> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <20181025173945.GA16670@klara.mpi.htwm.de> Message-ID: <4a2727e7-1f16-9341-559b-eb8a8c162415@qt.io> +1 from here as well. I also think that the proposed document (and especially the "enforcement" part) is way too long On 25/10/2018 19:39, André Pönitz wrote: > On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via Development wrote: >> We do have a Code of Conduct at KDE for about 10 years now, and this hasn't >> led to abuse of power, suppression of free speech, racism against white people >> or whatever other nonsense people seem to attribute to CoCs nowadays. > The KDE CoC is *friendly*. It contains words like "considerate", "pragmatic", > "support". It doesn't push someone's personal political agenda. This is a > completely different beast than the Contributor Covenant that's about > "enforcing", "reporting", "banning". > > I think we'd see much less heat in the discussion if the proposed Qt CoC had > been based on the KDE CoC. > > Andre' > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From ulf.hermann at qt.io Fri Oct 26 09:18:21 2018 From: ulf.hermann at qt.io (Ulf Hermann) Date: Fri, 26 Oct 2018 07:18:21 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <4a2727e7-1f16-9341-559b-eb8a8c162415@qt.io> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <20181025173945.GA16670@klara.mpi.htwm.de> <4a2727e7-1f16-9341-559b-eb8a8c162415@qt.io> Message-ID: On 10/26/18 9:05 AM, Oliver Wolff wrote: > +1 from here as well. I also think that the proposed document (and > especially the "enforcement" part) is way too long The KDE CoC [1] does not specify any action to be taken when it's violated. That's the main reason why it seems shorter. If you only consider the equivalent sections in our proposed CoC, the KDE one is actually much longer. That said, I wouldn't mind replacing the "Our Pledge" and "Our Standards" paragraphs in the current proposal with the KDE CoC if that helps with acceptance here. But, how does this actually work in practice at KDE? Is there another document that states what they do if someone oversteps the boundaries? There isn't even a contact email in their CoC. So, if someone was slapping me around with a large fish in the KDE IRC channel, I still wouldn't know what to do about it. Ulf [1] https://www.kde.org/code-of-conduct/ From yetanotherandreyev at gmail.com Fri Oct 26 09:44:57 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Fri, 26 Oct 2018 10:44:57 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <4145998.dxsAPVRcBo@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <4145998.dxsAPVRcBo@tjmaciei-mobl1> Message-ID: Hello! :) The CoC is a lie. From my point of view, some of the current intentions at least. I'm hesitating a bit, that I'm so loud. I'm doing this to prevent problems at the community, trying to find bottlenecks and provide better solution for us. > The rest should be in the CoC text itself and how it empowers the resolution committee to make its decisions as well as any checks-and-balances on the com committee itself. Specifically, the CoC should not be used to discriminate against one's political views any more than on another's sexual orientations. And what you do on your private time is your own business. I want to contribute: to accept that, we have to define "private time" meaning in a such public place as the web. Is personal blog page posting a private time? Secondly, the idea about "non-discrimination" and being free from shared political or other values (at least minimal) could be easy perverted as restriction to even talk about the defined topics. It could be used against the community false-defining some sentenses as restricted. And we have real-life examples of this. So we probably need at least minimal shared values if we are proposing some CoC, not just undefined "free from discrimination". > We can also work with that person to find a compromise solution. I find it hard to believe we couldn't, if that person is willing to see the other side of the coin. And I speak from experience on that. I agree we should work together on shared values > 3) how do we prevent ill side-effects and abuse? One ill side-effect would be the turning away of important contributors who feel that the adoption of the CoC stands in the way of their participation. But please note that has not happened to any significant manner in any of the big Open Source Projects that have adopted CoCs. That includes the Linux kernel: despite what you may have heard in the media, the kernel maintainers and Linus himself subscribe to the new CoC and Linus has returned to development. Looks like it doesn't happened yet to open source projects, yes (feel free to correct me). Just want to add that proposed CoC raised the questions at least in case of the kernel project and we should carefully research negative impact too to prevent worst results > 2) why not let the code rule? [...] So clearly code is not enough. I agree. I guess the idea why some people focusing on the code it's because the code is better defined and verifiable at least. And some people are probably searching for metrics how to check CoC is positive for community development not negative. If we don't provide well-defined document, it's probably makes no sence to include undefined with visible dangerous problems. That's why some probably prefers KDE's version more. > 1) if it ain't broke, why fix it? [...] We don't want to lose them or their contributions. Think of the CoC as preventive maintenance: you don't do it because it's broken. You do it so it *won't* break in the first place. I probably agree. And want to add we should be very careful. > But the CoC was adopted, with no ill effects. I guess global situation changed since that. And what if we compare the number of public conflicts at the world and dates when undefined rules about that was accepted at big companies? And it's not about just example with Theodore Ts'o. Look at the cinema world. We should be careful not to create rules that could be just a backdoor for external companies to force thier expansion ideas not focused on helping at all. I agree we should think about others and help each other, and could try to build shared values document. The questions is about implementation. > So I want to say this first: Intel does support Open Source Projects adopting Code of Conduct as well as actions leading to increasing access and diversity of ideas, hopefully leading to improved code. We also particularly like the Contributor Covenant text. My idea was to show that "diversity of ideas" is just yet another idea. Not all the ideas is clear and positive by default. "What's you favourite idea? Mine is to be creative..." (from "Don’t Hug Me, I’m Scared") пт, 26 окт. 2018 г., 8:15 Thiago Macieira : > On Wednesday, 24 October 2018 00:17:09 PDT Ulf Hermann wrote: > > Hi, > > > > regarding our earlier discussions on a possible Code of Conduct, here as > > well as at the Contributors' Summit 2017, I've pushed a QUIP with the > > necessary rules and definitions: > > > > https://codereview.qt-project.org/243623 > > Hello Ulf and everyone else on this thread > > I've posted a few comments here and there relating to the process of > adopting > anything in our community, but I haven't yet voiced my opinion on this > subject. This email is it. > > Note that even though I am speaking for myself, I understand my opinion > reflects on my employer. So I want to say this first: Intel does support > Open > Source Projects adopting Code of Conduct as well as actions leading to > increasing access and diversity of ideas, hopefully leading to improved > code. > We also particularly like the Contributor Covenant text. > > I am also personally in favour of adopting a CoC and I support adopting > either > the Covenant text or KDE's. Both are fine to me. Another good one is > Mozilla's[1], which the SQLite developers have just adopted too. > > In fact, I was there 10 years ago when KDE decided to adopt something. > Back > then, I was also of the opinion that we shouldn't need anything. The KDE > community had always been a welcoming one: in my first Akademy, I was > greeted > by people I had only met online as an old friend. Moreover, the KDE > community > had always resisted any kind of formal structuring of anything, which led > to > the Technical Working Group being created and disbanding in 2006. Even > today, > the KDE e.V. takes great steps to make sure it is never seen as a ruling > body. > > But the CoC was adopted, with no ill effects. I do not have direct > knowledge > of where they had to intervene, if at all, but I'm told it has happened. > More > importantly, I have also grown as a person since then. In a particularly > telling moment, when a female colleague here in the office (located in a > very > affluent, liberal and progressive part of the US) once asked my opinion on > the > Python Donglegate incident and explained to me the reason why she > interpreted > it the way she did, I realised how my worldview was so very different from > hers. I've come to understand how little things that did not bother me > were > highly offensive to her. > > I've seen basically three questions asked by the skepticals to this > proposal: > > 1) if it ain't broke, why fix it? > > To put it simply: the CoC has as an objective make sure the community is > always welcoming and inclusive. People have a limit on how much hostility > (intended or not) they're going to put up with. If they reach that limit, > they're going to simply avoid it and that can be anywhere from avoiding > contributions to certain parts of the code to stopping contributing > altogether > (or worse). We don't want to lose them or their contributions. > > Think of the CoC as preventive maintenance: you don't do it because it's > broken. You do it so it *won't* break in the first place. > > 2) why not let the code rule? > > Code does not exist in isolation and the Qt Project is not a set of files > in > Git. The Qt Project is a community that maintains that code, so we need > rules > beyond code. We have contributors who don't contribute a lot of code, but > that > does not make them any less important members of the community. > > Besides, any commit comes with a commit message. Any review comes with > feedback and there are few that are simply "+2" with no text. We want good > code, improving Qt and for that we need to interact with one another. > Moreover, the major architectural issues are not discussed in code, but in > prose via email. > > Finally, being good at C++ is not an excuse for being a jackass. No one > should > get a pass because they're experts at something. We can't make the cold > calculus that "person X's productivity is worth 10 new contributors so we > will > allow X's behaviour to turn away 10 contributors". What happens on the > 11th? > And what if one of those turned out to be amazing after a few months? > > So clearly code is not enough. > > 3) how do we prevent ill side-effects and abuse? > > One ill side-effect would be the turning away of important contributors > who > feel that the adoption of the CoC stands in the way of their > participation. > But please note that has not happened to any significant manner in any of > the > big Open Source Projects that have adopted CoCs. That includes the Linux > kernel: despite what you may have heard in the media, the kernel > maintainers > and Linus himself subscribe to the new CoC and Linus has returned to > development. > > We can also work with that person to find a compromise solution. I find it > hard to believe we couldn't, if that person is willing to see the other > side > of the coin. And I speak from experience on that. > > The rest should be in the CoC text itself and how it empowers the > resolution > committee to make its decisions as well as any checks-and-balances on the > com > committee itself. Specifically, the CoC should not be used to > discriminate > against one's political views any more than on another's sexual > orientations. > And what you do on your private time is your own business. > > [1] https://www.mozilla.org/en-US/about/governance/policies/participation/ > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christian.Kandeler at qt.io Fri Oct 26 09:50:17 2018 From: Christian.Kandeler at qt.io (Christian Kandeler) Date: Fri, 26 Oct 2018 07:50:17 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <20181025173945.GA16670@klara.mpi.htwm.de> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <20181025173945.GA16670@klara.mpi.htwm.de> Message-ID: <20181026095004.21207e9c@ckandeler-archlinux> On Thu, 25 Oct 2018 19:39:45 +0200 André Pönitz wrote: > On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via Development wrote: > > We do have a Code of Conduct at KDE for about 10 years now, and this hasn't > > led to abuse of power, suppression of free speech, racism against white people > > or whatever other nonsense people seem to attribute to CoCs nowadays. > > The KDE CoC is *friendly*. It contains words like "considerate", "pragmatic", > "support". It doesn't push someone's personal political agenda. I agree. It reads as if it was written with the intention of creating a constructive environment, lacks the inquisition-y vibe and is free of jargon and weirdly over-specific lists. Christian From Andy.Nichols at qt.io Fri Oct 26 10:12:35 2018 From: Andy.Nichols at qt.io (Andy Nichols) Date: Fri, 26 Oct 2018 08:12:35 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <4145998.dxsAPVRcBo@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <4145998.dxsAPVRcBo@tjmaciei-mobl1> Message-ID: Thank you Thiago for your well put thoughts. This is in line with my thinking as well. I'm glad we are finally at the point of having this discussion, as it's been quite a long time since I hosted the Code of Conduct discussion at the 2017 contributors summit. https://wiki.qt.io/QtCS2017_Qt_Project_Code_of_Conduct What has been so surprising about the discussion so far is the assumption that the people pushing the Code of Conduct have a political agenda, because this is not at all where this drive started from. The Qt project currently is a really nice community who is very supportive and respectful of each other. The Qt community is aligned in achieving the same goals, and the work we do to achieve that is done in good faith. The whole point of the Code of Conduct was to codify those same values so we could maintain that. The choice of the Contributors Covenant as a starting point was arbitrary (I know, because I proposed it). The KDE and Mozzila CoC's are also just as acceptable in my eyes. Even looking at the notes for the CS2017 sessions, we were perfectly fine with the simple theme of "Be Kind. Be respectful". Nothing is set in stone at this point, everything is open to discussion still, even the point of whether we should adopt any code of conduct at all. Based on discussions I've had this week, one of the biggest sticking points with any CoC regards enforcement. Even if we have a one sentence CoC how do gross violations of the CoC get handled? If there is an email address for reporting incidents then who is reading/responding to that for example? The proposal that is part of https://codereview.qt-project.org/#/c/243623/ is also completely open to discussion evaluation. The discussion at CS2017 that led the current proposal was based off of this: "As part of creating the Code of Conduct, we will also establish a small private mailing list for usage in resolving breaches of the code. This would behave similarly to the Security mailing list. This proposal will be part of the draft submitted to the Qt Project for approval." The details of this are tricky though because it depends a lot on trust (similarly the security list). Much of the concern with this proposal has to do with the potential for abuse, and rightly so. I'm not super happy with the idea of a Conduct Cabal who has to the power to banish people from the community either. So maybe a better way of looking at this is, today if you felt were legitimately being harassed by another member of the Qt Project, what would you do? Who would you tell and what kind of reaction would you expect? My understanding of how things are handled today is that its very ad hoc, which is less than ideal as well. The way trust works in the Qt project so far is through the meritocracy so maybe a solution to any trust issues with enforcement can be solved in a similar way? I also want to make it clear that QUIP 12 can be completely different than what is in https://codereview.qt-project.org/#/c/243623/ and welcome a counter proposal based off the KDE CoC if someone would like to draft that. I look forward to hearing any thoughts and ideas. Andy Nichols -----Original Message----- From: Development On Behalf Of Thiago Macieira Sent: Friday, October 26, 2018 7:15 AM To: development at qt-project.org Subject: Re: [Development] QUIP 12: Code of Conduct On Wednesday, 24 October 2018 00:17:09 PDT Ulf Hermann wrote: > Hi, > > regarding our earlier discussions on a possible Code of Conduct, here > as well as at the Contributors' Summit 2017, I've pushed a QUIP with > the necessary rules and definitions: > > https://codereview.qt-project.org/243623 Hello Ulf and everyone else on this thread I've posted a few comments here and there relating to the process of adopting anything in our community, but I haven't yet voiced my opinion on this subject. This email is it. Note that even though I am speaking for myself, I understand my opinion reflects on my employer. So I want to say this first: Intel does support Open Source Projects adopting Code of Conduct as well as actions leading to increasing access and diversity of ideas, hopefully leading to improved code. We also particularly like the Contributor Covenant text. I am also personally in favour of adopting a CoC and I support adopting either the Covenant text or KDE's. Both are fine to me. Another good one is Mozilla's[1], which the SQLite developers have just adopted too. In fact, I was there 10 years ago when KDE decided to adopt something. Back then, I was also of the opinion that we shouldn't need anything. The KDE community had always been a welcoming one: in my first Akademy, I was greeted by people I had only met online as an old friend. Moreover, the KDE community had always resisted any kind of formal structuring of anything, which led to the Technical Working Group being created and disbanding in 2006. Even today, the KDE e.V. takes great steps to make sure it is never seen as a ruling body. But the CoC was adopted, with no ill effects. I do not have direct knowledge of where they had to intervene, if at all, but I'm told it has happened. More importantly, I have also grown as a person since then. In a particularly telling moment, when a female colleague here in the office (located in a very affluent, liberal and progressive part of the US) once asked my opinion on the Python Donglegate incident and explained to me the reason why she interpreted it the way she did, I realised how my worldview was so very different from hers. I've come to understand how little things that did not bother me were highly offensive to her. I've seen basically three questions asked by the skepticals to this proposal: 1) if it ain't broke, why fix it? To put it simply: the CoC has as an objective make sure the community is always welcoming and inclusive. People have a limit on how much hostility (intended or not) they're going to put up with. If they reach that limit, they're going to simply avoid it and that can be anywhere from avoiding contributions to certain parts of the code to stopping contributing altogether (or worse). We don't want to lose them or their contributions. Think of the CoC as preventive maintenance: you don't do it because it's broken. You do it so it *won't* break in the first place. 2) why not let the code rule? Code does not exist in isolation and the Qt Project is not a set of files in Git. The Qt Project is a community that maintains that code, so we need rules beyond code. We have contributors who don't contribute a lot of code, but that does not make them any less important members of the community. Besides, any commit comes with a commit message. Any review comes with feedback and there are few that are simply "+2" with no text. We want good code, improving Qt and for that we need to interact with one another. Moreover, the major architectural issues are not discussed in code, but in prose via email. Finally, being good at C++ is not an excuse for being a jackass. No one should get a pass because they're experts at something. We can't make the cold calculus that "person X's productivity is worth 10 new contributors so we will allow X's behaviour to turn away 10 contributors". What happens on the 11th? And what if one of those turned out to be amazing after a few months? So clearly code is not enough. 3) how do we prevent ill side-effects and abuse? One ill side-effect would be the turning away of important contributors who feel that the adoption of the CoC stands in the way of their participation. But please note that has not happened to any significant manner in any of the big Open Source Projects that have adopted CoCs. That includes the Linux kernel: despite what you may have heard in the media, the kernel maintainers and Linus himself subscribe to the new CoC and Linus has returned to development. We can also work with that person to find a compromise solution. I find it hard to believe we couldn't, if that person is willing to see the other side of the coin. And I speak from experience on that. The rest should be in the CoC text itself and how it empowers the resolution committee to make its decisions as well as any checks-and-balances on the com committee itself. Specifically, the CoC should not be used to discriminate against one's political views any more than on another's sexual orientations. And what you do on your private time is your own business. [1] https://www.mozilla.org/en-US/about/governance/policies/participation/ -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Oliver.Wolff at qt.io Fri Oct 26 10:14:15 2018 From: Oliver.Wolff at qt.io (Oliver Wolff) Date: Fri, 26 Oct 2018 08:14:15 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <20181025173945.GA16670@klara.mpi.htwm.de> <4a2727e7-1f16-9341-559b-eb8a8c162415@qt.io> Message-ID: On 26/10/2018 09:18, Ulf Hermann wrote: > On 10/26/18 9:05 AM, Oliver Wolff wrote: >> +1 from here as well. I also think that the proposed document (and >> especially the "enforcement" part) is way too long > The KDE CoC [1] does not specify any action to be taken when it's > violated. That's the main reason why it seems shorter. If you only > consider the equivalent sections in our proposed CoC, the KDE one is > actually much longer. That said, I wouldn't mind replacing the "Our > Pledge" and "Our Standards" paragraphs in the current proposal with the > KDE CoC if that helps with acceptance here. > > But, how does this actually work in practice at KDE? Is there another > document that states what they do if someone oversteps the boundaries? > There isn't even a contact email in their CoC. So, if someone was > slapping me around with a large fish in the KDE IRC channel, I still > wouldn't know what to do about it. I think it depends on the CoC's main purpose (which we are currently defining). I'd see it as a behavioral guideline which states how to interact with other people. It might basically say that we treat each other with respect and are not assholes (pardon the french). If a (potential) contributor reads these, he will get the idea and know, what collaboration in the project will (ideally) be like. By filling that guideline with technicalities and punishments we take away that positive vibe and create a more threatening atmosphere. Additionally it lengthens the core document (unnessecarily in my eyes). Enforcement and punishments are mere technicalities which can be "hidden" in another document. The code of conduct should describe the generic ways of working together for every day, while the additional document of punishment will only be used rarely and thus can be "hidden" a bit. I still think and hope that there will not be too many cases where the CoC police will have to intervene. Just my 2 cents, Olli > > Ulf > > [1] https://www.kde.org/code-of-conduct/ > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From volker.krause at kdab.com Fri Oct 26 10:19:42 2018 From: volker.krause at kdab.com (Volker Krause) Date: Fri, 26 Oct 2018 10:19:42 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <4a2727e7-1f16-9341-559b-eb8a8c162415@qt.io> Message-ID: <1703595.yab0zvMfhV@vkpc19> On Friday, 26 October 2018 09:18:21 CEST Ulf Hermann wrote: > On 10/26/18 9:05 AM, Oliver Wolff wrote: > > +1 from here as well. I also think that the proposed document (and > > especially the "enforcement" part) is way too long > > The KDE CoC [1] does not specify any action to be taken when it's > violated. That's the main reason why it seems shorter. If you only > consider the equivalent sections in our proposed CoC, the KDE one is > actually much longer. That said, I wouldn't mind replacing the "Our > Pledge" and "Our Standards" paragraphs in the current proposal with the > KDE CoC if that helps with acceptance here. > > But, how does this actually work in practice at KDE? Is there another > document that states what they do if someone oversteps the boundaries? > There isn't even a contact email in their CoC. So, if someone was > slapping me around with a large fish in the KDE IRC channel, I still > wouldn't know what to do about it. Yes, there is the KDE Community Working Group, which is the body tasked with (among other things) dealing with CoC violations, and the regulation for that is indeed not in the CoC itself but the working group charter. I'd need to re- read the wording but from how this works in practice it's not all that different from what is proposed here I think. If there is no suitable body yet to deal with violations, it obviously will need to be created alongside the actual CoC. Regards, Volker -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4664 bytes Desc: not available URL: From Paul.Wicking at qt.io Fri Oct 26 16:02:24 2018 From: Paul.Wicking at qt.io (Paul Wicking) Date: Fri, 26 Oct 2018 14:02:24 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <20181025173945.GA16670@klara.mpi.htwm.de> <4a2727e7-1f16-9341-559b-eb8a8c162415@qt.io> Message-ID: Some time lurker, first time poster. I'm an employee of the Qt Company, Oslo office, since January 2018. I'm not an approver and as such do not have voting rights. However, my favorite Austrian philosopher once said "give back and change the world", so this is my way of giving back. Let's see if we can't get to the part about changing the world together. I was surprised when I learned earlier this year that there isn't any CoC for the Qt project. I agree wholeheartedly that we shouldn't need one. I also agree completely that we do need one. Therefore, I would like to thank the volunteers involved in creating these first drafts - judging by the amounts of comments in gerrit, it has been quite the task already. You people are awesome! However, I'm sorry to say I find I do not agree with the current proposal. As I see it, a code of conduct serves two equally important purposes: - It serves as a reminder to ourselves to always strive for excellence. - It shows that we expect excellence from each other. In that spirit, I must say I find Simon's suggestion of "kindness guidelines" much more appropriate than codifying the bad behavior and nasty things we don't want to see. As a new member of _any_ community, I would much rather see the one-liner as referenced by Andy, or an adaptation of KDE's CoC, than some legalese "formal line in the sand about what is unacceptable". Tell me how I can participate in a productive and fruitful way. Tell me what I can expect from the community I am about to take part in. Listing what isn't good, tells me that the community is riddled with poisonous behavior to such an extent that it is more important to focus on the bad than on the good. That doesn't sound like a community I want to be a part of. More importantly, that doesn't sound like Qt. Not to me, anyway. I appreciate how there's room for disagreement on the mailing lists, forum, IRC, and gerrit. I have yet to experience something negative - in fact, I am in awe at the amount of help and encouragement I get from both the community and my fellow TQtC employees, from all corners of the world. You help me deliver excellence, and I can only hope to do the same for my peers. And I firmly believe a CoC, or kindness guidelines, will increase the likelihood of others having a similar experience with the Qt community. I wish that for each of you. Live long and prosper. -- Paul Wicking Documentation Engineer The Qt Company https://qt.io/ From Robert.Loehning at qt.io Fri Oct 26 17:27:21 2018 From: Robert.Loehning at qt.io (Robert Loehning) Date: Fri, 26 Oct 2018 15:27:21 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <20181025173945.GA16670@klara.mpi.htwm.de> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <20181025173945.GA16670@klara.mpi.htwm.de> Message-ID: <20e5555f-7c11-e577-98a5-75eac5a0e18f@qt.io> Am 25.10.2018 um 19:39 schrieb André Pönitz: > On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via Development wrote: >> We do have a Code of Conduct at KDE for about 10 years now, and this hasn't >> led to abuse of power, suppression of free speech, racism against white people >> or whatever other nonsense people seem to attribute to CoCs nowadays. > > The KDE CoC is *friendly*. It contains words like "considerate", "pragmatic", > "support". It doesn't push someone's personal political agenda. This is a > completely different beast than the Contributor Covenant that's about > "enforcing", "reporting", "banning". > > I think we'd see much less heat in the discussion if the proposed Qt CoC had > been based on the KDE CoC. > > Andre' +1 for the KDE CoC. From thiago.macieira at intel.com Fri Oct 26 17:59:10 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Oct 2018 08:59:10 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <4145998.dxsAPVRcBo@tjmaciei-mobl1> Message-ID: <1817756.t0qVAJgBIh@tjmaciei-mobl1> On Thursday, 25 October 2018 23:55:09 PDT Elvis Stansvik wrote: > Absolutely. And one thing I've when doing code reviews at work is that it's > _very_ effective to not only point out problem areas of where things should > be done differently, but also point out parts that are particularly good, > as encouragement. The reviewee will feel better, and be more productive, > producing even better code. > > Humans are quite simple in that sense Ooh, that's a nice idea. I've only pointed out when it was a very clever solution (just short of a hack) to a problem, but I'm thinking I should pay attention to more regular things that are well-done. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Oct 26 18:07:02 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Oct 2018 09:07:02 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <4145998.dxsAPVRcBo@tjmaciei-mobl1> Message-ID: <3140255.DCYrTFKIPV@tjmaciei-mobl1> On Friday, 26 October 2018 00:44:57 PDT Alexey Andreyev wrote: > I want to contribute: to accept that, we have to define "private time" > meaning in a such public place as the web. Is personal blog page posting a > private time? The Mozilla text explains what it considers to be "Mozilla spaces", which defines by exclusion everything that is not. Blogs are a good example: your blog is your own private time. You can write whatever you want, even in your own native language which most others can't read. But if you choose to aggregate it into Planet Qt, then all the content that gets shown there is now contribution to the Qt Community and under the CoC, just like the requirement to write in English. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Oct 26 18:11:58 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Oct 2018 09:11:58 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <4145998.dxsAPVRcBo@tjmaciei-mobl1> Message-ID: <2157984.flhv5agb7N@tjmaciei-mobl1> On Friday, 26 October 2018 01:12:35 PDT Andy Nichols wrote: > The details of this are tricky though because it depends a lot on trust > (similarly the security list). Much of the concern with this proposal has > to do with the potential for abuse, and rightly so. I'm not super happy > with the idea of a Conduct Cabal who has to the power to banish people from > the community either. One idea I've seen recently is to populate the panel members at random, on a need basis, much like jury duty. I don't know of project adopting this solution and whether they've been successful at it. Would be nice to research. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Oct 26 18:17:07 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Oct 2018 09:17:07 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <4145998.dxsAPVRcBo@tjmaciei-mobl1> Message-ID: <6451524.oa1CdlDt1m@tjmaciei-mobl1> On Friday, 26 October 2018 01:12:35 PDT Andy Nichols wrote: > The way trust works in the Qt project so far is through the meritocracy so > maybe a solution to any trust issues with enforcement can be solved in a > similar way? And on this point: yes, but not the code decision-making structure. I agree that we can meritocratically select the CoC Board/Panel/Committee, but the merit qualifications necessarily imply it's a separate structure. Lars is our Chief Maintainer, which means he's good at coding and knows Qt inside and out. That does not follow he's good at resolving CoC violations or that he has the time for it. (He probably is good, since he's also been a perople manager for 15+ years [was my manager even!], but that's not a logical conclusion from the original statements) A better example is me: I am maintainer for QtCore, but I am not qualified to judge and address CoC violations. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jhihn at gmx.com Fri Oct 26 18:48:11 2018 From: jhihn at gmx.com (Jason H) Date: Fri, 26 Oct 2018 18:48:11 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <20181026095004.21207e9c@ckandeler-archlinux> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <20181025173945.GA16670@klara.mpi.htwm.de> <20181026095004.21207e9c@ckandeler-archlinux> Message-ID: My fundamental problem about the Contributor Covenant[1] was initially and solely the fallout from the Linux Kernel fiasco. But then I learned that it was drafted by Coraline Ada Ehmke, who sought to have a contributor removed [2] from a project preemptively. The contributor did nothing wrong with respect to the project or the project's community. She constructed a claim of "transphobia" based on a tweet the contributor wrote in no way relating to the project at hand, and slandered the project for not expunging them. My mind is made up: the Contributor Covenant is a tool of oppression. The specific sentence in the Covenant is: "This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community." However, despite being the author of the Covenant (2014), she found it appropriate to attack someone who was clearly not operating in a project space or representing the project community (2015). We now have two examples - the linux Kernel and Opal project, that after CC was enacted that calls for removal of members based on past unrelated tweets went out. One of the problems its politics and political climates change over time. Expressing what is not political at one point in time may become political in subsequent years. People's minds also change over time. I urge you to read link[3] below and see if we want that kind of attention. It summarizes what happens when the CC has been adopted by other projects. [1] https://en.wikipedia.org/wiki/Contributor_Covenant [2] https://github.com/opal/opal/issues/941 [3] https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/ > Sent: Friday, October 26, 2018 at 3:50 AM > From: "Christian Kandeler" > To: "development at qt-project.org" > Subject: Re: [Development] QUIP 12: Code of Conduct > > On Thu, 25 Oct 2018 19:39:45 +0200 > André Pönitz wrote: > > > On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via Development wrote: > > > We do have a Code of Conduct at KDE for about 10 years now, and this hasn't > > > led to abuse of power, suppression of free speech, racism against white people > > > or whatever other nonsense people seem to attribute to CoCs nowadays. > > > > The KDE CoC is *friendly*. It contains words like "considerate", "pragmatic", > > "support". It doesn't push someone's personal political agenda. > > I agree. It reads as if it was written with the intention of creating a constructive environment, lacks the inquisition-y vibe and is free of jargon and weirdly over-specific lists. > > > Christian > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From enmarantispam at gmail.com Fri Oct 26 19:24:52 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Fri, 26 Oct 2018 20:24:52 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <20181025173945.GA16670@klara.mpi.htwm.de> <20181026095004.21207e9c@ckandeler-archlinux> Message-ID: Just to clarify: she sought to remove _maintainer_ of the project :) At that point the guy was doing most of the work. On Fri, Oct 26, 2018 at 7:48 PM Jason H wrote: > My fundamental problem about the Contributor Covenant[1] was initially and > solely the fallout from the Linux Kernel fiasco. But then I learned that it > was drafted by Coraline Ada Ehmke, who sought to have a contributor removed > [2] from a project preemptively. The contributor did nothing wrong with > respect to the project or the project's community. She constructed a claim > of "transphobia" based on a tweet the contributor wrote in no way relating > to the project at hand, and slandered the project for not expunging them. > My mind is made up: the Contributor Covenant is a tool of oppression. > > The specific sentence in the Covenant is: > "This Code of Conduct applies both within project spaces and in public > spaces when an individual is representing the project or its community." > > However, despite being the author of the Covenant (2014), she found it > appropriate to attack someone who was clearly not operating in a project > space or representing the project community (2015). We now have two > examples - the linux Kernel and Opal project, that after CC was enacted > that calls for removal of members based on past unrelated tweets went out. > One of the problems its politics and political climates change over time. > Expressing what is not political at one point in time may become political > in subsequent years. People's minds also change over time. > > I urge you to read link[3] below and see if we want that kind of > attention. It summarizes what happens when the CC has been adopted by other > projects. > > [1] https://en.wikipedia.org/wiki/Contributor_Covenant > [2] https://github.com/opal/opal/issues/941 > [3] https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/ > > > Sent: Friday, October 26, 2018 at 3:50 AM > > From: "Christian Kandeler" > > To: "development at qt-project.org" > > Subject: Re: [Development] QUIP 12: Code of Conduct > > > > On Thu, 25 Oct 2018 19:39:45 +0200 > > André Pönitz wrote: > > > > > On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via > Development wrote: > > > > We do have a Code of Conduct at KDE for about 10 years now, and this > hasn't > > > > led to abuse of power, suppression of free speech, racism against > white people > > > > or whatever other nonsense people seem to attribute to CoCs > nowadays. > > > > > > The KDE CoC is *friendly*. It contains words like "considerate", > "pragmatic", > > > "support". It doesn't push someone's personal political agenda. > > > > I agree. It reads as if it was written with the intention of creating a > constructive environment, lacks the inquisition-y vibe and is free of > jargon and weirdly over-specific lists. > > > > > > Christian > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From private at bernhard-lindner.de Fri Oct 26 19:53:18 2018 From: private at bernhard-lindner.de (Bernhard Lindner) Date: Fri, 26 Oct 2018 19:53:18 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: I wish any one discussion about Qt software quality would have attracted so much attention, passion and effort as this CoC topic. -- Best Regards, Bernhard Lindner From jhihn at gmx.com Fri Oct 26 20:06:34 2018 From: jhihn at gmx.com (Jason H) Date: Fri, 26 Oct 2018 20:06:34 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <20181025173945.GA16670@klara.mpi.htwm.de> <20181026095004.21207e9c@ckandeler-archlinux> Message-ID: An HTML attachment was scrubbed... URL: From enmarantispam at gmail.com Fri Oct 26 20:17:45 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Fri, 26 Oct 2018 21:17:45 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <20181025173945.GA16670@klara.mpi.htwm.de> <20181026095004.21207e9c@ckandeler-archlinux> Message-ID: And we already see the budding sentiments to that exact tune: (quote from Edward Welbourne) >That sometimes folk have felt so intimidated that they give up on trying > to make a contribution; and that, were potential worse conduct to cause > distress to a contributor, we have no process in place that could give > them confidence that their distress will be respected and honest efforts vwill be made to relieve it. Various variations and permutations on > these themes may also be relevant; see Simon's mail. Note: I understand that he means well, but Within the context of Contributor Covenant the punishability of the potential harm of people not contributing can escalate to stupid proportions. I have nothing against KDE's code. It strives to add positivity. I am very much against Qt's CoC being drafted from Covenant. Covenant is focused on oppression and excluding ppl. On Fri, Oct 26, 2018 at 9:06 PM Jason H wrote: > I don't really care that their role, though that move takes gravitas. > > I will never endorse a measure that encourages (and the CC does > encourage) a witchhunt on the members of the community. It encourages by > creating a metric of "maximum comfort" (or "least harmful") and that > anything else is somehow a violation. She did it herself with these > words[2]: "Is this what the other maintainers want to be reflected in the > project? Will any transgender developers feel comfortable contributing?" > With those words she created a metric of "maximum comfort". So now the > question moves from not just having not offended someone, but to be > maximally comforting to every possible person. Not that there's anything > wrong with *wanting* to be maximally comfortable for everyone. It's a great > goal. But now every interaction is to be judged by this metric, and > anything less than the maximal comfort is somehow potentially alienating to > a population and can be construed to be a cause for removal. > > In the CC itself it encourages a witchhunt with these words: > "Project maintainers have the right and responsibility to remove, edit, > or reject comments, commits, code, wiki edits, issues, and other > contributions that are not aligned to this Code of Conduct, or to ban > temporarily or permanently any contributor for other behaviors that they > deem inappropriate, threatening, offensive, or harmful." > > That last word, "harmful" significantly alters the statement. Don't let > your eyes glaze over. Now anything that happens is potentially harmful. > (Ironically C++, or its constructs is even "considered harmful". Just > google "C++ considered harmful", lol). I probably would have let this whole > issue slide but that last word _really_ changes the character of the > covenant. I beleive that is *the* word that allows the witchhunting. It's > not just direct harm but potential harm. From [2]: "As a queer person > this sort of argument from a maintainer makes me feel unwelcome. The > ignorance which @elia shows by claiming that > transfolk are "not accepting reality" is actively harmful. I will not > contribute to this project or any other project which @elia > maintains." - strand > > Not that strand was participating, but states that there will be no future > contribution by strand. This is an appeal to percieved harm - that now > strand will not ever contribute, the project is potentially harmed by > missing out on a contributor. So now this issue can fall under the > Covenant. > > > How can we avoid witchhunts? > > *Sent:* Friday, October 26, 2018 at 1:24 PM > *From:* "NIkolai Marchenko" > *To:* jhihn at gmx.com > *Cc:* "Christian Kandeler" , "Qt development > mailing list" > *Subject:* Re: [Development] QUIP 12: Code of Conduct > Just to clarify: she sought to remove _maintainer_ of the project :) At > that point the guy was doing most of the work. > > On Fri, Oct 26, 2018 at 7:48 PM Jason H wrote: > >> My fundamental problem about the Contributor Covenant[1] was initially >> and solely the fallout from the Linux Kernel fiasco. But then I learned >> that it was drafted by Coraline Ada Ehmke, who sought to have a contributor >> removed [2] from a project preemptively. The contributor did nothing wrong >> with respect to the project or the project's community. She constructed a >> claim of "transphobia" based on a tweet the contributor wrote in no way >> relating to the project at hand, and slandered the project for not >> expunging them. My mind is made up: the Contributor Covenant is a tool of >> oppression. >> >> The specific sentence in the Covenant is: >> "This Code of Conduct applies both within project spaces and in public >> spaces when an individual is representing the project or its community." >> >> However, despite being the author of the Covenant (2014), she found it >> appropriate to attack someone who was clearly not operating in a project >> space or representing the project community (2015). We now have two >> examples - the linux Kernel and Opal project, that after CC was enacted >> that calls for removal of members based on past unrelated tweets went out. >> One of the problems its politics and political climates change over time. >> Expressing what is not political at one point in time may become political >> in subsequent years. People's minds also change over time. >> >> I urge you to read link[3] below and see if we want that kind of >> attention. It summarizes what happens when the CC has been adopted by other >> projects. >> >> [1] https://en.wikipedia.org/wiki/Contributor_Covenant >> [2] https://github.com/opal/opal/issues/941 >> [3] https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/ >> >> > Sent: Friday, October 26, 2018 at 3:50 AM >> > From: "Christian Kandeler" >> > To: "development at qt-project.org" >> > Subject: Re: [Development] QUIP 12: Code of Conduct >> > >> > On Thu, 25 Oct 2018 19:39:45 +0200 >> > André Pönitz wrote: >> > >> > > On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via >> Development wrote: >> > > > We do have a Code of Conduct at KDE for about 10 years now, and >> this hasn't >> > > > led to abuse of power, suppression of free speech, racism against >> white people >> > > > or whatever other nonsense people seem to attribute to CoCs >> nowadays. >> > > >> > > The KDE CoC is *friendly*. It contains words like "considerate", >> "pragmatic", >> > > "support". It doesn't push someone's personal political agenda. >> > >> > I agree. It reads as if it was written with the intention of creating a >> constructive environment, lacks the inquisition-y vibe and is free of >> jargon and weirdly over-specific lists. >> > >> > >> > Christian >> > _______________________________________________ >> > Development mailing list >> > Development at qt-project.org >> > http://lists.qt-project.org/mailman/listinfo/development >> > >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Oct 26 20:35:06 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Oct 2018 11:35:06 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <20181026095004.21207e9c@ckandeler-archlinux> Message-ID: <2213770.76mU4ngG7U@tjmaciei-mobl1> On Friday, 26 October 2018 09:48:11 PDT Jason H wrote: > My fundamental problem about the Contributor Covenant[1] was initially and > solely the fallout from the Linux Kernel fiasco. But then I learned that it > was drafted by Coraline Ada Ehmke, who sought to have a contributor removed > [2] from a project preemptively. The contributor did nothing wrong with > respect to the project or the project's community. She constructed a claim > of "transphobia" based on a tweet the contributor wrote in no way relating > to the project at hand, and slandered the project for not expunging them. > My mind is made up: the Contributor Covenant is a tool of oppression. First of all, the kernel adoption of CoC was not a fiasco. All the negative emails you may have seen came from people who are not contributors, often their first and only email to the mailing list. Despite what Eric Raymond has said, revoking the copyright licence for GPL just cannot be done -- it would be against GPL's spirit. Coraline's intentions are irrelevant. What matters is the text: is it good? But if your mind is made up, kindly refrain from trying to convince others to change their minds too. This is a two-way street and you're only welcome to argue your point if you're willing to admit defeat too. > The specific sentence in the Covenant is: > "This Code of Conduct applies both within project spaces and in public > spaces when an individual is representing the project or its community." > > However, despite being the author of the Covenant (2014), she found it > appropriate to attack someone who was clearly not operating in a project > space or representing the project community (2015). We now have two > examples - the linux Kernel and Opal project, that after CC was enacted > that calls for removal of members based on past unrelated tweets went out. > One of the problems its politics and political climates change over time. > Expressing what is not political at one point in time may become political > in subsequent years. People's minds also change over time. What is the kernel example? Who was forced out, or attempted to? > I urge you to read link[3] below and see if we want that kind of attention. > It summarizes what happens when the CC has been adopted by other projects. > > [1] https://en.wikipedia.org/wiki/Contributor_Covenant > [2] https://github.com/opal/opal/issues/941 > [3] https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/ I have. The proponents of the removal were arguing that having such a person as a project leader is poisonous to the project, *regardless* of the fact that it was done in private time, because it would turn away potential new contributors as they didn't want to associate with such a person. This is an extreme situation, indeed, and one that the CoC committee should be able to make a judgement on: which way is the project best served? Anyway, given that the request to get the maintainer removed was not accepted, how is that a failure of the CoC? Isn't it showing that it's *working*? I personally think those situations explain why we need a CoC in the first place and why the judgment on such situations is very subjective, best left to humans, not to a script. And the deliberations should not be in a public forum, like a GitHub issue. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jhihn at gmx.com Fri Oct 26 20:39:52 2018 From: jhihn at gmx.com (Jason H) Date: Fri, 26 Oct 2018 20:39:52 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <20181025173945.GA16670@klara.mpi.htwm.de> <20181026095004.21207e9c@ckandeler-archlinux> Message-ID: An HTML attachment was scrubbed... URL: From enmarantispam at gmail.com Fri Oct 26 20:40:14 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Fri, 26 Oct 2018 21:40:14 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2213770.76mU4ngG7U@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <20181026095004.21207e9c@ckandeler-archlinux> <2213770.76mU4ngG7U@tjmaciei-mobl1> Message-ID: > Coraline's intentions are irrelevant. What matters is the text: is it good? I have to disagree. As I see it: she has spent considerable amount of time drafting the exact text to allow her to bully projects. Have you spent as much time analyzing all of the potential pitfalls she may or may not have inserted into this document? She's a malicious person and not second guessign her Code is a mistake. Yes, indeed, is the text good? This has to be analyzed: in depth. And I would still probably avoid using hers. On Fri, Oct 26, 2018 at 9:35 PM Thiago Macieira wrote: > On Friday, 26 October 2018 09:48:11 PDT Jason H wrote: > > My fundamental problem about the Contributor Covenant[1] was initially > and > > solely the fallout from the Linux Kernel fiasco. But then I learned that > it > > was drafted by Coraline Ada Ehmke, who sought to have a contributor > removed > > [2] from a project preemptively. The contributor did nothing wrong with > > respect to the project or the project's community. She constructed a > claim > > of "transphobia" based on a tweet the contributor wrote in no way > relating > > to the project at hand, and slandered the project for not expunging them. > > My mind is made up: the Contributor Covenant is a tool of oppression. > > First of all, the kernel adoption of CoC was not a fiasco. All the > negative > emails you may have seen came from people who are not contributors, often > their first and only email to the mailing list. Despite what Eric Raymond > has > said, revoking the copyright licence for GPL just cannot be done -- it > would > be against GPL's spirit. > > Coraline's intentions are irrelevant. What matters is the text: is it good? > > But if your mind is made up, kindly refrain from trying to convince others > to > change their minds too. This is a two-way street and you're only welcome > to > argue your point if you're willing to admit defeat too. > > > The specific sentence in the Covenant is: > > "This Code of Conduct applies both within project spaces and in public > > spaces when an individual is representing the project or its community." > > > > However, despite being the author of the Covenant (2014), she found it > > appropriate to attack someone who was clearly not operating in a project > > space or representing the project community (2015). We now have two > > examples - the linux Kernel and Opal project, that after CC was enacted > > that calls for removal of members based on past unrelated tweets went > out. > > One of the problems its politics and political climates change over time. > > Expressing what is not political at one point in time may become > political > > in subsequent years. People's minds also change over time. > > What is the kernel example? Who was forced out, or attempted to? > > > I urge you to read link[3] below and see if we want that kind of > attention. > > It summarizes what happens when the CC has been adopted by other > projects. > > > > [1] https://en.wikipedia.org/wiki/Contributor_Covenant > > [2] https://github.com/opal/opal/issues/941 > > [3] > https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/ > > I have. > > The proponents of the removal were arguing that having such a person as a > project leader is poisonous to the project, *regardless* of the fact that > it > was done in private time, because it would turn away potential new > contributors as they didn't want to associate with such a person. This is > an > extreme situation, indeed, and one that the CoC committee should be able > to > make a judgement on: which way is the project best served? > > Anyway, given that the request to get the maintainer removed was not > accepted, > how is that a failure of the CoC? Isn't it showing that it's *working*? > > I personally think those situations explain why we need a CoC in the first > place and why the judgment on such situations is very subjective, best > left to > humans, not to a script. And the deliberations should not be in a public > forum, like a GitHub issue. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Oct 26 20:45:27 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Oct 2018 11:45:27 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: <3844322.YypU1izrmg@tjmaciei-mobl1> On Friday, 26 October 2018 10:53:18 PDT Bernhard Lindner wrote: > I wish any one discussion about Qt software quality would have attracted so > much attention, passion and effort as this CoC topic. There are plenty of technical threads that have had more emails sent than this. Look at the ones about the buildsystem, for a recent example. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Oct 26 20:45:27 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Oct 2018 11:45:27 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: <3844322.YypU1izrmg@tjmaciei-mobl1> On Friday, 26 October 2018 10:53:18 PDT Bernhard Lindner wrote: > I wish any one discussion about Qt software quality would have attracted so > much attention, passion and effort as this CoC topic. There are plenty of technical threads that have had more emails sent than this. Look at the ones about the buildsystem, for a recent example. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jhihn at gmx.com Fri Oct 26 21:25:50 2018 From: jhihn at gmx.com (Jason H) Date: Fri, 26 Oct 2018 21:25:50 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2213770.76mU4ngG7U@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <20181026095004.21207e9c@ckandeler-archlinux> <2213770.76mU4ngG7U@tjmaciei-mobl1> Message-ID: Thiago, Here's a link that kinda puts it together: https://lulz.com/linux-devs-threaten-killswitch-coc-controversy-1252/ (Scroll to "The Controversy" and the "rape apologist" Sage Sharp tweet) I didn't realize this was a thing of "defeat". I have concerns, based on actual events, that I want resolved. I do respectfully disagree on whether or not an author is relevant to considering a work. In this case the author has a track record of attacking members in open source projects and arguing against meritocracy. Is the text good? There is a lot I agree with, but there are things in it that cross the line for me. I think we can come to an agreement, but not with invoking the Covenant in its current form. > Sent: Friday, October 26, 2018 at 2:35 PM > From: "Thiago Macieira" > To: development at qt-project.org > Subject: Re: [Development] QUIP 12: Code of Conduct > > On Friday, 26 October 2018 09:48:11 PDT Jason H wrote: > > My fundamental problem about the Contributor Covenant[1] was initially and > > solely the fallout from the Linux Kernel fiasco. But then I learned that it > > was drafted by Coraline Ada Ehmke, who sought to have a contributor removed > > [2] from a project preemptively. The contributor did nothing wrong with > > respect to the project or the project's community. She constructed a claim > > of "transphobia" based on a tweet the contributor wrote in no way relating > > to the project at hand, and slandered the project for not expunging them. > > My mind is made up: the Contributor Covenant is a tool of oppression. > > First of all, the kernel adoption of CoC was not a fiasco. All the negative > emails you may have seen came from people who are not contributors, often > their first and only email to the mailing list. Despite what Eric Raymond has > said, revoking the copyright licence for GPL just cannot be done -- it would > be against GPL's spirit. > > Coraline's intentions are irrelevant. What matters is the text: is it good? > > But if your mind is made up, kindly refrain from trying to convince others to > change their minds too. This is a two-way street and you're only welcome to > argue your point if you're willing to admit defeat too. > > > The specific sentence in the Covenant is: > > "This Code of Conduct applies both within project spaces and in public > > spaces when an individual is representing the project or its community." > > > > However, despite being the author of the Covenant (2014), she found it > > appropriate to attack someone who was clearly not operating in a project > > space or representing the project community (2015). We now have two > > examples - the linux Kernel and Opal project, that after CC was enacted > > that calls for removal of members based on past unrelated tweets went out. > > One of the problems its politics and political climates change over time. > > Expressing what is not political at one point in time may become political > > in subsequent years. People's minds also change over time. > > What is the kernel example? Who was forced out, or attempted to? > > > I urge you to read link[3] below and see if we want that kind of attention. > > It summarizes what happens when the CC has been adopted by other projects. > > > > [1] https://en.wikipedia.org/wiki/Contributor_Covenant > > [2] https://github.com/opal/opal/issues/941 > > [3] https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/ > > I have. > > The proponents of the removal were arguing that having such a person as a > project leader is poisonous to the project, *regardless* of the fact that it > was done in private time, because it would turn away potential new > contributors as they didn't want to associate with such a person. This is an > extreme situation, indeed, and one that the CoC committee should be able to > make a judgement on: which way is the project best served? > > Anyway, given that the request to get the maintainer removed was not accepted, > how is that a failure of the CoC? Isn't it showing that it's *working*? > > I personally think those situations explain why we need a CoC in the first > place and why the judgment on such situations is very subjective, best left to > humans, not to a script. And the deliberations should not be in a public > forum, like a GitHub issue. From yetanotherandreyev at gmail.com Fri Oct 26 21:28:42 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Fri, 26 Oct 2018 22:28:42 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2213770.76mU4ngG7U@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <20181026095004.21207e9c@ckandeler-archlinux> <2213770.76mU4ngG7U@tjmaciei-mobl1> Message-ID: > I personally think those situations explain why we need a CoC in the first place and why the judgment on such situations is very subjective, best left to humans, not to a script. And the deliberations should not be in a public forum, like a GitHub issue. If mentioned situations best left to humans, what is current CoC for? If deliberations should be limited, who could have access to it? > Isn't it showing that it's *working*? I guess not, not the current version of the CoC at least. Communities are spending resources instead of working on other tasks. If discussed situations be left to humans in the end with current document, we could just state simple one-liner instead: "be conscious and think about future consequences", -- to minimize CoC problems at least. As I said previously, I agree we should work together on a better version. I guess Qt people could do it. пт, 26 окт. 2018 г. в 21:35, Thiago Macieira : > On Friday, 26 October 2018 09:48:11 PDT Jason H wrote: > > My fundamental problem about the Contributor Covenant[1] was initially > and > > solely the fallout from the Linux Kernel fiasco. But then I learned that > it > > was drafted by Coraline Ada Ehmke, who sought to have a contributor > removed > > [2] from a project preemptively. The contributor did nothing wrong with > > respect to the project or the project's community. She constructed a > claim > > of "transphobia" based on a tweet the contributor wrote in no way > relating > > to the project at hand, and slandered the project for not expunging them. > > My mind is made up: the Contributor Covenant is a tool of oppression. > > First of all, the kernel adoption of CoC was not a fiasco. All the > negative > emails you may have seen came from people who are not contributors, often > their first and only email to the mailing list. Despite what Eric Raymond > has > said, revoking the copyright licence for GPL just cannot be done -- it > would > be against GPL's spirit. > > Coraline's intentions are irrelevant. What matters is the text: is it good? > > But if your mind is made up, kindly refrain from trying to convince others > to > change their minds too. This is a two-way street and you're only welcome > to > argue your point if you're willing to admit defeat too. > > > The specific sentence in the Covenant is: > > "This Code of Conduct applies both within project spaces and in public > > spaces when an individual is representing the project or its community." > > > > However, despite being the author of the Covenant (2014), she found it > > appropriate to attack someone who was clearly not operating in a project > > space or representing the project community (2015). We now have two > > examples - the linux Kernel and Opal project, that after CC was enacted > > that calls for removal of members based on past unrelated tweets went > out. > > One of the problems its politics and political climates change over time. > > Expressing what is not political at one point in time may become > political > > in subsequent years. People's minds also change over time. > > What is the kernel example? Who was forced out, or attempted to? > > > I urge you to read link[3] below and see if we want that kind of > attention. > > It summarizes what happens when the CC has been adopted by other > projects. > > > > [1] https://en.wikipedia.org/wiki/Contributor_Covenant > > [2] https://github.com/opal/opal/issues/941 > > [3] > https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/ > > I have. > > The proponents of the removal were arguing that having such a person as a > project leader is poisonous to the project, *regardless* of the fact that > it > was done in private time, because it would turn away potential new > contributors as they didn't want to associate with such a person. This is > an > extreme situation, indeed, and one that the CoC committee should be able > to > make a judgement on: which way is the project best served? > > Anyway, given that the request to get the maintainer removed was not > accepted, > how is that a failure of the CoC? Isn't it showing that it's *working*? > > I personally think those situations explain why we need a CoC in the first > place and why the judgment on such situations is very subjective, best > left to > humans, not to a script. And the deliberations should not be in a public > forum, like a GitHub issue. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvstone at gmail.com Fri Oct 26 22:26:52 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Fri, 26 Oct 2018 22:26:52 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <4b21d498-c513-53e7-5c20-2e8c88aeb0db@kdab.com> References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> <4b21d498-c513-53e7-5c20-2e8c88aeb0db@kdab.com> Message-ID: Den sön 21 okt. 2018 kl 17:50 skrev Giuseppe D'Angelo : > > Hello, > > Il 21/10/18 16:15, Elvis Stansvik ha scritto: > > I couldn't find a way to contact them. > > The best shot would be the std-discussion mailing list, I think. > > > In order to try out the unsafe usage you suggested in your other mail, > > and also another unsafe usage pointed out in an SO question > > (https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612), > > I made the following test program. > > > > The output when running is: > > > > [estan at newton move-to-const-test]$ ./move-to-const-test > > without moveToConst: > > FooPrivate constr from vector > > Foo constr with arg 0x7fffdb627200 > > Foo begin 0x7fffdb627200 > > Foo end 0x7fffdb627200 > > Foo destr 0x7fffdb627200 > > FooPrivate destr > > > > with moveToConst: > > FooPrivate constr from vector > > Foo constr with arg 0x7fffdb627208 > > Foo move constr 0x7fffdb627210 > > Foo destr 0x7fffdb627208 > > Foo begin const 0x7fffdb627210 > > Foo end const 0x7fffdb627210 > > Foo destr 0x7fffdb627210 > > FooPrivate destr > > [estan at newton move-to-const-test]$ > > > > Which just shows it's working as intended. > > However the third test should be a without moveToConst, but storing in a > temporary, i.e. the current best practice. It should output exactly like > the first one, but of course call const begin/end. For completely other reasons, I came across "Range-based for statements with initializer" today: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0614r1.html With that, the Qt best practice could become for (const auto list = getQList(); const auto &v : list) { ... } Which may or may not be pretty, but avoids the extra line of code and keeps the scope clean. Elvis > > And note the extra move/destruciton in the second example. > > > > The two unsafe usages are commented out, because they wouldn't compile (good!). > > > Whops, you're absolutely right. My bad. With your proposed implementation: > > > template > > const T moveToConst(T &&t) > > { > > return std::move(t); > > } > > This won't compile when called on a non-const lvalue (the return type > will be a lvalue reference to const, which won't bind to a non-const > rvalue). I stand corrected. > > Which actually makes me think of yet another possibility of misuse, that > is, applying moveToConst to a function returning a const object. That > will compile, using a copy... > > > const QVector getVector(); > > for (auto &obj : moveToConst(getVector()) ~~~ > > > Long story short, I think it's good if we stay away from this in Qt. > Clazy warns you if you "do it wrong", and being a Qt-specific problem, > we better not offer too many ways that could have unpleasant drawbacks. > > > My 2 c, > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > From thiago.macieira at intel.com Fri Oct 26 23:05:32 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Oct 2018 14:05:32 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: <9241797.PmYgKvIYqj@tjmaciei-mobl1> On Friday, 26 October 2018 11:39:52 PDT Jason H wrote: > How do we prevent that scenario, what is essentially a social > Denial-of-Service (denial of community?) attack? If we adopt a > Conenant-based language we have to consider this attack vector. It has > already happened in other projects - it is not a hypothetical. We prevent this scenario by having sensible people in the CoC Committee, who will address the problem appropriately. And will remind the person posting the complaint of the story of the boy who cried "wolf". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Oct 26 23:13:02 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Oct 2018 14:13:02 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <2213770.76mU4ngG7U@tjmaciei-mobl1> Message-ID: <2069800.qSaBZiJxKM@tjmaciei-mobl1> On Friday, 26 October 2018 11:40:14 PDT NIkolai Marchenko wrote: > I have to disagree. As I see it: she has spent considerable amount of time > drafting the exact text to allow her to bully projects. > Have you spent as much time analyzing all of the potential pitfalls she may > or may not have inserted into this document? I have read the text assuming it was written and adopted in good faith, which is also how the people in the Linux kernel's TAB as well as whomever we empower in the Qt Project would. That's why the decisions are left to humans, not a script. > She's a malicious person and not second guessign her Code is a mistake. Let's assume for the sake of the argument that the text was written with ill- intent and let's ignore the taint that it would cause us just by adopting it: what's the worst that could happen? The interpretation of the CoC is left to the community that *is* part of the project, not the text's author. I believe the worst that could happen is an argument on the original spirit of the text versus our interpretation of it. But the Qt Project makes the decision, not the original author, so our opinion of what it is meant to say has more weight. So I don't think this is a danger. > Yes, indeed, is the text good? This has to be analyzed: in depth. And I > would still probably avoid using hers. And personally I'm leaning in favour of KDE's. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From enmarantispam at gmail.com Fri Oct 26 23:22:12 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Sat, 27 Oct 2018 00:22:12 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2069800.qSaBZiJxKM@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <2213770.76mU4ngG7U@tjmaciei-mobl1> <2069800.qSaBZiJxKM@tjmaciei-mobl1> Message-ID: > Let's assume for the sake of the argument that the text was written with ill- intent and let's ignore the taint that it would cause us just by adopting it: what's the worst that could happen? The interpretation of the CoC is left to the community that *is* part of the project, not the text's author. Very simple. Once someone like her tries to exploit the vulnerabilities community have created by adopting this document, the Qt project will likely shut them down with a simple "no, you are not being reasonable". But being unreasonable, this person will immediately blast Qt Community for not adhering to code of conduct and doubts will arise both inside and outside. Depending on how persistent they are, it could become a full blown media storm tarnishing the community's image. This could all have been avoided by just not letting those people assume Qt picked _their_ Code. And whatever Qt Community thinks, they _will_ assume that it is their code that has been picked and will hold Qt liable to that. On Sat, Oct 27, 2018 at 12:13 AM Thiago Macieira wrote: > On Friday, 26 October 2018 11:40:14 PDT NIkolai Marchenko wrote: > > I have to disagree. As I see it: she has spent considerable amount of > time > > drafting the exact text to allow her to bully projects. > > Have you spent as much time analyzing all of the potential pitfalls she > may > > or may not have inserted into this document? > > I have read the text assuming it was written and adopted in good faith, > which > is also how the people in the Linux kernel's TAB as well as whomever we > empower in the Qt Project would. That's why the decisions are left to > humans, > not a script. > > > She's a malicious person and not second guessign her Code is a mistake. > > Let's assume for the sake of the argument that the text was written with > ill- > intent and let's ignore the taint that it would cause us just by adopting > it: > what's the worst that could happen? The interpretation of the CoC is left > to > the community that *is* part of the project, not the text's author. > > I believe the worst that could happen is an argument on the original > spirit of > the text versus our interpretation of it. But the Qt Project makes the > decision, not the original author, so our opinion of what it is meant to > say > has more weight. > > So I don't think this is a danger. > > > Yes, indeed, is the text good? This has to be analyzed: in depth. And I > > would still probably avoid using hers. > > And personally I'm leaning in favour of KDE's. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Oct 26 23:28:15 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Oct 2018 14:28:15 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <2213770.76mU4ngG7U@tjmaciei-mobl1> Message-ID: <2232345.ip5vFvkopD@tjmaciei-mobl1> On Friday, 26 October 2018 12:25:50 PDT Jason H wrote: > Thiago, > > Here's a link that kinda puts it together: > https://lulz.com/linux-devs-threaten-killswitch-coc-controversy-1252/ > (Scroll to "The Controversy" and the "rape apologist" Sage Sharp tweet) I know of the controversy and find Sage's tweet to be of extremely poor judgment, given the situation that originally caused them to find Ted Ts'o an apologist. I know both and I fail to see how the actions could have led to such an escalation. This is very unfortunate. I agree with the tweet replies quoted in the article: the Sage's tweet was out of bounds and a violation of the CoC. Fortunately, they are not part of the kernel community anymore, so the Linux TAB does not have to do anything. The post says: "1. Insertion of the CoC into other projects has heralded witch hunts where good contributors are removed over trivial matters or even events that happened a long time ago." There's a difference between triggering witch hunts and successful removal of contributors. The fact that the CoC and a reporting mechanism exist can lead to their being abused. But I stand by my argument that the final decision is left to existing, trusted members of the project's community and that stops the abuse from getting out of hand. > I didn't realize this was a thing of "defeat". I have concerns, based on > actual events, that I want resolved. That's fine. I was reacting to your "my mind is made up", which it makes you sound like you will not change your position and no compromise is possible, short of not adopting a CoC at all. > I do respectfully disagree on whether or not an author is relevant to > considering a work. In this case the author has a track record of attacking > members in open source projects and arguing against meritocracy. Is the > text good? There is a lot I agree with, but there are things in it that > cross the line for me. I think we can come to an agreement, but not with > invoking the Covenant in its current form. Please also note that the attack against meritocracy is more nuanced than it appears at first sight. I don't have more information on this -- I will go inform myself about it -- so until then I will not comment. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Oct 26 23:35:11 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Oct 2018 14:35:11 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <2213770.76mU4ngG7U@tjmaciei-mobl1> Message-ID: <2705117.ReUGEIRvoK@tjmaciei-mobl1> On Friday, 26 October 2018 12:28:42 PDT Alexey Andreyev wrote: > > I personally think those situations explain why we need a CoC in the > > first place and why the judgment on such situations is very subjective, > best left to humans, not to a script. And the deliberations should not be > in a public forum, like a GitHub issue. > > If mentioned situations best left to humans, what is current CoC for? If > deliberations should be limited, who could have access to it? The deliberation is left to humans, but the ground rules are written so that all participants know what is expected of them and to give them the reassurance that their grievances will be heard (not that there'll be action taken). If we took your argument to the extreme, then why would we need a Constitution if we have judges? As for who can have access to it or any other methods of checking their power, I don't know. Do you trust our Security mailing list? Why wouldn't you trust the CoC board? How can we add those? > > Isn't it showing that it's *working*? > > I guess not, not the current version of the CoC at least. Communities are > spending resources instead of working on other tasks. If discussed > situations be left to humans in the end with current document, we could > just state simple one-liner instead: "be conscious and think about future > consequences", -- to minimize CoC problems at least. > > As I said previously, I agree we should work together on a better version. > I guess Qt people could do it. I would rather we not write a text ourselves, but find something we're comfortable with. That would be an extreme effort whose resources could be best used elsewhere. If the CC is such a hot topic, a magnet because of its author's actions, let's look at others. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From private at bernhard-lindner.de Sat Oct 27 00:02:09 2018 From: private at bernhard-lindner.de (Bernhard Lindner) Date: Sat, 27 Oct 2018 00:02:09 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <3844322.YypU1izrmg@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> Message-ID: <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> > > I wish any one discussion about Qt software quality would have attracted so > > much attention, passion and effort as this CoC topic. > > There are plenty of technical threads that have had more emails sent than > this. Look at the ones about the buildsystem, for a recent example. I didn't say "technical". Also I didn't say "number of e-mails". Anyway I think engineering and politics should be separated. On any level. Politics is extremly harmful to engineering. CoCs are always political. -- Best Regards, Bernhard Lindner From thiago.macieira at intel.com Sat Oct 27 00:07:33 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Oct 2018 15:07:33 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> Message-ID: <7304455.ZYRPdxLY82@tjmaciei-mobl1> On Friday, 26 October 2018 15:02:09 PDT Bernhard Lindner wrote: > Anyway I think engineering and politics should be separated. On any level. > Politics is extremly harmful to engineering. CoCs are always political. You are correct. But the only mailing list with sufficient representation of the community is this one. We don't have to like discussing this, but it seems necessary that we do. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From private at bernhard-lindner.de Sat Oct 27 00:39:40 2018 From: private at bernhard-lindner.de (Bernhard Lindner) Date: Sat, 27 Oct 2018 00:39:40 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <7304455.ZYRPdxLY82@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> Message-ID: <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> > But the only mailing list with sufficient representation of the community is > this one. We don't have to like discussing this, but it seems necessary that > we do. Well, then let me give you my simple minded opinion on this topic, an engineers opinion: Do not introduce a CoC. Resisting to have anything and everything in black and white is hard and is not popular and surely not zeitgeist but sometimes the better way. Please do not make me discuss about that as well, I prefer to wrangle with item delegate code ;) -- Best regards, Bernhard Lindner From yetanotherandreyev at gmail.com Sat Oct 27 00:57:41 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Sat, 27 Oct 2018 01:57:41 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2705117.ReUGEIRvoK@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <2213770.76mU4ngG7U@tjmaciei-mobl1> <2705117.ReUGEIRvoK@tjmaciei-mobl1> Message-ID: Thank you for your answers, Thiago! > If we took your argument to the extreme, then why would we need a Constitution > if we have judges? As I said, I'm not against any CoC by default. I just tried to express that professional judges is not an excuse to not work on a better constitution. Not sure it is appropriate analogy though. Is CoC is just a light welcome recommendations that is not going to be used by CoC board at making desicions? Or is it definite rules that we need to follow? If it's light enough in terms of CoC board possible actions, why bother adding controvertial details about discrimination for example? It's not clear about the stringency of the document for me and how to use it for now. > Do you trust our Security mailing list? Yes, I do. And I'm going to trust CoC board, but I do not want to legitimate things that could easily be misused against community members and against CoC board too > I would rather we not write a text ourselves, but find something we're comfortable with. That would be an extreme effort whose resources could be best used elsewhere. > If the CC is such a hot topic, a magnet because of its author's actions, let's look at others. I agree about reusing some working CoC is good idea. Not sure that there's one yet. сб, 27 окт. 2018 г. в 0:35, Thiago Macieira : > On Friday, 26 October 2018 12:28:42 PDT Alexey Andreyev wrote: > > > I personally think those situations explain why we need a CoC in the > > > > first place and why the judgment on such situations is very subjective, > > best left to humans, not to a script. And the deliberations should not be > > in a public forum, like a GitHub issue. > > > > If mentioned situations best left to humans, what is current CoC for? If > > deliberations should be limited, who could have access to it? > > The deliberation is left to humans, but the ground rules are written so > that > all participants know what is expected of them and to give them the > reassurance that their grievances will be heard (not that there'll be > action > taken). > > If we took your argument to the extreme, then why would we need a > Constitution > if we have judges? > > As for who can have access to it or any other methods of checking their > power, > I don't know. Do you trust our Security mailing list? Why wouldn't you > trust > the CoC board? How can we add those? > > > > Isn't it showing that it's *working*? > > > > I guess not, not the current version of the CoC at least. Communities are > > spending resources instead of working on other tasks. If discussed > > situations be left to humans in the end with current document, we could > > just state simple one-liner instead: "be conscious and think about future > > consequences", -- to minimize CoC problems at least. > > > > As I said previously, I agree we should work together on a better > version. > > I guess Qt people could do it. > > I would rather we not write a text ourselves, but find something we're > comfortable with. That would be an extreme effort whose resources could be > best used elsewhere. > > If the CC is such a hot topic, a magnet because of its author's actions, > let's > look at others. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sat Oct 27 02:01:50 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Oct 2018 17:01:50 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> Message-ID: <1635690.gPX8EbFp9O@tjmaciei-mobl1> On Friday, 26 October 2018 15:39:40 PDT Bernhard Lindner wrote: > > But the only mailing list with sufficient representation of the community > > is this one. We don't have to like discussing this, but it seems > > necessary that we do. > > Well, then let me give you my simple minded opinion on this topic, an > engineers opinion: Do not introduce a CoC. > > Resisting to have anything and everything in black and white is hard and is > not popular and surely not zeitgeist but sometimes the better way. Thanks Bernhard Your opinion is noted and is no less important than anyone else's. > Please do not make me discuss about that as well, I prefer to wrangle with > item delegate code ;) :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Oct 26 20:45:27 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Oct 2018 11:45:27 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: <3844322.YypU1izrmg@tjmaciei-mobl1> On Friday, 26 October 2018 10:53:18 PDT Bernhard Lindner wrote: > I wish any one discussion about Qt software quality would have attracted so > much attention, passion and effort as this CoC topic. There are plenty of technical threads that have had more emails sent than this. Look at the ones about the buildsystem, for a recent example. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Oct 27 07:53:08 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Oct 2018 22:53:08 -0700 Subject: [Development] There are staged stuff in the CI for now close to 20 hours Message-ID: <24920334.MI8HZKdNHf@tjmaciei-mobl1> -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at qt.io Sat Oct 27 11:40:37 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Sat, 27 Oct 2018 09:40:37 +0000 Subject: [Development] There are staged stuff in the CI for now close to 20 hours In-Reply-To: <24920334.MI8HZKdNHf@tjmaciei-mobl1> References: <24920334.MI8HZKdNHf@tjmaciei-mobl1> Message-ID: <3A75B038-F0C8-4C95-B71D-7BD36F8187BB@qt.io> Indeed, the CI appears to be down as a whole. There is one single change in integrating state and that since yesterday, so it’s certainly not processing. Simon > On 27. Oct 2018, at 07:53, Thiago Macieira wrote: > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From olivier at woboq.com Sat Oct 27 13:37:38 2018 From: olivier at woboq.com (Olivier Goffart) Date: Sat, 27 Oct 2018 13:37:38 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> <4b21d498-c513-53e7-5c20-2e8c88aeb0db@kdab.com> Message-ID: <34556951-f628-6499-ee3d-3b05b69570d6@woboq.com> On 10/26/18 10:26 PM, Elvis Stansvik wrote: > For completely other reasons, I came across "Range-based for > statements with initializer" today: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0614r1.html > > With that, the Qt best practice could become > > for (const auto list = getQList(); const auto &v : list) { > ... > } > > Which may or may not be pretty, but avoids the extra line of code and > keeps the scope clean. > We could even wrap this in a macro for convenience. We would call that macro 'foreach' for example. Ah no, wait, this name is already taken by a macro that does exactly that :-) Jokes aside, I think we still should let users use Q_FOREACH for implicitly shared containers. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From elvstone at gmail.com Sat Oct 27 14:52:48 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Sat, 27 Oct 2018 14:52:48 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <34556951-f628-6499-ee3d-3b05b69570d6@woboq.com> References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> <4b21d498-c513-53e7-5c20-2e8c88aeb0db@kdab.com> <34556951-f628-6499-ee3d-3b05b69570d6@woboq.com> Message-ID: Den lör 27 okt. 2018 kl 13:37 skrev Olivier Goffart : > > On 10/26/18 10:26 PM, Elvis Stansvik wrote: > > For completely other reasons, I came across "Range-based for > > statements with initializer" today: > > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0614r1.html > > > > With that, the Qt best practice could become > > > > for (const auto list = getQList(); const auto &v : list) { > > ... > > } > > > > Which may or may not be pretty, but avoids the extra line of code and > > keeps the scope clean. > > > > We could even wrap this in a macro for convenience. We would call that macro > 'foreach' for example. > Ah no, wait, this name is already taken by a macro that does exactly that :-) :) > > Jokes aside, I think we still should let users use Q_FOREACH for implicitly > shared containers. Yes, I thought that Q_FOREACH was slated for deprecation though. But maybe that's not set in stone yet? I just found this post by Marc: https://www.kdab.com/goodbye-q_foreach/ Lots of comments there I haven't had time to go through yet, so I bet it's a contentious issue :) Elvis > > -- > Olivier > > Woboq - Qt services and support - https://woboq.com - https://code.woboq.org > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From kevin.kofler at chello.at Sat Oct 27 15:06:06 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 27 Oct 2018 15:06:06 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> <4b21d498-c513-53e7-5c20-2e8c88aeb0db@kdab.com> <34556951-f628-6499-ee3d-3b05b69570d6@woboq.com> Message-ID: Elvis Stansvik wrote: > Den lör 27 okt. 2018 kl 13:37 skrev Olivier Goffart : >> Jokes aside, I think we still should let users use Q_FOREACH for >> implicitly shared containers. > > Yes, I thought that Q_FOREACH was slated for deprecation though. But > maybe that's not set in stone yet? That's his point, it should be undeprecated. Kevin Kofler From Martin.Smith at qt.io Sat Oct 27 15:09:45 2018 From: Martin.Smith at qt.io (Martin Smith) Date: Sat, 27 Oct 2018 13:09:45 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1>, <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> Message-ID: >Well, then let me give you my simple minded opinion on this topic, an engineers >opinion: >Do not introduce a CoC. In that case, if a contributor is mistreated by another contributor, what recourse does the victim have? martin ________________________________________ From: Development on behalf of Bernhard Lindner Sent: Saturday, October 27, 2018 12:39:40 AM To: development at qt-project.org Subject: Re: [Development] QUIP 12: Code of Conduct > But the only mailing list with sufficient representation of the community is > this one. We don't have to like discussing this, but it seems necessary that > we do. Well, then let me give you my simple minded opinion on this topic, an engineers opinion: Do not introduce a CoC. Resisting to have anything and everything in black and white is hard and is not popular and surely not zeitgeist but sometimes the better way. Please do not make me discuss about that as well, I prefer to wrangle with item delegate code ;) -- Best regards, Bernhard Lindner _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From enmarantispam at gmail.com Sat Oct 27 15:17:09 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Sat, 27 Oct 2018 16:17:09 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> Message-ID: Note that installing a conflict resolution authority doesn't need installing a controversial CoC and formalizing every thing a contributor can or cannot do.. True, there won't be formalized and standadized rules for resolution, but aren't people in this project sensible enough, in general, to have the common sense to reach an adequate solution? On Sat, Oct 27, 2018 at 4:10 PM Martin Smith wrote: > >Well, then let me give you my simple minded opinion on this topic, an > engineers > >opinion: > >Do not introduce a CoC. > > In that case, if a contributor is mistreated by another contributor, what > recourse does the victim have? > > martin > > ________________________________________ > From: Development > on behalf of Bernhard Lindner > Sent: Saturday, October 27, 2018 12:39:40 AM > To: development at qt-project.org > Subject: Re: [Development] QUIP 12: Code of Conduct > > > But the only mailing list with sufficient representation of the > community is > > this one. We don't have to like discussing this, but it seems necessary > that > > we do. > > Well, then let me give you my simple minded opinion on this topic, an > engineers opinion: > Do not introduce a CoC. > > Resisting to have anything and everything in black and white is hard and > is not popular > and surely not zeitgeist but sometimes the better way. > > Please do not make me discuss about that as well, I prefer to wrangle with > item delegate > code ;) > > -- > Best regards, > Bernhard Lindner > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Smith at qt.io Sat Oct 27 15:30:12 2018 From: Martin.Smith at qt.io (Martin Smith) Date: Sat, 27 Oct 2018 13:30:12 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> , Message-ID: >Note that installing a conflict resolution authority doesn't need installing a >controversial CoC and formalizing every thing a contributor can or cannot do.. But it does require specifying how to lodge a complaint, which specifies conduct, and it then ought to say something about the kinds of complaints that will be resolved by the resolution authority and the kinds of complaints that will not. That also specifies conduct. >but aren't people in this project sensible enough, in general, to have the >common sense to reach an adequate solution? That's what we're doing now. ________________________________________ From: NIkolai Marchenko Sent: Saturday, October 27, 2018 3:17:09 PM To: Martin Smith Cc: private at bernhard-lindner.de; Qt development mailing list Subject: Re: [Development] QUIP 12: Code of Conduct Note that installing a conflict resolution authority doesn't need installing a controversial CoC and formalizing every thing a contributor can or cannot do.. True, there won't be formalized and standadized rules for resolution, but aren't people in this project sensible enough, in general, to have the common sense to reach an adequate solution? On Sat, Oct 27, 2018 at 4:10 PM Martin Smith > wrote: >Well, then let me give you my simple minded opinion on this topic, an engineers >opinion: >Do not introduce a CoC. In that case, if a contributor is mistreated by another contributor, what recourse does the victim have? martin ________________________________________ From: Development > on behalf of Bernhard Lindner > Sent: Saturday, October 27, 2018 12:39:40 AM To: development at qt-project.org Subject: Re: [Development] QUIP 12: Code of Conduct > But the only mailing list with sufficient representation of the community is > this one. We don't have to like discussing this, but it seems necessary that > we do. Well, then let me give you my simple minded opinion on this topic, an engineers opinion: Do not introduce a CoC. Resisting to have anything and everything in black and white is hard and is not popular and surely not zeitgeist but sometimes the better way. Please do not make me discuss about that as well, I prefer to wrangle with item delegate code ;) -- Best regards, Bernhard Lindner _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From elvstone at gmail.com Sat Oct 27 15:39:01 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Sat, 27 Oct 2018 15:39:01 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> <4b21d498-c513-53e7-5c20-2e8c88aeb0db@kdab.com> <34556951-f628-6499-ee3d-3b05b69570d6@woboq.com> Message-ID: Den lör 27 okt. 2018 kl 15:06 skrev Kevin Kofler : > > Elvis Stansvik wrote: > > Den lör 27 okt. 2018 kl 13:37 skrev Olivier Goffart : > >> Jokes aside, I think we still should let users use Q_FOREACH for > >> implicitly shared containers. > > > > Yes, I thought that Q_FOREACH was slated for deprecation though. But > > maybe that's not set in stone yet? > > That's his point, it should be undeprecated. Ah, now I see. I finally managed to read all the comments on that post, and I definitely don't want to open that can of worms here again. I'm fine with Guiseppes answers to my initial question, a qMoveToConst probably wasn't a good idea in the first place. Elvis > > Kevin Kofler > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From kshegunov at gmail.com Sat Oct 27 15:48:49 2018 From: kshegunov at gmail.com (Konstantin Shegunov) Date: Sat, 27 Oct 2018 16:48:49 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> Message-ID: On Sat, Oct 27, 2018 at 4:09 PM Martin Smith wrote: > In that case, if a contributor is mistreated by another contributor, what > recourse does the victim have? > 1) To contact the contributor first and try to resolve the issue civilly. 2) To seek help with a third party (another contributor) who is known to the alleged victim and who can act as mediator to try an resolve it. 3) If 1) and 2) don't work he/she may also bring it to the attention of the community (e.g. the mailing list). The community is then free to react or not to react. The implication that currently, if you're feeling mistreated, it's impossible to act (respectfully) against harassment seems rather far-fetched to me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Smith at qt.io Sat Oct 27 15:55:59 2018 From: Martin.Smith at qt.io (Martin Smith) Date: Sat, 27 Oct 2018 13:55:59 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> , Message-ID: >1) To contact the contributor first and try to resolve the issue civilly. >2) To seek help with a third party (another contributor) who is known to the >alleged victim and who can act as mediator to try an resolve it. >3) If 1) and 2) don't work he/she may also bring it to the attention of the >community (e.g. the mailing list). The community is then free to react or not to >react. You just specified a code of conduct. The problem with your code of conduct is that it isn't guaranteed to end in resolution. >The implication that currently, if you're feeling mistreated, it's impossible to act >(respectfully) against harassment seems rather far-fetched to me. But that isn't the implication. The implication is that a mistreated person can take the actions you have specified, and the result can be that the mistreatment, real or not, is not resolved. ________________________________________ From: Konstantin Shegunov Sent: Saturday, October 27, 2018 3:48:49 PM To: Martin Smith Cc: development at qt-project.org Subject: Re: [Development] QUIP 12: Code of Conduct On Sat, Oct 27, 2018 at 4:09 PM Martin Smith > wrote: In that case, if a contributor is mistreated by another contributor, what recourse does the victim have? 1) To contact the contributor first and try to resolve the issue civilly. 2) To seek help with a third party (another contributor) who is known to the alleged victim and who can act as mediator to try an resolve it. 3) If 1) and 2) don't work he/she may also bring it to the attention of the community (e.g. the mailing list). The community is then free to react or not to react. The implication that currently, if you're feeling mistreated, it's impossible to act (respectfully) against harassment seems rather far-fetched to me. From enmarantispam at gmail.com Sat Oct 27 16:03:41 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Sat, 27 Oct 2018 17:03:41 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> Message-ID: I am yet to hear an answer about what is going to be done in case the person mistreating is an active contributor. Will you chose potential harm, over actual benefit of having such a person on the project? The edge case being, for example, if a module maintainer is mistreating someone for whatever reason. The other person can just stop trying to interact with that maintainer, but I fail to see how removing a maintainer over a potential benefit of someone not being mistreated actually benefits the project. I've heard from people in this thread that it _is_ a problem you are trying to sovle and there _have _ been mistreatment. Now, I am not asking for dirty laundry, but isn't community supposed to know at least in broad strokes, the kind of problems yo uare even tring to solve before actually voting on anything? Maybe the community have a better answer for these specific problems? On Sat, Oct 27, 2018 at 4:56 PM Martin Smith wrote: > > >1) To contact the contributor first and try to resolve the issue civilly. > >2) To seek help with a third party (another contributor) who is known to > the > >alleged victim and who can act as mediator to try an resolve it. > >3) If 1) and 2) don't work he/she may also bring it to the attention of > the > >community (e.g. the mailing list). The community is then free to react or > not to > >react. > > You just specified a code of conduct. The problem with your code of > conduct is that it isn't guaranteed to end in resolution. > > >The implication that currently, if you're feeling mistreated, it's > impossible to act > >(respectfully) against harassment seems rather far-fetched to me. > > But that isn't the implication. The implication is that a mistreated > person can take the actions you have specified, and the result can be that > the mistreatment, real or not, is not resolved. > > ________________________________________ > From: Konstantin Shegunov > Sent: Saturday, October 27, 2018 3:48:49 PM > To: Martin Smith > Cc: development at qt-project.org > Subject: Re: [Development] QUIP 12: Code of Conduct > > On Sat, Oct 27, 2018 at 4:09 PM Martin Smith Martin.Smith at qt.io>> wrote: > In that case, if a contributor is mistreated by another contributor, what > recourse does the victim have? > > 1) To contact the contributor first and try to resolve the issue civilly. > 2) To seek help with a third party (another contributor) who is known to > the alleged victim and who can act as mediator to try an resolve it. > 3) If 1) and 2) don't work he/she may also bring it to the attention of > the community (e.g. the mailing list). The community is then free to react > or not to react. > > The implication that currently, if you're feeling mistreated, it's > impossible to act (respectfully) against harassment seems rather > far-fetched to me. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Smith at qt.io Sat Oct 27 16:53:20 2018 From: Martin.Smith at qt.io (Martin Smith) Date: Sat, 27 Oct 2018 14:53:20 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> , Message-ID: >I am yet to hear an answer about what is going to be done in case the person >mistreating is an active contributor. >Will you chose potential harm, over actual benefit of having such a person on the >project? Active contributors who abuse others should be treated the same as inactive contributors who abuse others. What would be done would of course depend on what the abuser did. I suppose the abuser (active contributor or not) would be informed as to what he/she did wrong and would be told to stop doing it. Your remarks seem to mean you would rather ignore harm to get the benefit. I hope that's not what you mean. Being a super contributor doesn't buy one the privilege of being an asshole to others. ________________________________________ From: NIkolai Marchenko Sent: Saturday, October 27, 2018 4:03:41 PM To: Martin Smith Cc: Konstantin Shegunov; Qt development mailing list Subject: Re: [Development] QUIP 12: Code of Conduct I am yet to hear an answer about what is going to be done in case the person mistreating is an active contributor. Will you chose potential harm, over actual benefit of having such a person on the project? The edge case being, for example, if a module maintainer is mistreating someone for whatever reason. The other person can just stop trying to interact with that maintainer, but I fail to see how removing a maintainer over a potential benefit of someone not being mistreated actually benefits the project. I've heard from people in this thread that it _is_ a problem you are trying to sovle and there _have _ been mistreatment. Now, I am not asking for dirty laundry, but isn't community supposed to know at least in broad strokes, the kind of problems yo uare even tring to solve before actually voting on anything? Maybe the community have a better answer for these specific problems? On Sat, Oct 27, 2018 at 4:56 PM Martin Smith > wrote: >1) To contact the contributor first and try to resolve the issue civilly. >2) To seek help with a third party (another contributor) who is known to the >alleged victim and who can act as mediator to try an resolve it. >3) If 1) and 2) don't work he/she may also bring it to the attention of the >community (e.g. the mailing list). The community is then free to react or not to >react. You just specified a code of conduct. The problem with your code of conduct is that it isn't guaranteed to end in resolution. >The implication that currently, if you're feeling mistreated, it's impossible to act >(respectfully) against harassment seems rather far-fetched to me. But that isn't the implication. The implication is that a mistreated person can take the actions you have specified, and the result can be that the mistreatment, real or not, is not resolved. ________________________________________ From: Konstantin Shegunov > Sent: Saturday, October 27, 2018 3:48:49 PM To: Martin Smith Cc: development at qt-project.org Subject: Re: [Development] QUIP 12: Code of Conduct On Sat, Oct 27, 2018 at 4:09 PM Martin Smith >> wrote: In that case, if a contributor is mistreated by another contributor, what recourse does the victim have? 1) To contact the contributor first and try to resolve the issue civilly. 2) To seek help with a third party (another contributor) who is known to the alleged victim and who can act as mediator to try an resolve it. 3) If 1) and 2) don't work he/she may also bring it to the attention of the community (e.g. the mailing list). The community is then free to react or not to react. The implication that currently, if you're feeling mistreated, it's impossible to act (respectfully) against harassment seems rather far-fetched to me. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From yetanotherandreyev at gmail.com Sat Oct 27 17:21:10 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Sat, 27 Oct 2018 18:21:10 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> Message-ID: I agree not interacting is probably not a solution and your contribution without other details is not an excuse. But I think existing CoC have problems. There are statements everywhere about discrimination protection for example which are very controversial. The problem with that in other communities was already mentioned. I disagree it's not a big deal and have more benefits than negative aspect. We provided a lot of problematic real-life examples, since it's still hard to prove positive impact. I guess we should try to develop better version, I don't see real-life benefits from existing CoC at other communities. сб, 27 окт. 2018 г., 17:53 Martin Smith : > >I am yet to hear an answer about what is going to be done in case the > person > >mistreating is an active contributor. > >Will you chose potential harm, over actual benefit of having such a > person on the > >project? > > Active contributors who abuse others should be treated the same as > inactive contributors who abuse others. What would be done would of course > depend on what the abuser did. I suppose the abuser (active contributor or > not) would be informed as to what he/she did wrong and would be told to > stop doing it. > > Your remarks seem to mean you would rather ignore harm to get the benefit. > I hope that's not what you mean. Being a super contributor doesn't buy one > the privilege of being an asshole to others. > > ________________________________________ > From: NIkolai Marchenko > Sent: Saturday, October 27, 2018 4:03:41 PM > To: Martin Smith > Cc: Konstantin Shegunov; Qt development mailing list > Subject: Re: [Development] QUIP 12: Code of Conduct > > I am yet to hear an answer about what is going to be done in case the > person mistreating is an active contributor. > Will you chose potential harm, over actual benefit of having such a person > on the project? > > The edge case being, for example, if a module maintainer is mistreating > someone for whatever reason. > The other person can just stop trying to interact with that maintainer, > but I fail to see how removing a maintainer over a potential benefit of > someone not being mistreated actually benefits the project. > > I've heard from people in this thread that it _is_ a problem you are > trying to sovle and there _have _ been mistreatment. > Now, I am not asking for dirty laundry, but isn't community supposed to > know at least in broad strokes, the kind of problems yo uare even tring to > solve before actually voting on anything? > Maybe the community have a better answer for these specific problems? > > On Sat, Oct 27, 2018 at 4:56 PM Martin Smith Martin.Smith at qt.io>> wrote: > > >1) To contact the contributor first and try to resolve the issue civilly. > >2) To seek help with a third party (another contributor) who is known to > the > >alleged victim and who can act as mediator to try an resolve it. > >3) If 1) and 2) don't work he/she may also bring it to the attention of > the > >community (e.g. the mailing list). The community is then free to react or > not to > >react. > > You just specified a code of conduct. The problem with your code of > conduct is that it isn't guaranteed to end in resolution. > > >The implication that currently, if you're feeling mistreated, it's > impossible to act > >(respectfully) against harassment seems rather far-fetched to me. > > But that isn't the implication. The implication is that a mistreated > person can take the actions you have specified, and the result can be that > the mistreatment, real or not, is not resolved. > > ________________________________________ > From: Konstantin Shegunov >> > Sent: Saturday, October 27, 2018 3:48:49 PM > To: Martin Smith > Cc: development at qt-project.org > Subject: Re: [Development] QUIP 12: Code of Conduct > > On Sat, Oct 27, 2018 at 4:09 PM Martin Smith Martin.Smith at qt.io>>> > wrote: > In that case, if a contributor is mistreated by another contributor, what > recourse does the victim have? > > 1) To contact the contributor first and try to resolve the issue civilly. > 2) To seek help with a third party (another contributor) who is known to > the alleged victim and who can act as mediator to try an resolve it. > 3) If 1) and 2) don't work he/she may also bring it to the attention of > the community (e.g. the mailing list). The community is then free to react > or not to react. > > The implication that currently, if you're feeling mistreated, it's > impossible to act (respectfully) against harassment seems rather > far-fetched to me. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iamsergio at gmail.com Sat Oct 27 17:27:44 2018 From: iamsergio at gmail.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Sat, 27 Oct 2018 16:27:44 +0100 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> <4b21d498-c513-53e7-5c20-2e8c88aeb0db@kdab.com> <34556951-f628-6499-ee3d-3b05b69570d6@woboq.com> Message-ID: > Den lör 27 okt. 2018 kl 13:37 skrev Olivier Goffart : > > Jokes aside, I think we still should let users use Q_FOREACH for implicitly > > shared containers. But what's the percentage of Qt developers that understand the subtleties between Q_FOREACH and range-for ? Having a toolbox with two similar-but-not-quite constructs is bad for less seasoned users. I prefer explicitly assigning the container to a const local variable instead of relying in the magic behind macros. On Sat, Oct 27, 2018 at 1:53 PM Elvis Stansvik wrote: > Yes, I thought that Q_FOREACH was slated for deprecation though. But > maybe that's not set in stone yet? It is, see Qt's documentation: "Since Qt 5.7, the use of this macro is discouraged. It will be removed in a future version of Qt" Regards, Sérgio From iamsergio at gmail.com Sat Oct 27 17:33:30 2018 From: iamsergio at gmail.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Sat, 27 Oct 2018 16:33:30 +0100 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: Message-ID: On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik wrote: > > Hi all (first post), Welcome :) > In Qt 5.7+ there's qAsConst, an std::as_const implementation for those > who are not on C++17 yet, which is convenient for iterating over Qt > containers using range-based for loops without causing a detach. > > For good reasons there's no version of qAsConst that takes an rvalue > reference, so you can't do e.g. for (auto foo : > qAsConst(returnsQtContainer()) { ... }. Instead you must do const > auto stuff = returnsQtContainer(); for (auto foo : stuff) { ... }. Should we instead just encourage people to make returnsQtContainer() return a const container ? Not sure what's the reason we don't do it in Qt. It's frowned upon for regular value types, but our containers are special. Regards, Sergio From elvstone at gmail.com Sat Oct 27 17:46:00 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Sat, 27 Oct 2018 17:46:00 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: Message-ID: Den lör 27 okt. 2018 kl 17:33 skrev Sérgio Martins : > > On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik wrote: > > > > Hi all (first post), > > Welcome :) > > > In Qt 5.7+ there's qAsConst, an std::as_const implementation for those > > who are not on C++17 yet, which is convenient for iterating over Qt > > containers using range-based for loops without causing a detach. > > > > For good reasons there's no version of qAsConst that takes an rvalue > > reference, so you can't do e.g. for (auto foo : > > qAsConst(returnsQtContainer()) { ... }. Instead you must do const > > auto stuff = returnsQtContainer(); for (auto foo : stuff) { ... }. > > Should we instead just encourage people to make returnsQtContainer() > return a const container ? > Not sure what's the reason we don't do it in Qt. It's frowned upon for > regular value types, but our containers are special. It was the very last comment on that blog post, to which Marc answered: "Making returned containers const inhibits move semantics, because const rvalues do not bind to the mutable rvalue references that move constructors and move assignment operators use." Elvis > > Regards, > Sergio From Martin.Smith at qt.io Sat Oct 27 17:51:47 2018 From: Martin.Smith at qt.io (Martin Smith) Date: Sat, 27 Oct 2018 15:51:47 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> , Message-ID: Having observed this discussion since the beginning... Apparently there are cases where contributors are being abused by other contributors. Currently, there is no formal procedure for resolving these cases of alleged abuse. Those objecting to establishing a CoC the purpose of which will be to establish that formal procedure to resolve cases of alleged dispute, are objecting because the CoC might abuse someone accused of abuse. Those objecting claim we are all able to resolve these abuse problems without a code of conduct, but those of us empowered, under a CoC, to resolve cases of abuse, would suddenly lose their ability to resolve abuse problems and would instead use the CoC to abuse alleged abusers. That's what it looks like to me. ________________________________________ From: Alexey Andreyev Sent: Saturday, October 27, 2018 5:21:10 PM To: Martin Smith Cc: NIkolai “Zeks” Marchenko; Qt development mailing list Subject: Re: [Development] QUIP 12: Code of Conduct I agree not interacting is probably not a solution and your contribution without other details is not an excuse. But I think existing CoC have problems. There are statements everywhere about discrimination protection for example which are very controversial. The problem with that in other communities was already mentioned. I disagree it's not a big deal and have more benefits than negative aspect. We provided a lot of problematic real-life examples, since it's still hard to prove positive impact. I guess we should try to develop better version, I don't see real-life benefits from existing CoC at other communities. сб, 27 окт. 2018 г., 17:53 Martin Smith >: >I am yet to hear an answer about what is going to be done in case the person >mistreating is an active contributor. >Will you chose potential harm, over actual benefit of having such a person on the >project? Active contributors who abuse others should be treated the same as inactive contributors who abuse others. What would be done would of course depend on what the abuser did. I suppose the abuser (active contributor or not) would be informed as to what he/she did wrong and would be told to stop doing it. Your remarks seem to mean you would rather ignore harm to get the benefit. I hope that's not what you mean. Being a super contributor doesn't buy one the privilege of being an asshole to others. ________________________________________ From: NIkolai Marchenko > Sent: Saturday, October 27, 2018 4:03:41 PM To: Martin Smith Cc: Konstantin Shegunov; Qt development mailing list Subject: Re: [Development] QUIP 12: Code of Conduct I am yet to hear an answer about what is going to be done in case the person mistreating is an active contributor. Will you chose potential harm, over actual benefit of having such a person on the project? The edge case being, for example, if a module maintainer is mistreating someone for whatever reason. The other person can just stop trying to interact with that maintainer, but I fail to see how removing a maintainer over a potential benefit of someone not being mistreated actually benefits the project. I've heard from people in this thread that it _is_ a problem you are trying to sovle and there _have _ been mistreatment. Now, I am not asking for dirty laundry, but isn't community supposed to know at least in broad strokes, the kind of problems yo uare even tring to solve before actually voting on anything? Maybe the community have a better answer for these specific problems? On Sat, Oct 27, 2018 at 4:56 PM Martin Smith >> wrote: >1) To contact the contributor first and try to resolve the issue civilly. >2) To seek help with a third party (another contributor) who is known to the >alleged victim and who can act as mediator to try an resolve it. >3) If 1) and 2) don't work he/she may also bring it to the attention of the >community (e.g. the mailing list). The community is then free to react or not to >react. You just specified a code of conduct. The problem with your code of conduct is that it isn't guaranteed to end in resolution. >The implication that currently, if you're feeling mistreated, it's impossible to act >(respectfully) against harassment seems rather far-fetched to me. But that isn't the implication. The implication is that a mistreated person can take the actions you have specified, and the result can be that the mistreatment, real or not, is not resolved. ________________________________________ From: Konstantin Shegunov >> Sent: Saturday, October 27, 2018 3:48:49 PM To: Martin Smith Cc: development at qt-project.org> Subject: Re: [Development] QUIP 12: Code of Conduct On Sat, Oct 27, 2018 at 4:09 PM Martin Smith >>>> wrote: In that case, if a contributor is mistreated by another contributor, what recourse does the victim have? 1) To contact the contributor first and try to resolve the issue civilly. 2) To seek help with a third party (another contributor) who is known to the alleged victim and who can act as mediator to try an resolve it. 3) If 1) and 2) don't work he/she may also bring it to the attention of the community (e.g. the mailing list). The community is then free to react or not to react. The implication that currently, if you're feeling mistreated, it's impossible to act (respectfully) against harassment seems rather far-fetched to me. _______________________________________________ Development mailing list Development at qt-project.org> http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From yetanotherandreyev at gmail.com Sat Oct 27 18:04:35 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Sat, 27 Oct 2018 19:04:35 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> Message-ID: Want to add that CoC implementation matters. It's hard to accept and change or revert some rules than. The controversial discrimination protection sentences at least should be carefully discussed. It's not some thing that we could accept as easy as rewrite. сб, 27 окт. 2018 г., 18:51 Martin Smith : > Having observed this discussion since the beginning... > > Apparently there are cases where contributors are being abused by other > contributors. Currently, there is no formal procedure for resolving these > cases of alleged abuse. > > Those objecting to establishing a CoC the purpose of which will be to > establish that formal procedure to resolve cases of alleged dispute, are > objecting because the CoC might abuse someone accused of abuse. > > Those objecting claim we are all able to resolve these abuse problems > without a code of conduct, but those of us empowered, under a CoC, to > resolve cases of abuse, would suddenly lose their ability to resolve abuse > problems and would instead use the CoC to abuse alleged abusers. > > That's what it looks like to me. > > ________________________________________ > From: Alexey Andreyev > Sent: Saturday, October 27, 2018 5:21:10 PM > To: Martin Smith > Cc: NIkolai “Zeks” Marchenko; Qt development mailing list > Subject: Re: [Development] QUIP 12: Code of Conduct > > I agree not interacting is probably not a solution and your contribution > without other details is not an excuse. > > But I think existing CoC have problems. > There are statements everywhere about discrimination protection for > example which are very controversial. > > The problem with that in other communities was already mentioned. > I disagree it's not a big deal and have more benefits than negative aspect. > We provided a lot of problematic real-life examples, since it's still hard > to prove positive impact. > > I guess we should try to develop better version, I don't see real-life > benefits from existing CoC at other communities. > > > сб, 27 окт. 2018 г., 17:53 Martin Smith Martin.Smith at qt.io>>: > >I am yet to hear an answer about what is going to be done in case the > person > >mistreating is an active contributor. > >Will you chose potential harm, over actual benefit of having such a > person on the > >project? > > Active contributors who abuse others should be treated the same as > inactive contributors who abuse others. What would be done would of course > depend on what the abuser did. I suppose the abuser (active contributor or > not) would be informed as to what he/she did wrong and would be told to > stop doing it. > > Your remarks seem to mean you would rather ignore harm to get the benefit. > I hope that's not what you mean. Being a super contributor doesn't buy one > the privilege of being an asshole to others. > > ________________________________________ > From: NIkolai Marchenko enmarantispam at gmail.com>> > Sent: Saturday, October 27, 2018 4:03:41 PM > To: Martin Smith > Cc: Konstantin Shegunov; Qt development mailing list > Subject: Re: [Development] QUIP 12: Code of Conduct > > I am yet to hear an answer about what is going to be done in case the > person mistreating is an active contributor. > Will you chose potential harm, over actual benefit of having such a person > on the project? > > The edge case being, for example, if a module maintainer is mistreating > someone for whatever reason. > The other person can just stop trying to interact with that maintainer, > but I fail to see how removing a maintainer over a potential benefit of > someone not being mistreated actually benefits the project. > > I've heard from people in this thread that it _is_ a problem you are > trying to sovle and there _have _ been mistreatment. > Now, I am not asking for dirty laundry, but isn't community supposed to > know at least in broad strokes, the kind of problems yo uare even tring to > solve before actually voting on anything? > Maybe the community have a better answer for these specific problems? > > On Sat, Oct 27, 2018 at 4:56 PM Martin Smith Martin.Smith at qt.io>>> > wrote: > > >1) To contact the contributor first and try to resolve the issue civilly. > >2) To seek help with a third party (another contributor) who is known to > the > >alleged victim and who can act as mediator to try an resolve it. > >3) If 1) and 2) don't work he/she may also bring it to the attention of > the > >community (e.g. the mailing list). The community is then free to react or > not to > >react. > > You just specified a code of conduct. The problem with your code of > conduct is that it isn't guaranteed to end in resolution. > > >The implication that currently, if you're feeling mistreated, it's > impossible to act > >(respectfully) against harassment seems rather far-fetched to me. > > But that isn't the implication. The implication is that a mistreated > person can take the actions you have specified, and the result can be that > the mistreatment, real or not, is not resolved. > > ________________________________________ > From: Konstantin Shegunov >>> > Sent: Saturday, October 27, 2018 3:48:49 PM > To: Martin Smith > Cc: development at qt-project.org development at qt-project.org> > Subject: Re: [Development] QUIP 12: Code of Conduct > > On Sat, Oct 27, 2018 at 4:09 PM Martin Smith Martin.Smith at qt.io> >> Martin.Smith at qt.io>>> wrote: > In that case, if a contributor is mistreated by another contributor, what > recourse does the victim have? > > 1) To contact the contributor first and try to resolve the issue civilly. > 2) To seek help with a third party (another contributor) who is known to > the alleged victim and who can act as mediator to try an resolve it. > 3) If 1) and 2) don't work he/she may also bring it to the attention of > the community (e.g. the mailing list). The community is then free to react > or not to react. > > The implication that currently, if you're feeling mistreated, it's > impossible to act (respectfully) against harassment seems rather > far-fetched to me. > _______________________________________________ > Development mailing list > Development at qt-project.org Development at qt-project.org> > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apoenitz at t-online.de Sat Oct 27 19:25:39 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Sat, 27 Oct 2018 19:25:39 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> Message-ID: <20181027172539.GA20012@klara.mpi.htwm.de> On Sat, Oct 27, 2018 at 01:09:45PM +0000, Martin Smith wrote: > >Well, then let me give you my simple minded opinion on this topic, an engineers > >opinion: > >Do not introduce a CoC. > > In that case, if a contributor is mistreated by another contributor, > what recourse does the victim have? File charges with the relevant authorities. Why should "being a contributor" make a difference? Actions that are considered offenses by a society are typically mentioned in its laws. If something is not forbidden by law it usually means that there is no majority, let alone consensus in that society that this action is an offense. Andre' From apoenitz at t-online.de Sat Oct 27 19:29:31 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Sat, 27 Oct 2018 19:29:31 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: Message-ID: <20181027172931.GB20012@klara.mpi.htwm.de> On Sat, Oct 27, 2018 at 04:33:30PM +0100, Sérgio Martins wrote: > On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik wrote: > > > > Hi all (first post), > > Welcome :) > > > In Qt 5.7+ there's qAsConst, an std::as_const implementation for those > > who are not on C++17 yet, which is convenient for iterating over Qt > > containers using range-based for loops without causing a detach. > > > > For good reasons there's no version of qAsConst that takes an rvalue > > reference, so you can't do e.g. for (auto foo : > > qAsConst(returnsQtContainer()) { ... }. Instead you must do const > > auto stuff = returnsQtContainer(); for (auto foo : stuff) { ... }. > > Should we instead just encourage people to make returnsQtContainer() > return a const container ? This is actually a route we recently took in some cases in Qt Creator's code base. Andre' From Martin.Smith at qt.io Sat Oct 27 19:34:30 2018 From: Martin.Smith at qt.io (Martin Smith) Date: Sat, 27 Oct 2018 17:34:30 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <20181027172539.GA20012@klara.mpi.htwm.de> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> , <20181027172539.GA20012@klara.mpi.htwm.de> Message-ID: >Actions that are considered offenses by a society are typically mentioned >in its laws. If something is not forbidden by law it usually means that >there is no majority, let alone consensus in that society that this action >is an offense. Exactly. Without a CoC, we have no laws, so the implication is we don't consider any behavior an offense. ________________________________________ From: André Pönitz Sent: Saturday, October 27, 2018 7:25:39 PM To: Martin Smith Cc: Bernhard Lindner; development at qt-project.org Subject: Re: [Development] QUIP 12: Code of Conduct On Sat, Oct 27, 2018 at 01:09:45PM +0000, Martin Smith wrote: > >Well, then let me give you my simple minded opinion on this topic, an engineers > >opinion: > >Do not introduce a CoC. > > In that case, if a contributor is mistreated by another contributor, > what recourse does the victim have? File charges with the relevant authorities. Why should "being a contributor" make a difference? Actions that are considered offenses by a society are typically mentioned in its laws. If something is not forbidden by law it usually means that there is no majority, let alone consensus in that society that this action is an offense. Andre' From lars.knoll at qt.io Sat Oct 27 19:48:45 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Sat, 27 Oct 2018 17:48:45 +0000 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <20181027172931.GB20012@klara.mpi.htwm.de> References: <20181027172931.GB20012@klara.mpi.htwm.de> Message-ID: On 27 Oct 2018, at 19:29, André Pönitz > wrote: On Sat, Oct 27, 2018 at 04:33:30PM +0100, Sérgio Martins wrote: On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik > wrote: Hi all (first post), Welcome :) In Qt 5.7+ there's qAsConst, an std::as_const implementation for those who are not on C++17 yet, which is convenient for iterating over Qt containers using range-based for loops without causing a detach. For good reasons there's no version of qAsConst that takes an rvalue reference, so you can't do e.g. for (auto foo : qAsConst(returnsQtContainer()) { ... }. Instead you must do const auto stuff = returnsQtContainer(); for (auto foo : stuff) { ... }. Should we instead just encourage people to make returnsQtContainer() return a const container ? This is actually a route we recently took in some cases in Qt Creator's code base. That might actually make sense. Calling a non const method on the returned temporary object is usually a mistake anyway. And the copy/move assignment to a variable will work with the const object. Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From apoenitz at t-online.de Sat Oct 27 20:37:12 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Sat, 27 Oct 2018 20:37:12 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> <20181027172539.GA20012@klara.mpi.htwm.de> Message-ID: <20181027183712.GA28072@klara.mpi.htwm.de> On Sat, Oct 27, 2018 at 05:34:30PM +0000, Martin Smith wrote: > >Actions that are considered offenses by a society are typically mentioned > >in its laws. If something is not forbidden by law it usually means that > >there is no majority, let alone consensus in that society that this action > >is an offense. > > Exactly. Without a CoC, we have no laws, so the implication > is we don't consider any behavior an offense. I am not aware of a single country without laws. Over here e.g. "insult" is an offense. Andre' From kshegunov at gmail.com Sat Oct 27 21:04:12 2018 From: kshegunov at gmail.com (Konstantin Shegunov) Date: Sat, 27 Oct 2018 22:04:12 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> Message-ID: On Sat, Oct 27, 2018 at 4:56 PM Martin Smith wrote: > You just specified a code of conduct. The problem with your code of > conduct is that it isn't guaranteed to end in resolution. > Oh, it is going to end in A resolution, it may not end the way the offended party may feel just, but that's true also for the proposed text. > But that isn't the implication. > Then I apologize, this is how I interpreted it. The implication is that a mistreated person can take the actions you have > specified, and the result can be that the mistreatment, real or not, is not > resolved. The proposed text can't guarantee resolution either (see below for a reductio ad absurdum). Active contributors who abuse others should be treated the same as inactive > contributors who abuse others. What would be done would of course depend on > what the abuser did. I suppose the abuser (active contributor or not) would > be informed as to what he/she did wrong and would be told to stop doing it. Say we adopt the CC (basically the proposed text) and imagine that the abusive party is an employee of the QtC and has committed heinous acts against a community member. As far as I can tell this is very unlikely, but humor me for a second. As QtC employees' main work is on the Qt project, i.e. writing patches, committing features, writing docs and such, how would is this proposed committee to enforce the CoC? Are they going to plead that the person is taken out of the project, and wouldn't that mean that, basically, he/she can't be an employee for the QtC anymore? And to drive it home, say the head troll had a mental breakdown or something what is the committee to do? Take over the QtC? Just as I said before, I'm not against a CoC in principle. I'm against the CC's text which is quite invasive and badly written. To me KDE's CoC is much more practical in the case of the Qt project. Exactly. Without a CoC, we have no laws, so the implication is we don't > consider any behavior an offense. Laws are bit more complicated than a statement of how people *should* behave. There's also separation of power, mandates, enforcement and laws that control how laws are made. Also there's hierarchy between the laws themselves in case they are in conflict. I suggest we don't venture into that. It's not what binds us to this community to begin with. -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvstone at gmail.com Sat Oct 27 21:07:33 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Sat, 27 Oct 2018 21:07:33 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: <20181027172931.GB20012@klara.mpi.htwm.de> Message-ID: Den lör 27 okt. 2018 kl 19:48 skrev Lars Knoll : > > > > On 27 Oct 2018, at 19:29, André Pönitz wrote: > > On Sat, Oct 27, 2018 at 04:33:30PM +0100, Sérgio Martins wrote: > > On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik wrote: > > > Hi all (first post), > > > Welcome :) > > In Qt 5.7+ there's qAsConst, an std::as_const implementation for those > who are not on C++17 yet, which is convenient for iterating over Qt > containers using range-based for loops without causing a detach. > > For good reasons there's no version of qAsConst that takes an rvalue > reference, so you can't do e.g. for (auto foo : > qAsConst(returnsQtContainer()) { ... }. Instead you must do const > auto stuff = returnsQtContainer(); for (auto foo : stuff) { ... }. > > > Should we instead just encourage people to make returnsQtContainer() > return a const container ? > > > This is actually a route we recently took in some cases in Qt Creator's > code base. > > > That might actually make sense. Calling a non const method on the returned temporary object is usually a mistake anyway. And the copy/move assignment to a variable will work with the const object. Hm, but was Marc not right when he said "Making returned containers const inhibits move semantics, because const rvalues do not bind to the mutable rvalue references that move constructors and move assignment operators use." on his blog? Guess he should jump in here to defend himself :) Elvis > > Cheers, > Lars > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From elvstone at gmail.com Sat Oct 27 21:37:06 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Sat, 27 Oct 2018 21:37:06 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: <20181027172931.GB20012@klara.mpi.htwm.de> Message-ID: Den lör 27 okt. 2018 kl 21:07 skrev Elvis Stansvik : > > Den lör 27 okt. 2018 kl 19:48 skrev Lars Knoll : > > > > > > > > On 27 Oct 2018, at 19:29, André Pönitz wrote: > > > > On Sat, Oct 27, 2018 at 04:33:30PM +0100, Sérgio Martins wrote: > > > > On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik wrote: > > > > > > Hi all (first post), > > > > > > Welcome :) > > > > In Qt 5.7+ there's qAsConst, an std::as_const implementation for those > > who are not on C++17 yet, which is convenient for iterating over Qt > > containers using range-based for loops without causing a detach. > > > > For good reasons there's no version of qAsConst that takes an rvalue > > reference, so you can't do e.g. for (auto foo : > > qAsConst(returnsQtContainer()) { ... }. Instead you must do const > > auto stuff = returnsQtContainer(); for (auto foo : stuff) { ... }. > > > > > > Should we instead just encourage people to make returnsQtContainer() > > return a const container ? > > > > > > This is actually a route we recently took in some cases in Qt Creator's > > code base. > > > > > > That might actually make sense. Calling a non const method on the returned temporary object is usually a mistake anyway. And the copy/move assignment to a variable will work with the const object. > > Hm, but was Marc not right when he said > > "Making returned containers const inhibits move semantics, because > const rvalues do not bind to the mutable rvalue references that move > constructors and move assignment operators use." > > on his blog? > > Guess he should jump in here to defend himself :) Another problem I found when trying to apply this to our code base is that it seems you can't QtConcurrent::run a function returning const T, because internally, ResultStoreBase::addResult looks like template int addResult(int index, const T *result) { if (result == 0) return addResult(index, static_cast(nullptr)); else return addResult(index, static_cast(new T(*result))); } so you'll get an error like /usr/include/x86_64-linux-gnu/qt5/QtCore/qresultstore.h:151: error: static_cast from 'const QVector *' to 'void *' is not allowed return addResult(index, static_cast(new T(*result))); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Just a small downside in our case, but still. Elvis > > Elvis > > > > > Cheers, > > Lars > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development From lars.knoll at qt.io Sat Oct 27 22:07:40 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Sat, 27 Oct 2018 20:07:40 +0000 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: <20181027172931.GB20012@klara.mpi.htwm.de> Message-ID: On 27 Oct 2018, at 21:07, Elvis Stansvik > wrote: Den lör 27 okt. 2018 kl 19:48 skrev Lars Knoll >: On 27 Oct 2018, at 19:29, André Pönitz > wrote: On Sat, Oct 27, 2018 at 04:33:30PM +0100, Sérgio Martins wrote: On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik > wrote: Hi all (first post), Welcome :) In Qt 5.7+ there's qAsConst, an std::as_const implementation for those who are not on C++17 yet, which is convenient for iterating over Qt containers using range-based for loops without causing a detach. For good reasons there's no version of qAsConst that takes an rvalue reference, so you can't do e.g. for (auto foo : qAsConst(returnsQtContainer()) { ... }. Instead you must do const auto stuff = returnsQtContainer(); for (auto foo : stuff) { ... }. Should we instead just encourage people to make returnsQtContainer() return a const container ? This is actually a route we recently took in some cases in Qt Creator's code base. That might actually make sense. Calling a non const method on the returned temporary object is usually a mistake anyway. And the copy/move assignment to a variable will work with the const object. Hm, but was Marc not right when he said "Making returned containers const inhibits move semantics, because const rvalues do not bind to the mutable rvalue references that move constructors and move assignment operators use." on his blog? Guess he should jump in here to defend himself :) No need. He’s right. A move constructor only works with a non const value, as it needs to modify the object. One thing to check however for our containers is how much more expensive the copy is (compared to the move). Cheers, Lars Elvis 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: From thiago.macieira at intel.com Sat Oct 27 22:20:18 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 27 Oct 2018 13:20:18 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: <3713880.AgeDxuVClM@tjmaciei-mobl1> On Saturday, 27 October 2018 12:04:12 PDT Konstantin Shegunov wrote: > Say we adopt the CC (basically the proposed text) and imagine that the > abusive party is an employee of the QtC and has committed heinous acts > against a community member. As far as I can tell this is very unlikely, but > humor me for a second. As QtC employees' main work is on the Qt project, > i.e. writing patches, committing features, writing docs and such, how would > is this proposed committee to enforce the CoC? Are they going to plead that > the person is taken out of the project, and wouldn't that mean that, > basically, he/she can't be an employee for the QtC anymore? And to drive it > home, say the head troll had a mental breakdown or something what is the > committee to do? Take over the QtC? The answer to all of those questions needs to be "yes". Anything short of that means the CoC is powerless and just for show. Whether there's a termination of employment or not is out of scope, since the CoC does not rule TQtC employment and what other work there is inside that company. Note also it applies to any company. If you're not welcome anymore in the community where your employer is asking you to do work, that is going to affect your employment. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Oct 27 22:23:00 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 27 Oct 2018 13:23:00 -0700 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: Message-ID: <1686590.ORQEvNpYvM@tjmaciei-mobl1> On Saturday, 27 October 2018 08:33:30 PDT Sérgio Martins wrote: > Should we instead just encourage people to make returnsQtContainer() > return a const container ? We should not, since the prevents move-construction from happening. You'll pay the cost of two reference counts (one up and one down). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Oct 27 22:35:05 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 27 Oct 2018 13:35:05 -0700 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: Message-ID: <1863110.lurdCQ6cLK@tjmaciei-mobl1> On Saturday, 27 October 2018 13:07:40 PDT Lars Knoll wrote: > No need. He’s right. A move constructor only works with a non const value, > as it needs to modify the object. One thing to check however for our > containers is how much more expensive the copy is (compared to the move). Two atomic operations. https://stackoverflow.com/questions/2538070/atomic-operation-cost https://stackoverflow.com/questions/34660376/atomic-fetch-add-vs-add-performance etc. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kshegunov at gmail.com Sat Oct 27 22:40:42 2018 From: kshegunov at gmail.com (Konstantin Shegunov) Date: Sat, 27 Oct 2018 23:40:42 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <3713880.AgeDxuVClM@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3713880.AgeDxuVClM@tjmaciei-mobl1> Message-ID: On Sat, Oct 27, 2018 at 11:20 PM Thiago Macieira wrote: > The answer to all of those questions needs to be "yes". Anything short of > that > means the CoC is powerless and just for show. > Which was my point exactly. > Whether there's a termination of employment or not is out of scope, since > the > CoC does not rule TQtC employment and what other work there is inside that > company. > Note also it applies to any company. If you're not welcome anymore in the > community where your employer is asking you to do work, that is going to > affect your employment. > I agree. However my argument was that the QtC being a major contributor to the codebase is going to have to abide by the ruling of the proposed committee, which is a significant commitment (and a major nitpick I admit). -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvstone at gmail.com Sat Oct 27 23:14:51 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Sat, 27 Oct 2018 23:14:51 +0200 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <1686590.ORQEvNpYvM@tjmaciei-mobl1> References: <1686590.ORQEvNpYvM@tjmaciei-mobl1> Message-ID: Den lör 27 okt. 2018 kl 22:23 skrev Thiago Macieira : > > On Saturday, 27 October 2018 08:33:30 PDT Sérgio Martins wrote: > > Should we instead just encourage people to make returnsQtContainer() > > return a const container ? > > We should not, since the prevents move-construction from happening. You'll pay > the cost of two reference counts (one up and one down). Alright, rules that out I guess. From the looks of it, it could be ~100 ns. Elvis > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From sierdzio at gmail.com Sun Oct 28 08:47:20 2018 From: sierdzio at gmail.com (Tomasz Siekierda) Date: Sun, 28 Oct 2018 08:47:20 +0100 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3713880.AgeDxuVClM@tjmaciei-mobl1> Message-ID: > The controversial discrimination protection sentences at least should be carefully discussed. It's not some thing that we could accept as easy as rewrite. Hi Alexey, I've just read the QUIP proposal and couldn't find any controversial sentences. Could you elaborate? Which points shall be discussed? On Sat, 27 Oct 2018 at 22:41, Konstantin Shegunov wrote: > > On Sat, Oct 27, 2018 at 11:20 PM Thiago Macieira wrote: >> >> The answer to all of those questions needs to be "yes". Anything short of that >> means the CoC is powerless and just for show. > > > Which was my point exactly. > >> >> Whether there's a termination of employment or not is out of scope, since the >> CoC does not rule TQtC employment and what other work there is inside that >> company. >> >> >> Note also it applies to any company. If you're not welcome anymore in the >> community where your employer is asking you to do work, that is going to >> affect your employment. > > > I agree. However my argument was that the QtC being a major contributor to the codebase is going to have to abide by the ruling of the proposed committee, which is a significant commitment (and a major nitpick I admit). > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Martin.Smith at qt.io Sun Oct 28 09:34:40 2018 From: Martin.Smith at qt.io (Martin Smith) Date: Sun, 28 Oct 2018 08:34:40 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <20181027183712.GA28072@klara.mpi.htwm.de> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> <20181027172539.GA20012@klara.mpi.htwm.de> , <20181027183712.GA28072@klara.mpi.htwm.de> Message-ID: >I am not aware of a single country without laws. >Over here e.g. "insult" is an offense. First, most of us aren't in Germany and don't have the German legal system to protect us. But more to the point, A CoC need not be adequate to deal with actual crimes nor even violations of civil law, because, as you point out, every country has laws to deal with incidents that rise to that level. For dealing with these problems, our CoC can simply state that the committee will refer such incidents to the appropriate legal authority. The forums where our CoC is needed are like meetings, but they are online. Imagine a group of contributors attending a meeting in a room. Abusive behavior would not be allowed there, and it probably wouldn't happen anyway, because people generally remain civil in a face to face context. But the same set of behaviors that would not be allowed in that face to face meeting should not be allowed in our online interactions, whether synchronous in an actual online meeting or asynchronous via code reviews and email list discussions. And because we are online and spread all around the world, there is currently no way for us to stop and prevent abusive behavior.We need a formal procedure to enable that, and the CoC is that procedure. ________________________________________ From: André Pönitz Sent: Saturday, October 27, 2018 8:37:12 PM To: Martin Smith Cc: Bernhard Lindner; development at qt-project.org Subject: Re: [Development] QUIP 12: Code of Conduct On Sat, Oct 27, 2018 at 05:34:30PM +0000, Martin Smith wrote: > >Actions that are considered offenses by a society are typically mentioned > >in its laws. If something is not forbidden by law it usually means that > >there is no majority, let alone consensus in that society that this action > >is an offense. > > Exactly. Without a CoC, we have no laws, so the implication > is we don't consider any behavior an offense. I am not aware of a single country without laws. Over here e.g. "insult" is an offense. Andre' From Martin.Smith at qt.io Sun Oct 28 09:43:19 2018 From: Martin.Smith at qt.io (Martin Smith) Date: Sun, 28 Oct 2018 08:43:19 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> , Message-ID: >Oh, it is going to end in A resolution, it may not end the way the offended party >may feel just, but that's true also for the proposed text. HA! You are not Konstantin Shegunov! A software engineer would imediately see that your 3 step CoC might not terminate. You are an imposter! >imagine that the abusive party is an employee of the QtC and has committed >heinous acts against a community member. You can't immediately jump to the worst case scenario to discredit the code of conduct. In fact, the CoC can deal with "heinous acts" by stating that such acts will be referred to the appropriate legal authority. ________________________________________ From: Konstantin Shegunov Sent: Saturday, October 27, 2018 9:04:12 PM To: Martin Smith Cc: development at qt-project.org Subject: Re: [Development] QUIP 12: Code of Conduct On Sat, Oct 27, 2018 at 4:56 PM Martin Smith > wrote: You just specified a code of conduct. The problem with your code of conduct is that it isn't guaranteed to end in resolution. Oh, it is going to end in A resolution, it may not end the way the offended party may feel just, but that's true also for the proposed text. But that isn't the implication. Then I apologize, this is how I interpreted it. The implication is that a mistreated person can take the actions you have specified, and the result can be that the mistreatment, real or not, is not resolved. The proposed text can't guarantee resolution either (see below for a reductio ad absurdum). Active contributors who abuse others should be treated the same as inactive contributors who abuse others. What would be done would of course depend on what the abuser did. I suppose the abuser (active contributor or not) would be informed as to what he/she did wrong and would be told to stop doing it. Say we adopt the CC (basically the proposed text) and imagine that the abusive party is an employee of the QtC and has committed heinous acts against a community member. As far as I can tell this is very unlikely, but humor me for a second. As QtC employees' main work is on the Qt project, i.e. writing patches, committing features, writing docs and such, how would is this proposed committee to enforce the CoC? Are they going to plead that the person is taken out of the project, and wouldn't that mean that, basically, he/she can't be an employee for the QtC anymore? And to drive it home, say the head troll had a mental breakdown or something what is the committee to do? Take over the QtC? Just as I said before, I'm not against a CoC in principle. I'm against the CC's text which is quite invasive and badly written. To me KDE's CoC is much more practical in the case of the Qt project. Exactly. Without a CoC, we have no laws, so the implication is we don't consider any behavior an offense. Laws are bit more complicated than a statement of how people *should* behave. There's also separation of power, mandates, enforcement and laws that control how laws are made. Also there's hierarchy between the laws themselves in case they are in conflict. I suggest we don't venture into that. It's not what binds us to this community to begin with. From elvstone at gmail.com Sun Oct 28 11:22:10 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Sun, 28 Oct 2018 11:22:10 +0100 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <1686590.ORQEvNpYvM@tjmaciei-mobl1> References: <1686590.ORQEvNpYvM@tjmaciei-mobl1> Message-ID: Den lör 27 okt. 2018 kl 22:23 skrev Thiago Macieira : > > On Saturday, 27 October 2018 08:33:30 PDT Sérgio Martins wrote: > > Should we instead just encourage people to make returnsQtContainer() > > return a const container ? > > We should not, since the prevents move-construction from happening. You'll pay > the cost of two reference counts (one up and one down). Though hmm, even if we'd lose move-construction, for the copy we'd get instead, wouldn't copy elision kick in and elide it? So we wouldn't have to pay for the ref count up/down? I simplified my example a little, so to recap: $ cat copytest.cpp #include #include struct Foo { Foo() { std::cout << this << " constructed" << std::endl; } Foo(const Foo &) { std::cout << this << " copy constructed" << std::endl; } Foo(Foo &&) { std::cout << this << " move constructed" << std::endl; } ~Foo() { std::cout << this << " destructed" << std::endl; } std::vector::iterator begin() { std::cout << this << " begin" << std::endl; return v.begin(); }; std::vector::const_iterator begin() const { std::cout << this << " begin const" << std::endl; return v.begin(); }; std::vector::iterator end() { std::cout << this << " end" << std::endl; return v.end(); }; std::vector::const_iterator end() const { std::cout << this << " end const" << std::endl; return v.end(); }; std::vector v{1, 2, 3}; }; Foo f() { Foo foo; return foo; } const Foo constF() { Foo foo; return foo; } template const T moveToConst(T &&t) { return std::move(t); } int main(void) { std::cout << "without moveToConst:" << std::endl; for (auto v : f()) { } std::cout << std::endl; std::cout << "with moveToConst:" << std::endl; for (auto v : moveToConst(f())) { } std::cout << std::endl; std::cout << "with returning const:" << std::endl; for (auto v : constF()) { } std::cout << std::endl; std::cout << "with recommended way:" << std::endl; const auto stuff = f(); for (auto v : stuff) { } return 0; } Result: $ g++ -std=c++17 -O0 -o copytest copytest.cpp $ ./copytest without moveToConst: 0x7ffcc6ac76b0 constructed 0x7ffcc6ac76b0 begin 0x7ffcc6ac76b0 end 0x7ffcc6ac76b0 destructed with moveToConst: 0x7ffcc6ac7710 constructed 0x7ffcc6ac76d0 move constructed 0x7ffcc6ac7710 destructed 0x7ffcc6ac76d0 begin const 0x7ffcc6ac76d0 end const 0x7ffcc6ac76d0 destructed with returning const: 0x7ffcc6ac76f0 constructed 0x7ffcc6ac76f0 begin const 0x7ffcc6ac76f0 end const 0x7ffcc6ac76f0 destructed with recommended way: 0x7ffcc6ac7710 constructed 0x7ffcc6ac7710 begin const 0x7ffcc6ac7710 end const 0x7ffcc6ac7710 destructed So it looks like the copy has been elided also in the "with returning const" case. Anyone know if this is guaranteed in C++17, or just permitted? If I compile with -fno-elide-constructors to disable elision: $ g++ -std=c++17 -fno-elide-constructors -O0 -o copytest copytest.cpp $ ./copytest without moveToConst: 0x7ffe7c107070 constructed 0x7ffe7c1070f0 move constructed 0x7ffe7c107070 destructed 0x7ffe7c1070f0 begin 0x7ffe7c1070f0 end 0x7ffe7c1070f0 destructed with moveToConst: 0x7ffe7c107070 constructed 0x7ffe7c107150 move constructed 0x7ffe7c107070 destructed 0x7ffe7c107110 move constructed 0x7ffe7c107150 destructed 0x7ffe7c107110 begin const 0x7ffe7c107110 end const 0x7ffe7c107110 destructed with returning const: 0x7ffe7c107070 constructed 0x7ffe7c107130 move constructed 0x7ffe7c107070 destructed 0x7ffe7c107130 begin const 0x7ffe7c107130 end const 0x7ffe7c107130 destructed with recommended way: 0x7ffe7c107070 constructed 0x7ffe7c107150 move constructed 0x7ffe7c107070 destructed 0x7ffe7c107150 begin const 0x7ffe7c107150 end const 0x7ffe7c107150 destructed $ What I find surprising here is that with the -fno-elide-constructors flag, in the "with returning const", the move constructor *is* called. Didn't we just say it wouldn't, because the const rvalue wouldn't bind to the non-const rvalue reference? I'm a little confused :p Elvis > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From elvstone at gmail.com Sun Oct 28 11:28:17 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Sun, 28 Oct 2018 11:28:17 +0100 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: <1686590.ORQEvNpYvM@tjmaciei-mobl1> Message-ID: Den sön 28 okt. 2018 kl 11:22 skrev Elvis Stansvik : > > Den lör 27 okt. 2018 kl 22:23 skrev Thiago Macieira : > > > > On Saturday, 27 October 2018 08:33:30 PDT Sérgio Martins wrote: > > > Should we instead just encourage people to make returnsQtContainer() > > > return a const container ? > > > > We should not, since the prevents move-construction from happening. You'll pay > > the cost of two reference counts (one up and one down). > > Though hmm, even if we'd lose move-construction, for the copy we'd get > instead, wouldn't copy elision kick in and elide it? So we wouldn't > have to pay for the ref count up/down? > > I simplified my example a little, so to recap: > > $ cat copytest.cpp > #include > #include > > struct Foo { > Foo() { > std::cout << this << " constructed" << std::endl; > } > Foo(const Foo &) { > std::cout << this << " copy constructed" << std::endl; > } > Foo(Foo &&) { > std::cout << this << " move constructed" << std::endl; > } > ~Foo() { > std::cout << this << " destructed" << std::endl; > } > std::vector::iterator begin() { > std::cout << this << " begin" << std::endl; return v.begin(); > }; > std::vector::const_iterator begin() const { > std::cout << this << " begin const" << std::endl; return v.begin(); > }; > std::vector::iterator end() { > std::cout << this << " end" << std::endl; return v.end(); > }; > std::vector::const_iterator end() const { > std::cout << this << " end const" << std::endl; return v.end(); > }; > std::vector v{1, 2, 3}; > }; > > Foo f() { > Foo foo; > return foo; > } > > const Foo constF() { > Foo foo; > return foo; > } > > template > const T moveToConst(T &&t) > { > return std::move(t); > } > > int main(void) { > std::cout << "without moveToConst:" << std::endl; > for (auto v : f()) { } > > std::cout << std::endl; > > std::cout << "with moveToConst:" << std::endl; > for (auto v : moveToConst(f())) { } > > std::cout << std::endl; > > std::cout << "with returning const:" << std::endl; > for (auto v : constF()) { } > > std::cout << std::endl; > > std::cout << "with recommended way:" << std::endl; > const auto stuff = f(); > for (auto v : stuff) { } > > return 0; > } I put it up on godbolt for this who want to play: https://godbolt.org/z/x6FPq_ Elvis > > Result: > > $ g++ -std=c++17 -O0 -o copytest copytest.cpp > $ ./copytest > without moveToConst: > 0x7ffcc6ac76b0 constructed > 0x7ffcc6ac76b0 begin > 0x7ffcc6ac76b0 end > 0x7ffcc6ac76b0 destructed > > with moveToConst: > 0x7ffcc6ac7710 constructed > 0x7ffcc6ac76d0 move constructed > 0x7ffcc6ac7710 destructed > 0x7ffcc6ac76d0 begin const > 0x7ffcc6ac76d0 end const > 0x7ffcc6ac76d0 destructed > > with returning const: > 0x7ffcc6ac76f0 constructed > 0x7ffcc6ac76f0 begin const > 0x7ffcc6ac76f0 end const > 0x7ffcc6ac76f0 destructed > > with recommended way: > 0x7ffcc6ac7710 constructed > 0x7ffcc6ac7710 begin const > 0x7ffcc6ac7710 end const > 0x7ffcc6ac7710 destructed > > So it looks like the copy has been elided also in the "with returning > const" case. Anyone know if this is guaranteed in C++17, or just > permitted? > > If I compile with -fno-elide-constructors to disable elision: > > $ g++ -std=c++17 -fno-elide-constructors -O0 -o copytest copytest.cpp > $ ./copytest > without moveToConst: > 0x7ffe7c107070 constructed > 0x7ffe7c1070f0 move constructed > 0x7ffe7c107070 destructed > 0x7ffe7c1070f0 begin > 0x7ffe7c1070f0 end > 0x7ffe7c1070f0 destructed > > with moveToConst: > 0x7ffe7c107070 constructed > 0x7ffe7c107150 move constructed > 0x7ffe7c107070 destructed > 0x7ffe7c107110 move constructed > 0x7ffe7c107150 destructed > 0x7ffe7c107110 begin const > 0x7ffe7c107110 end const > 0x7ffe7c107110 destructed > > with returning const: > 0x7ffe7c107070 constructed > 0x7ffe7c107130 move constructed > 0x7ffe7c107070 destructed > 0x7ffe7c107130 begin const > 0x7ffe7c107130 end const > 0x7ffe7c107130 destructed > > with recommended way: > 0x7ffe7c107070 constructed > 0x7ffe7c107150 move constructed > 0x7ffe7c107070 destructed > 0x7ffe7c107150 begin const > 0x7ffe7c107150 end const > 0x7ffe7c107150 destructed > $ > > What I find surprising here is that with the -fno-elide-constructors > flag, in the "with returning const", the move constructor *is* called. > > Didn't we just say it wouldn't, because the const rvalue wouldn't bind > to the non-const rvalue reference? > > I'm a little confused :p > > Elvis > > > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel Open Source Technology Center > > > > > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development From yetanotherandreyev at gmail.com Sun Oct 28 11:36:41 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Sun, 28 Oct 2018 13:36:41 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3713880.AgeDxuVClM@tjmaciei-mobl1> Message-ID: Hello, Tomasz! :) Thank you for the question! Current draft based on CoC: > Our Pledge > ========== > In the interest of fostering an open and welcoming environment, we > as contributors to and maintainers of the Qt Project pledge to make > participation in our project and our community a harassment-free > experience for everyone, regardless of age, body size, disability, > ethnicity, sex characteristics, gender identity and expression, level > of experience, education, socio-economic status, nationality, personal > appearance, race, religion, or sexual identity and orientation, > or any other characteristics that are not relevant to a person's > ability to contribute to the Qt Project. and KDE version: > We do not tolerate personal attacks, racism, sexism or any other form of discrimination. Do we have any research about effects it leading? How many discrimination suspicions do we have right now? How could it be resolved successfully at digital community? How many misuse examples do we have at open projects since accepting similar rules? How CoC board are going to protect community from discrimination and harassment? Are CoC committee ready for "affirmative action"? I'm not against the rules as a concept, I agree we need it, but I totally against perverted or undefined rules that could help to destroy the community. I could not accept argument like "let's accept just anything and see how it goes and fix something later". "Don't code today what you can't debug tomorrow" :) I'm just saying we should think twice befoce accepting something. P.S.: I'm ready to change my mind if I've made a mistake, feel free to criticize, correct and ignore me :) вс, 28 окт. 2018 г. в 10:47, Tomasz Siekierda : > > The controversial discrimination protection sentences at least should be > carefully discussed. It's not some thing that we could accept as easy as > rewrite. > > Hi Alexey, I've just read the QUIP proposal and couldn't find any > controversial sentences. Could you elaborate? Which points shall be > discussed? > On Sat, 27 Oct 2018 at 22:41, Konstantin Shegunov > wrote: > > > > On Sat, Oct 27, 2018 at 11:20 PM Thiago Macieira < > thiago.macieira at intel.com> wrote: > >> > >> The answer to all of those questions needs to be "yes". Anything short > of that > >> means the CoC is powerless and just for show. > > > > > > Which was my point exactly. > > > >> > >> Whether there's a termination of employment or not is out of scope, > since the > >> CoC does not rule TQtC employment and what other work there is inside > that > >> company. > >> > >> > >> Note also it applies to any company. If you're not welcome anymore in > the > >> community where your employer is asking you to do work, that is going to > >> affect your employment. > > > > > > I agree. However my argument was that the QtC being a major contributor > to the codebase is going to have to abide by the ruling of the proposed > committee, which is a significant commitment (and a major nitpick I admit). > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kshegunov at gmail.com Sun Oct 28 11:35:42 2018 From: kshegunov at gmail.com (Konstantin Shegunov) Date: Sun, 28 Oct 2018 12:35:42 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> Message-ID: On Sun, Oct 28, 2018 at 10:43 AM Martin Smith wrote: > >Oh, it is going to end in A resolution, it may not end the way the > offended party > >may feel just, but that's true also for the proposed text. > > HA! You are not Konstantin Shegunov! A software engineer would imediately > see that your 3 step CoC might not terminate. You are an imposter! > That's actually amusing, but I'll bite. Formally speaking, I'm not a software engineer, never had any formal training in the field. I'm a physicist who moonlights as a programmer. In any case, the current status quo, which is what I described, ends in either the community reacting or not reacting to the alleged offence (i.e. isolating the offensive party for example). That is A resolution, be it a good one or bad. >imagine that the abusive party is an employee of the QtC and has committed > >heinous acts against a community member. > > You can't immediately jump to the worst case scenario to discredit the > code of conduct. In fact, the CoC can deal with "heinous acts" by stating > that such acts will be referred to the appropriate legal authority. > Not only can I, I pretty much have to. Minor infringements can already be handled internally without the need for CoC, major ones is where it would actually matter if we have one and which one we chose. Also it's a perfectly valid logic to push an argument to the extreme to see if holds, we do it on every day basis. In math you can assume something, operate on the presumption and see if contradicts itself when pushed (reductio ad impossibilem). If I were to design a safety net for a nuclear power plant am I to just ignore the extreme or unlikely case? Surely not. You compared the CoC to a "local law" of sorts, but does the local law forgo the unlikely case that from the whole population one person would be a murderer? I shouldn't think so. You can't defend the CoC's text and premise on the basis that my argument is unlikely, or extreme. It has to able to withstand exactly those extremes! In fact, the CoC can deal with "heinous acts" by stating that such acts > will be referred to the appropriate legal authority. Not if they don't elevate to a criminal act. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yetanotherandreyev at gmail.com Sun Oct 28 11:42:31 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Sun, 28 Oct 2018 13:42:31 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> Message-ID: I agree with you, Konstantin вс, 28 окт. 2018 г. в 13:36, Konstantin Shegunov : > > > On Sun, Oct 28, 2018 at 10:43 AM Martin Smith wrote: > >> >Oh, it is going to end in A resolution, it may not end the way the >> offended party >> >may feel just, but that's true also for the proposed text. >> >> HA! You are not Konstantin Shegunov! A software engineer would imediately >> see that your 3 step CoC might not terminate. You are an imposter! >> > > That's actually amusing, but I'll bite. Formally speaking, I'm not a > software engineer, never had any formal training in the field. I'm a > physicist who moonlights as a programmer. In any case, the current status > quo, which is what I described, ends in either the community reacting or > not reacting to the alleged offence (i.e. isolating the offensive party for > example). That is A resolution, be it a good one or bad. > > >imagine that the abusive party is an employee of the QtC and has committed >> >heinous acts against a community member. >> >> You can't immediately jump to the worst case scenario to discredit the >> code of conduct. In fact, the CoC can deal with "heinous acts" by stating >> that such acts will be referred to the appropriate legal authority. >> > > Not only can I, I pretty much have to. Minor infringements can already be > handled internally without the need for CoC, major ones is where it would > actually matter if we have one and which one we chose. Also it's a > perfectly valid logic to push an argument to the extreme to see if holds, > we do it on every day basis. In math you can assume something, operate on > the presumption and see if contradicts itself when pushed (reductio ad > impossibilem). If I were to design a safety net for a nuclear power plant > am I to just ignore the extreme or unlikely case? Surely not. You compared > the CoC to a "local law" of sorts, but does the local law forgo the > unlikely case that from the whole population one person would be a > murderer? I shouldn't think so. > You can't defend the CoC's text and premise on the basis that my argument > is unlikely, or extreme. It has to able to withstand exactly those extremes! > > In fact, the CoC can deal with "heinous acts" by stating that such acts >> will be referred to the appropriate legal authority. > > > Not if they don't elevate to a criminal act. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvstone at gmail.com Sun Oct 28 12:13:50 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Sun, 28 Oct 2018 12:13:50 +0100 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: <1686590.ORQEvNpYvM@tjmaciei-mobl1> Message-ID: Den sön 28 okt. 2018 kl 11:22 skrev Elvis Stansvik : > > Den lör 27 okt. 2018 kl 22:23 skrev Thiago Macieira : > > > > On Saturday, 27 October 2018 08:33:30 PDT Sérgio Martins wrote: > > > Should we instead just encourage people to make returnsQtContainer() > > > return a const container ? > > > > We should not, since the prevents move-construction from happening. You'll pay > > the cost of two reference counts (one up and one down). > > Though hmm, even if we'd lose move-construction, for the copy we'd get > instead, wouldn't copy elision kick in and elide it? So we wouldn't > have to pay for the ref count up/down? > > I simplified my example a little, so to recap: > > $ cat copytest.cpp > #include > #include > > struct Foo { > Foo() { > std::cout << this << " constructed" << std::endl; > } > Foo(const Foo &) { > std::cout << this << " copy constructed" << std::endl; > } > Foo(Foo &&) { > std::cout << this << " move constructed" << std::endl; > } > ~Foo() { > std::cout << this << " destructed" << std::endl; > } > std::vector::iterator begin() { > std::cout << this << " begin" << std::endl; return v.begin(); > }; > std::vector::const_iterator begin() const { > std::cout << this << " begin const" << std::endl; return v.begin(); > }; > std::vector::iterator end() { > std::cout << this << " end" << std::endl; return v.end(); > }; > std::vector::const_iterator end() const { > std::cout << this << " end const" << std::endl; return v.end(); > }; > std::vector v{1, 2, 3}; > }; > > Foo f() { > Foo foo; > return foo; > } > > const Foo constF() { > Foo foo; > return foo; > } > > template > const T moveToConst(T &&t) > { > return std::move(t); > } > > int main(void) { > std::cout << "without moveToConst:" << std::endl; > for (auto v : f()) { } > > std::cout << std::endl; > > std::cout << "with moveToConst:" << std::endl; > for (auto v : moveToConst(f())) { } > > std::cout << std::endl; > > std::cout << "with returning const:" << std::endl; > for (auto v : constF()) { } > > std::cout << std::endl; > > std::cout << "with recommended way:" << std::endl; > const auto stuff = f(); > for (auto v : stuff) { } > > return 0; > } > > Result: > > $ g++ -std=c++17 -O0 -o copytest copytest.cpp > $ ./copytest > without moveToConst: > 0x7ffcc6ac76b0 constructed > 0x7ffcc6ac76b0 begin > 0x7ffcc6ac76b0 end > 0x7ffcc6ac76b0 destructed > > with moveToConst: > 0x7ffcc6ac7710 constructed > 0x7ffcc6ac76d0 move constructed > 0x7ffcc6ac7710 destructed > 0x7ffcc6ac76d0 begin const > 0x7ffcc6ac76d0 end const > 0x7ffcc6ac76d0 destructed > > with returning const: > 0x7ffcc6ac76f0 constructed > 0x7ffcc6ac76f0 begin const > 0x7ffcc6ac76f0 end const > 0x7ffcc6ac76f0 destructed > > with recommended way: > 0x7ffcc6ac7710 constructed > 0x7ffcc6ac7710 begin const > 0x7ffcc6ac7710 end const > 0x7ffcc6ac7710 destructed > > So it looks like the copy has been elided also in the "with returning > const" case. Anyone know if this is guaranteed in C++17, or just > permitted? > > If I compile with -fno-elide-constructors to disable elision: > > $ g++ -std=c++17 -fno-elide-constructors -O0 -o copytest copytest.cpp > $ ./copytest > without moveToConst: > 0x7ffe7c107070 constructed > 0x7ffe7c1070f0 move constructed > 0x7ffe7c107070 destructed > 0x7ffe7c1070f0 begin > 0x7ffe7c1070f0 end > 0x7ffe7c1070f0 destructed > > with moveToConst: > 0x7ffe7c107070 constructed > 0x7ffe7c107150 move constructed > 0x7ffe7c107070 destructed > 0x7ffe7c107110 move constructed > 0x7ffe7c107150 destructed > 0x7ffe7c107110 begin const > 0x7ffe7c107110 end const > 0x7ffe7c107110 destructed > > with returning const: > 0x7ffe7c107070 constructed > 0x7ffe7c107130 move constructed > 0x7ffe7c107070 destructed > 0x7ffe7c107130 begin const > 0x7ffe7c107130 end const > 0x7ffe7c107130 destructed > > with recommended way: > 0x7ffe7c107070 constructed > 0x7ffe7c107150 move constructed > 0x7ffe7c107070 destructed > 0x7ffe7c107150 begin const > 0x7ffe7c107150 end const > 0x7ffe7c107150 destructed > $ I tried some more compilers. With Apple Clang 9.0.0 and -std=c++14, the output is the same without -fno-elide-constructors, but interestingly, if -fno-elide-constructors is added, the output is: with returning const: 0x7fff596ed8a8 constructed 0x7fff596eda20 move constructed 0x7fff596ed8a8 destructed 0x7fff596eda20 begin const 0x7fff596eda20 end const 0x7fff596eda20 destructed with recommended way: 0x7fff596ed8a8 constructed 0x7fff596ed9c8 move constructed 0x7fff596ed8a8 destructed 0x7fff596ed9e0 move constructed 0x7fff596ed9c8 destructed 0x7fff596ed9e0 begin const 0x7fff596ed9e0 end const 0x7fff596ed9e0 destructed With MSVC 2015 (compiled with just cl copytest.cpp), the output is: with returning const: 0000009FFE4BFD90 constructed 0000009FFE4BFE88 move constructed 0000009FFE4BFD90 destructed 0000009FFE4BFE88 begin const 0000009FFE4BFE88 end const 0000009FFE4BFE88 destructed with recommended way: 0000009FFE4BFD90 constructed 0000009FFE4BFEA0 move constructed 0000009FFE4BFD90 destructed 0000009FFE4BFEA0 begin const 0000009FFE4BFEA0 end const 0000009FFE4BFEA0 destructed So somehow it invokes the move constructor, not sure if this is just a bug. Elvis > > What I find surprising here is that with the -fno-elide-constructors > flag, in the "with returning const", the move constructor *is* called. > > Didn't we just say it wouldn't, because the const rvalue wouldn't bind > to the non-const rvalue reference? > > I'm a little confused :p > > Elvis > > > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel Open Source Technology Center > > > > > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development From elvstone at gmail.com Sun Oct 28 12:36:53 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Sun, 28 Oct 2018 12:36:53 +0100 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3713880.AgeDxuVClM@tjmaciei-mobl1> Message-ID: Den sön 28 okt. 2018 kl 11:34 skrev Alexey Andreyev : > > Hello, Tomasz! :) > Thank you for the question! > > Current draft based on CoC: > > > Our Pledge > > ========== > > In the interest of fostering an open and welcoming environment, we > > as contributors to and maintainers of the Qt Project pledge to make > > participation in our project and our community a harassment-free > > experience for everyone, regardless of age, body size, disability, > > ethnicity, sex characteristics, gender identity and expression, level > > of experience, education, socio-economic status, nationality, personal > > appearance, race, religion, or sexual identity and orientation, > > or any other characteristics that are not relevant to a person's > > ability to contribute to the Qt Project. A lot of people seem to have a problem with this long enumeration. I think this is because we're programmers, and we think of it as redundant given the concluding "[...] or any other characteristics that are not relevant to a person's ability to contribute to the Qt Project.", or the shorter list in the KDE CoC, so we instinctively want to trim the fat - we want to optimize. But, and this is of course just my personal opinion/interpretation, I think the purpose of this enumeration is to list those very large groups of people in society who are currently experiencing harassment and mistreatment for who they are. The pledge is supposed to be a set of guidelines for how the community operates, but *also* a message to potential contributors. Thought of that way, I think the enumeration makes sense: We tell a large part of the population who are currently being oppressed/mistreated that, at least in our community, you can feel safe. The enumeration is not supposed to cover everything, but I think it fulfills a purpose by covering a lot. I don't agree with some earlier poster who thought of the enumeration as setting some kind of bar, I don't think that is the purpose of it. It is meant as a message, and to drive that message home with the groups of people we want to reach, I think it makes sense to be explicit. The concluding "[...] or any other characteristics that are not relevant to a person's ability to contribute to the Qt Project." is of course very important *as well*, to cover our bases. If in 5, 10 or 50 years (I know, I'm a pessimist), there is no longer widespread discrimination and mistreatment of people for their race, religion or sexual identity/orientation, but some other groups are being mistreated (again, sorry for the pessimism), then I think it's perfectly fine to revise this list. I can't really see how this list could be misused. If people have an issue with a particular item on the list, they should say so. That's just my 2 cents on the enumeration, which seems to bug people, and I completely understand if others see it differently. Elvis > > and KDE version: > > > We do not tolerate personal attacks, racism, sexism or any other form of discrimination. > > Do we have any research about effects it leading? > > How many discrimination suspicions do we have right now? > > How could it be resolved successfully at digital community? > > How many misuse examples do we have at open projects since accepting similar rules? > > How CoC board are going to protect community from discrimination and harassment? > > Are CoC committee ready for "affirmative action"? > > I'm not against the rules as a concept, I agree we need it, > but I totally against perverted or undefined rules that could help to destroy the community. > > I could not accept argument like "let's accept just anything and see how it goes and fix something later". > "Don't code today what you can't debug tomorrow" :) > > I'm just saying we should think twice befoce accepting something. > > P.S.: I'm ready to change my mind if I've made a mistake, feel free to criticize, correct and ignore me :) > > вс, 28 окт. 2018 г. в 10:47, Tomasz Siekierda : >> >> > The controversial discrimination protection sentences at least should be carefully discussed. It's not some thing that we could accept as easy as rewrite. >> >> Hi Alexey, I've just read the QUIP proposal and couldn't find any >> controversial sentences. Could you elaborate? Which points shall be >> discussed? >> On Sat, 27 Oct 2018 at 22:41, Konstantin Shegunov wrote: >> > >> > On Sat, Oct 27, 2018 at 11:20 PM Thiago Macieira wrote: >> >> >> >> The answer to all of those questions needs to be "yes". Anything short of that >> >> means the CoC is powerless and just for show. >> > >> > >> > Which was my point exactly. >> > >> >> >> >> Whether there's a termination of employment or not is out of scope, since the >> >> CoC does not rule TQtC employment and what other work there is inside that >> >> company. >> >> >> >> >> >> Note also it applies to any company. If you're not welcome anymore in the >> >> community where your employer is asking you to do work, that is going to >> >> affect your employment. >> > >> > >> > I agree. However my argument was that the QtC being a major contributor to the codebase is going to have to abide by the ruling of the proposed committee, which is a significant commitment (and a major nitpick I admit). >> > _______________________________________________ >> > Development mailing list >> > Development at qt-project.org >> > http://lists.qt-project.org/mailman/listinfo/development >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Martin.Smith at qt.io Sun Oct 28 13:08:49 2018 From: Martin.Smith at qt.io (Martin Smith) Date: Sun, 28 Oct 2018 12:08:49 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> , Message-ID: >In any case, the current status quo, which is what I described, ends in either the >community reacting or not reacting to the alleged offence (i.e. isolating the >offensive party for example). That is A resolution, be it a good one or bad. No, it isn't a resolution. Not reacting to a complaint is no resolution. But even if "the community" does react to the alleged offense, how is that different from mob rule? >Not only can I, I pretty much have to. No. You don't. You used the word "heinous." It has a meaning. You used it deliberately to draw attention away from the problems the CoC is meant to resolve. We don't need a CoC to deal with heinous offenses because heinous offenses are dealt with by the police. >You can't defend the CoC's text and premise on the basis that my argument is >unlikely, or extreme. I'm not defending the CoC text and premise. I'm defending the goal of establishing a CoC. >Not if they don't elevate to a criminal act. My turn to bite. What is a heinous act that is not a criminal act? ________________________________________ From: Konstantin Shegunov Sent: Sunday, October 28, 2018 11:35:42 AM To: Martin Smith Cc: development at qt-project.org Subject: Re: [Development] QUIP 12: Code of Conduct On Sun, Oct 28, 2018 at 10:43 AM Martin Smith > wrote: >Oh, it is going to end in A resolution, it may not end the way the offended party >may feel just, but that's true also for the proposed text. HA! You are not Konstantin Shegunov! A software engineer would imediately see that your 3 step CoC might not terminate. You are an imposter! That's actually amusing, but I'll bite. Formally speaking, I'm not a software engineer, never had any formal training in the field. I'm a physicist who moonlights as a programmer. In any case, the current status quo, which is what I described, ends in either the community reacting or not reacting to the alleged offence (i.e. isolating the offensive party for example). That is A resolution, be it a good one or bad. >imagine that the abusive party is an employee of the QtC and has committed >heinous acts against a community member. You can't immediately jump to the worst case scenario to discredit the code of conduct. In fact, the CoC can deal with "heinous acts" by stating that such acts will be referred to the appropriate legal authority. Not only can I, I pretty much have to. Minor infringements can already be handled internally without the need for CoC, major ones is where it would actually matter if we have one and which one we chose. Also it's a perfectly valid logic to push an argument to the extreme to see if holds, we do it on every day basis. In math you can assume something, operate on the presumption and see if contradicts itself when pushed (reductio ad impossibilem). If I were to design a safety net for a nuclear power plant am I to just ignore the extreme or unlikely case? Surely not. You compared the CoC to a "local law" of sorts, but does the local law forgo the unlikely case that from the whole population one person would be a murderer? I shouldn't think so. You can't defend the CoC's text and premise on the basis that my argument is unlikely, or extreme. It has to able to withstand exactly those extremes! In fact, the CoC can deal with "heinous acts" by stating that such acts will be referred to the appropriate legal authority. Not if they don't elevate to a criminal act. From giuseppe.dangelo at kdab.com Sun Oct 28 13:31:57 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Sun, 28 Oct 2018 13:31:57 +0100 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: <1686590.ORQEvNpYvM@tjmaciei-mobl1> Message-ID: <868af8fd-1862-43da-f599-a4f175a0eff2@kdab.com> Il 28/10/18 11:22, Elvis Stansvik ha scritto: > Though hmm, even if we'd lose move-construction, for the copy we'd get > instead, wouldn't copy elision kick in and elide it? So we wouldn't > have to pay for the ref count up/down? GCE is one thing, and applies in a very specific case (returning a prvalue). (N)RVO is another thing, and may or may not be applied depending on whether the compiler *can* apply it and *will* apply it. In the general case, you won't have either, and thus having a move will be cheaper than a copy. Returning const objects for types which benefit from moves is a bad idea. My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From giuseppe.dangelo at kdab.com Sun Oct 28 13:32:40 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Sun, 28 Oct 2018 13:32:40 +0100 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> <4b21d498-c513-53e7-5c20-2e8c88aeb0db@kdab.com> <34556951-f628-6499-ee3d-3b05b69570d6@woboq.com> Message-ID: <52e05cc7-d77b-7d20-1b74-b9205044b2f2@kdab.com> Il 27/10/18 17:27, Sérgio Martins ha scritto: > It is, see Qt's documentation: > "Since Qt 5.7, the use of this macro is discouraged. It will be > removed in a future version of Qt" > ... we need to start adding actual deprecation macros, or people will never notice. https://codereview.qt-project.org/#/c/243949/ Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From elvstone at gmail.com Sun Oct 28 13:42:10 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Sun, 28 Oct 2018 13:42:10 +0100 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <868af8fd-1862-43da-f599-a4f175a0eff2@kdab.com> References: <1686590.ORQEvNpYvM@tjmaciei-mobl1> <868af8fd-1862-43da-f599-a4f175a0eff2@kdab.com> Message-ID: Den sön 28 okt. 2018 kl 13:32 skrev Giuseppe D'Angelo via Development : > > Il 28/10/18 11:22, Elvis Stansvik ha scritto: > > Though hmm, even if we'd lose move-construction, for the copy we'd get > > instead, wouldn't copy elision kick in and elide it? So we wouldn't > > have to pay for the ref count up/down? > > GCE is one thing, and applies in a very specific case (returning a > prvalue). > > (N)RVO is another thing, and may or may not be applied depending on > whether the compiler *can* apply it and *will* apply it. > > In the general case, you won't have either, and thus having a move will > be cheaper than a copy. Returning const objects for types which benefit > from moves is a bad idea. Ah yes of course, my bad. Elvis > > My 2 c, > > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From yetanotherandreyev at gmail.com Sun Oct 28 14:31:55 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Sun, 28 Oct 2018 16:31:55 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3713880.AgeDxuVClM@tjmaciei-mobl1> Message-ID: > [...] or the shorter list in the KDE CoC, so we instinctively > want to trim the fat - we want to optimize. I've provided both (CC and from KDE) not to show some version is better, but to show both have same problems. For me it's not about optimization right now. Is it possible to follow provided versions? And receive more positive for the commuity than negative. > the purpose of this enumeration is to list those very large > groups of people in society who are currently experiencing harassment > and mistreatment for who they are Is that obvious that provided document will help not made things worse for everyone? Are we going to treat something at the commuity just blindly without diagnosis and research? > We tell a large part of the population who are currently > being oppressed/mistreated that, at least in our community, you can > feel safe How are we going to provide safety? > The enumeration is not supposed to cover everything, but I > think it fulfills a purpose by covering a lot. As far as I can see the reasoning is based on the hypothesis that any rules will not be able to aggravate the situation. It's not obvious. > I don't agree with some earlier poster who thought of the enumeration > as setting some kind of bar, I don't think that is the purpose of it. > The concluding "[...] or any other characteristics that are > not relevant to a person's ability to contribute to the Qt Project." > is of course very important *as well*, to cover our bases. How the committee is going to determine that someone has violated these "guidelines not bars"? What is the purpose of the guidelines without additional information how to protect them? > I can't really see how this list could be misused. If people have an > issue with a particular item on the list, they should say so. For example, let's say some person (person or legal entity, organization or groups of organizations) have projects, competing with Qt somehow (or linux, or KDE). That "person/groups" will get more profit if Qt community will became unhealthy or will cease to exist. That person could sponsor, support or pay money somehow to other persons to support some vulnerable ideas. Persons who accept that ideas and have interests, conflicting with the community, could say something like "hey, we are actually feeling harassment, please accept our ideas/patches/anything too". It is a space for accepting non-obvious security or architectural changes. In 50, 10 or 5 years :) if attackers will be lucky enough, Qt community could lost their image of as awesome commuity as it is right now. ..??? PROFIT! Young generation not interested, no support, commuity is dying, profit for competing projects. It's just one example that could sound like a joke since I'm not a professional with this kind of tricky social questions, but I hope I showed the danger as a caricature at least. I don't want my arguments be adressed to someone personally, and I'm not saying there's some conspiracy here. I just want to help to save and develop the community for the future. I agree we need rules. My problem is not any rules are healthy. вс, 28 окт. 2018 г. в 14:37, Elvis Stansvik : > Den sön 28 okt. 2018 kl 11:34 skrev Alexey Andreyev > : > > > > Hello, Tomasz! :) > > Thank you for the question! > > > > Current draft based on CoC: > > > > > Our Pledge > > > ========== > > > In the interest of fostering an open and welcoming environment, we > > > as contributors to and maintainers of the Qt Project pledge to make > > > participation in our project and our community a harassment-free > > > experience for everyone, regardless of age, body size, disability, > > > ethnicity, sex characteristics, gender identity and expression, level > > > of experience, education, socio-economic status, nationality, personal > > > appearance, race, religion, or sexual identity and orientation, > > > or any other characteristics that are not relevant to a person's > > > ability to contribute to the Qt Project. > > A lot of people seem to have a problem with this long enumeration. > > I think this is because we're programmers, and we think of it as > redundant given the concluding "[...] or any other characteristics > that are not relevant to a person's ability to contribute to the Qt > Project.", or the shorter list in the KDE CoC, so we instinctively > want to trim the fat - we want to optimize. > > But, and this is of course just my personal opinion/interpretation, I > think the purpose of this enumeration is to list those very large > groups of people in society who are currently experiencing harassment > and mistreatment for who they are. The pledge is supposed to be a set > of guidelines for how the community operates, but *also* a message to > potential contributors. Thought of that way, I think the enumeration > makes sense: We tell a large part of the population who are currently > being oppressed/mistreated that, at least in our community, you can > feel safe. The enumeration is not supposed to cover everything, but I > think it fulfills a purpose by covering a lot. > > I don't agree with some earlier poster who thought of the enumeration > as setting some kind of bar, I don't think that is the purpose of it. > It is meant as a message, and to drive that message home with the > groups of people we want to reach, I think it makes sense to be > explicit. The concluding "[...] or any other characteristics that are > not relevant to a person's ability to contribute to the Qt Project." > is of course very important *as well*, to cover our bases. > > If in 5, 10 or 50 years (I know, I'm a pessimist), there is no longer > widespread discrimination and mistreatment of people for their race, > religion or sexual identity/orientation, but some other groups are > being mistreated (again, sorry for the pessimism), then I think it's > perfectly fine to revise this list. > > I can't really see how this list could be misused. If people have an > issue with a particular item on the list, they should say so. > > That's just my 2 cents on the enumeration, which seems to bug people, > and I completely understand if others see it differently. > > Elvis > > > > > and KDE version: > > > > > We do not tolerate personal attacks, racism, sexism or any other form > of discrimination. > > > > Do we have any research about effects it leading? > > > > How many discrimination suspicions do we have right now? > > > > How could it be resolved successfully at digital community? > > > > How many misuse examples do we have at open projects since accepting > similar rules? > > > > How CoC board are going to protect community from discrimination and > harassment? > > > > Are CoC committee ready for "affirmative action"? > > > > I'm not against the rules as a concept, I agree we need it, > > but I totally against perverted or undefined rules that could help to > destroy the community. > > > > I could not accept argument like "let's accept just anything and see how > it goes and fix something later". > > "Don't code today what you can't debug tomorrow" :) > > > > I'm just saying we should think twice befoce accepting something. > > > > P.S.: I'm ready to change my mind if I've made a mistake, feel free to > criticize, correct and ignore me :) > > > > вс, 28 окт. 2018 г. в 10:47, Tomasz Siekierda : > >> > >> > The controversial discrimination protection sentences at least should > be carefully discussed. It's not some thing that we could accept as easy as > rewrite. > >> > >> Hi Alexey, I've just read the QUIP proposal and couldn't find any > >> controversial sentences. Could you elaborate? Which points shall be > >> discussed? > >> On Sat, 27 Oct 2018 at 22:41, Konstantin Shegunov > wrote: > >> > > >> > On Sat, Oct 27, 2018 at 11:20 PM Thiago Macieira < > thiago.macieira at intel.com> wrote: > >> >> > >> >> The answer to all of those questions needs to be "yes". Anything > short of that > >> >> means the CoC is powerless and just for show. > >> > > >> > > >> > Which was my point exactly. > >> > > >> >> > >> >> Whether there's a termination of employment or not is out of scope, > since the > >> >> CoC does not rule TQtC employment and what other work there is > inside that > >> >> company. > >> >> > >> >> > >> >> Note also it applies to any company. If you're not welcome anymore > in the > >> >> community where your employer is asking you to do work, that is > going to > >> >> affect your employment. > >> > > >> > > >> > I agree. However my argument was that the QtC being a major > contributor to the codebase is going to have to abide by the ruling of the > proposed committee, which is a significant commitment (and a major nitpick > I admit). > >> > _______________________________________________ > >> > Development mailing list > >> > Development at qt-project.org > >> > http://lists.qt-project.org/mailman/listinfo/development > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvstone at gmail.com Sun Oct 28 15:35:34 2018 From: elvstone at gmail.com (Elvis Stansvik) Date: Sun, 28 Oct 2018 15:35:34 +0100 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3713880.AgeDxuVClM@tjmaciei-mobl1> Message-ID: Den sön 28 okt. 2018 kl 14:29 skrev Alexey Andreyev : > > > [...] or the shorter list in the KDE CoC, so we instinctively > > want to trim the fat - we want to optimize. > > I've provided both (CC and from KDE) not to show some version is better, > but to show both have same problems. > > For me it's not about optimization right now. Is it possible to follow provided versions? > And receive more positive for the commuity than negative. > > > the purpose of this enumeration is to list those very large > > groups of people in society who are currently experiencing harassment > > and mistreatment for who they are > > Is that obvious that provided document will help not made things worse for everyone? > Are we going to treat something at the commuity just blindly without diagnosis and research? > > > We tell a large part of the population who are currently > > being oppressed/mistreated that, at least in our community, you can > > feel safe > > How are we going to provide safety? > > > The enumeration is not supposed to cover everything, but I > > think it fulfills a purpose by covering a lot. > > As far as I can see the reasoning is based on the hypothesis that any rules will not be able to aggravate the situation. It's not obvious. > > > I don't agree with some earlier poster who thought of the enumeration > > as setting some kind of bar, I don't think that is the purpose of it. > > > The concluding "[...] or any other characteristics that are > > not relevant to a person's ability to contribute to the Qt Project." > > is of course very important *as well*, to cover our bases. > > How the committee is going to determine that someone has violated these "guidelines not bars"? > What is the purpose of the guidelines without additional information how to protect them? > > > I can't really see how this list could be misused. If people have an > > issue with a particular item on the list, they should say so. > > For example, let's say some person (person or legal entity, organization or groups of organizations) have projects, competing with Qt somehow (or linux, or KDE). > That "person/groups" will get more profit if Qt community will became unhealthy or will cease to exist. > That person could sponsor, support or pay money somehow to other persons to support some vulnerable ideas. > Persons who accept that ideas and have interests, conflicting with the community, could say something like > "hey, we are actually feeling harassment, please accept our ideas/patches/anything too". > It is a space for accepting non-obvious security or architectural changes. > > In 50, 10 or 5 years :) if attackers will be lucky enough, Qt community could lost their image of as awesome commuity as it is right now. I honestly think this is an extremely contrived example, and I think you're worrying way too much, but OK let's play along. You're suggesting that someone would submit bad patches, hoping to get harassed and thereby somehow get the patches in, as some sort of compensation for the harassment, and would use this in order to sabotage the Qt project? Looking past the ridiculousness of that idea for the moment, getting your patches rejected is not harassment. Not under any definition of harassment that I know of, and certainly not according to the suggested CoC. The patches can be respectfully rejected with e.g. "this is not in line with the Qt vision", or "could you please revise this part first?". The patches can also be rejected with "please don't submit crap like this, you fat dyke". See the difference? The first is not a matter for the CoC. If the party would still file a complaint, it would be dealt with and the council would find that no harassment took place. The second would most certainly be cause for some kind of action (I guess to begin with, tell the offender to not do that again and point them to the CoC). Elvis > > ..??? > > PROFIT! Young generation not interested, no support, commuity is dying, profit for competing projects. > > > It's just one example that could sound like a joke since I'm not a professional with this kind of tricky social questions, > but I hope I showed the danger as a caricature at least. > > I don't want my arguments be adressed to someone personally, and I'm not saying there's some conspiracy here. > I just want to help to save and develop the community for the future. > > I agree we need rules. My problem is not any rules are healthy. > > вс, 28 окт. 2018 г. в 14:37, Elvis Stansvik : >> >> Den sön 28 okt. 2018 kl 11:34 skrev Alexey Andreyev >> : >> > >> > Hello, Tomasz! :) >> > Thank you for the question! >> > >> > Current draft based on CoC: >> > >> > > Our Pledge >> > > ========== >> > > In the interest of fostering an open and welcoming environment, we >> > > as contributors to and maintainers of the Qt Project pledge to make >> > > participation in our project and our community a harassment-free >> > > experience for everyone, regardless of age, body size, disability, >> > > ethnicity, sex characteristics, gender identity and expression, level >> > > of experience, education, socio-economic status, nationality, personal >> > > appearance, race, religion, or sexual identity and orientation, >> > > or any other characteristics that are not relevant to a person's >> > > ability to contribute to the Qt Project. >> >> A lot of people seem to have a problem with this long enumeration. >> >> I think this is because we're programmers, and we think of it as >> redundant given the concluding "[...] or any other characteristics >> that are not relevant to a person's ability to contribute to the Qt >> Project.", or the shorter list in the KDE CoC, so we instinctively >> want to trim the fat - we want to optimize. >> >> But, and this is of course just my personal opinion/interpretation, I >> think the purpose of this enumeration is to list those very large >> groups of people in society who are currently experiencing harassment >> and mistreatment for who they are. The pledge is supposed to be a set >> of guidelines for how the community operates, but *also* a message to >> potential contributors. Thought of that way, I think the enumeration >> makes sense: We tell a large part of the population who are currently >> being oppressed/mistreated that, at least in our community, you can >> feel safe. The enumeration is not supposed to cover everything, but I >> think it fulfills a purpose by covering a lot. >> >> I don't agree with some earlier poster who thought of the enumeration >> as setting some kind of bar, I don't think that is the purpose of it. >> It is meant as a message, and to drive that message home with the >> groups of people we want to reach, I think it makes sense to be >> explicit. The concluding "[...] or any other characteristics that are >> not relevant to a person's ability to contribute to the Qt Project." >> is of course very important *as well*, to cover our bases. >> >> If in 5, 10 or 50 years (I know, I'm a pessimist), there is no longer >> widespread discrimination and mistreatment of people for their race, >> religion or sexual identity/orientation, but some other groups are >> being mistreated (again, sorry for the pessimism), then I think it's >> perfectly fine to revise this list. >> >> I can't really see how this list could be misused. If people have an >> issue with a particular item on the list, they should say so. >> >> That's just my 2 cents on the enumeration, which seems to bug people, >> and I completely understand if others see it differently. >> >> Elvis >> >> > >> > and KDE version: >> > >> > > We do not tolerate personal attacks, racism, sexism or any other form of discrimination. >> > >> > Do we have any research about effects it leading? >> > >> > How many discrimination suspicions do we have right now? >> > >> > How could it be resolved successfully at digital community? >> > >> > How many misuse examples do we have at open projects since accepting similar rules? >> > >> > How CoC board are going to protect community from discrimination and harassment? >> > >> > Are CoC committee ready for "affirmative action"? >> > >> > I'm not against the rules as a concept, I agree we need it, >> > but I totally against perverted or undefined rules that could help to destroy the community. >> > >> > I could not accept argument like "let's accept just anything and see how it goes and fix something later". >> > "Don't code today what you can't debug tomorrow" :) >> > >> > I'm just saying we should think twice befoce accepting something. >> > >> > P.S.: I'm ready to change my mind if I've made a mistake, feel free to criticize, correct and ignore me :) >> > >> > вс, 28 окт. 2018 г. в 10:47, Tomasz Siekierda : >> >> >> >> > The controversial discrimination protection sentences at least should be carefully discussed. It's not some thing that we could accept as easy as rewrite. >> >> >> >> Hi Alexey, I've just read the QUIP proposal and couldn't find any >> >> controversial sentences. Could you elaborate? Which points shall be >> >> discussed? >> >> On Sat, 27 Oct 2018 at 22:41, Konstantin Shegunov wrote: >> >> > >> >> > On Sat, Oct 27, 2018 at 11:20 PM Thiago Macieira wrote: >> >> >> >> >> >> The answer to all of those questions needs to be "yes". Anything short of that >> >> >> means the CoC is powerless and just for show. >> >> > >> >> > >> >> > Which was my point exactly. >> >> > >> >> >> >> >> >> Whether there's a termination of employment or not is out of scope, since the >> >> >> CoC does not rule TQtC employment and what other work there is inside that >> >> >> company. >> >> >> >> >> >> >> >> >> Note also it applies to any company. If you're not welcome anymore in the >> >> >> community where your employer is asking you to do work, that is going to >> >> >> affect your employment. >> >> > >> >> > >> >> > I agree. However my argument was that the QtC being a major contributor to the codebase is going to have to abide by the ruling of the proposed committee, which is a significant commitment (and a major nitpick I admit). >> >> > _______________________________________________ >> >> > Development mailing list >> >> > Development at qt-project.org >> >> > http://lists.qt-project.org/mailman/listinfo/development >> >> _______________________________________________ >> >> Development mailing list >> >> Development at qt-project.org >> >> http://lists.qt-project.org/mailman/listinfo/development >> > >> > _______________________________________________ >> > Development mailing list >> > Development at qt-project.org >> > http://lists.qt-project.org/mailman/listinfo/development From apoenitz at t-online.de Sun Oct 28 16:36:17 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Sun, 28 Oct 2018 16:36:17 +0100 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> <20181027172539.GA20012@klara.mpi.htwm.de> <20181027183712.GA28072@klara.mpi.htwm.de> Message-ID: <20181028153617.GA1855@klara.mpi.htwm.de> On Sun, Oct 28, 2018 at 08:34:40AM +0000, Martin Smith wrote: > And because we are online and spread all around the world, there is > currently no way for us to stop and prevent abusive behavior. That would be a valid reason in case there had been or we would expect to be unstoppable abusive behaviour. Most abusive behaviour on the mailing lists and IRC can be stopped by technical means, in exceptional cases like the recent spam attack on FreeNode also a coc won't help. > We need a formal procedure to enable that, and the CoC is that > procedure. This "we" needs qualification. It apparently does not include me. Andre' From kevin.kofler at chello.at Sun Oct 28 15:42:45 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 28 Oct 2018 15:42:45 +0100 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> <4b21d498-c513-53e7-5c20-2e8c88aeb0db@kdab.com> <34556951-f628-6499-ee3d-3b05b69570d6@woboq.com> Message-ID: Sérgio Martins wrote: > On Sat, Oct 27, 2018 at 1:53 PM Elvis Stansvik wrote: >> Yes, I thought that Q_FOREACH was slated for deprecation though. But >> maybe that's not set in stone yet? > > It is, see Qt's documentation: > "Since Qt 5.7, the use of this macro is discouraged. It will be > removed in a future version of Qt" As long as it is not actually removed, it is not too late to undo this totally incorrect decision. See also: https://valdyas.org/fading/hacking/happy-porting/ (Technically, it could be readded even after it is removed, but it would be much easier to undeprecate it now.) Kevin Kofler From yetanotherandreyev at gmail.com Sun Oct 28 17:41:08 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Sun, 28 Oct 2018 19:41:08 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3713880.AgeDxuVClM@tjmaciei-mobl1> Message-ID: I agree my example is extremely contrived right now, I just tried to show the idea. Thank you, Elvis, for your answers. > getting your patches rejected is not harassment I agree that getting some patches rejected without any additional info is not a harassment by default I'm saying something like "water wears away a stone". What could you say about public conflicts at Opal, Github, Django, Ruby, PHP, Nodejs, Drupal, Linux after accepting similar CoC? > The patches can be respectfully rejected with e.g. "this is not in > line with the Qt vision", or "could you please revise this part > first?". It easily could be misused as blocking due to discrimination with existing CoC and the question of resources and time on both sides > See the difference? Yes, of course. But I'm not talking about where CoC could be helpful right now, I agree we need rules. I'm trying to pay attention on the current implementation. We (me too) spend literally 0 minutes to scientifically research social state of the Qt community, didn't research influence and the trends of the accepted CoC at other projects. Nobody held even one social survey about the nubmer of the conflicts at Qt project before, anything like that. Nobody tried to predict the consequences after accepting current CoC. We just trying to provide some rules and to treat something blindly without even specifying the problem. вс, 28 окт. 2018 г. в 17:35, Elvis Stansvik : > Den sön 28 okt. 2018 kl 14:29 skrev Alexey Andreyev > : > > > > > [...] or the shorter list in the KDE CoC, so we instinctively > > > want to trim the fat - we want to optimize. > > > > I've provided both (CC and from KDE) not to show some version is better, > > but to show both have same problems. > > > > For me it's not about optimization right now. Is it possible to follow > provided versions? > > And receive more positive for the commuity than negative. > > > > > the purpose of this enumeration is to list those very large > > > groups of people in society who are currently experiencing harassment > > > and mistreatment for who they are > > > > Is that obvious that provided document will help not made things worse > for everyone? > > Are we going to treat something at the commuity just blindly without > diagnosis and research? > > > > > We tell a large part of the population who are currently > > > being oppressed/mistreated that, at least in our community, you can > > > feel safe > > > > How are we going to provide safety? > > > > > The enumeration is not supposed to cover everything, but I > > > think it fulfills a purpose by covering a lot. > > > > As far as I can see the reasoning is based on the hypothesis that any > rules will not be able to aggravate the situation. It's not obvious. > > > > > I don't agree with some earlier poster who thought of the enumeration > > > as setting some kind of bar, I don't think that is the purpose of it. > > > > > The concluding "[...] or any other characteristics that are > > > not relevant to a person's ability to contribute to the Qt Project." > > > is of course very important *as well*, to cover our bases. > > > > How the committee is going to determine that someone has violated these > "guidelines not bars"? > > What is the purpose of the guidelines without additional information how > to protect them? > > > > > I can't really see how this list could be misused. If people have an > > > issue with a particular item on the list, they should say so. > > > > For example, let's say some person (person or legal entity, organization > or groups of organizations) have projects, competing with Qt somehow (or > linux, or KDE). > > That "person/groups" will get more profit if Qt community will became > unhealthy or will cease to exist. > > That person could sponsor, support or pay money somehow to other persons > to support some vulnerable ideas. > > Persons who accept that ideas and have interests, conflicting with the > community, could say something like > > "hey, we are actually feeling harassment, please accept our > ideas/patches/anything too". > > It is a space for accepting non-obvious security or architectural > changes. > > > > In 50, 10 or 5 years :) if attackers will be lucky enough, Qt community > could lost their image of as awesome commuity as it is right now. > > I honestly think this is an extremely contrived example, and I think > you're worrying way too much, but OK let's play along. > > You're suggesting that someone would submit bad patches, hoping to get > harassed and thereby somehow get the patches in, as some sort of > compensation for the harassment, and would use this in order to > sabotage the Qt project? > > Looking past the ridiculousness of that idea for the moment, getting > your patches rejected is not harassment. Not under any definition of > harassment that I know of, and certainly not according to the > suggested CoC. > > The patches can be respectfully rejected with e.g. "this is not in > line with the Qt vision", or "could you please revise this part > first?". > > The patches can also be rejected with "please don't submit crap like > this, you fat dyke". > > See the difference? > > The first is not a matter for the CoC. If the party would still file a > complaint, it would be dealt with and the council would find that no > harassment took place. The second would most certainly be cause for > some kind of action (I guess to begin with, tell the offender to not > do that again and point them to the CoC). > > Elvis > > > > > ..??? > > > > PROFIT! Young generation not interested, no support, commuity is dying, > profit for competing projects. > > > > > > It's just one example that could sound like a joke since I'm not a > professional with this kind of tricky social questions, > > but I hope I showed the danger as a caricature at least. > > > > I don't want my arguments be adressed to someone personally, and I'm not > saying there's some conspiracy here. > > I just want to help to save and develop the community for the future. > > > > I agree we need rules. My problem is not any rules are healthy. > > > > вс, 28 окт. 2018 г. в 14:37, Elvis Stansvik : > >> > >> Den sön 28 okt. 2018 kl 11:34 skrev Alexey Andreyev > >> : > >> > > >> > Hello, Tomasz! :) > >> > Thank you for the question! > >> > > >> > Current draft based on CoC: > >> > > >> > > Our Pledge > >> > > ========== > >> > > In the interest of fostering an open and welcoming environment, we > >> > > as contributors to and maintainers of the Qt Project pledge to make > >> > > participation in our project and our community a harassment-free > >> > > experience for everyone, regardless of age, body size, disability, > >> > > ethnicity, sex characteristics, gender identity and expression, > level > >> > > of experience, education, socio-economic status, nationality, > personal > >> > > appearance, race, religion, or sexual identity and orientation, > >> > > or any other characteristics that are not relevant to a person's > >> > > ability to contribute to the Qt Project. > >> > >> A lot of people seem to have a problem with this long enumeration. > >> > >> I think this is because we're programmers, and we think of it as > >> redundant given the concluding "[...] or any other characteristics > >> that are not relevant to a person's ability to contribute to the Qt > >> Project.", or the shorter list in the KDE CoC, so we instinctively > >> want to trim the fat - we want to optimize. > >> > >> But, and this is of course just my personal opinion/interpretation, I > >> think the purpose of this enumeration is to list those very large > >> groups of people in society who are currently experiencing harassment > >> and mistreatment for who they are. The pledge is supposed to be a set > >> of guidelines for how the community operates, but *also* a message to > >> potential contributors. Thought of that way, I think the enumeration > >> makes sense: We tell a large part of the population who are currently > >> being oppressed/mistreated that, at least in our community, you can > >> feel safe. The enumeration is not supposed to cover everything, but I > >> think it fulfills a purpose by covering a lot. > >> > >> I don't agree with some earlier poster who thought of the enumeration > >> as setting some kind of bar, I don't think that is the purpose of it. > >> It is meant as a message, and to drive that message home with the > >> groups of people we want to reach, I think it makes sense to be > >> explicit. The concluding "[...] or any other characteristics that are > >> not relevant to a person's ability to contribute to the Qt Project." > >> is of course very important *as well*, to cover our bases. > >> > >> If in 5, 10 or 50 years (I know, I'm a pessimist), there is no longer > >> widespread discrimination and mistreatment of people for their race, > >> religion or sexual identity/orientation, but some other groups are > >> being mistreated (again, sorry for the pessimism), then I think it's > >> perfectly fine to revise this list. > >> > >> I can't really see how this list could be misused. If people have an > >> issue with a particular item on the list, they should say so. > >> > >> That's just my 2 cents on the enumeration, which seems to bug people, > >> and I completely understand if others see it differently. > >> > >> Elvis > >> > >> > > >> > and KDE version: > >> > > >> > > We do not tolerate personal attacks, racism, sexism or any other > form of discrimination. > >> > > >> > Do we have any research about effects it leading? > >> > > >> > How many discrimination suspicions do we have right now? > >> > > >> > How could it be resolved successfully at digital community? > >> > > >> > How many misuse examples do we have at open projects since accepting > similar rules? > >> > > >> > How CoC board are going to protect community from discrimination and > harassment? > >> > > >> > Are CoC committee ready for "affirmative action"? > >> > > >> > I'm not against the rules as a concept, I agree we need it, > >> > but I totally against perverted or undefined rules that could help to > destroy the community. > >> > > >> > I could not accept argument like "let's accept just anything and see > how it goes and fix something later". > >> > "Don't code today what you can't debug tomorrow" :) > >> > > >> > I'm just saying we should think twice befoce accepting something. > >> > > >> > P.S.: I'm ready to change my mind if I've made a mistake, feel free > to criticize, correct and ignore me :) > >> > > >> > вс, 28 окт. 2018 г. в 10:47, Tomasz Siekierda : > >> >> > >> >> > The controversial discrimination protection sentences at least > should be carefully discussed. It's not some thing that we could accept as > easy as rewrite. > >> >> > >> >> Hi Alexey, I've just read the QUIP proposal and couldn't find any > >> >> controversial sentences. Could you elaborate? Which points shall be > >> >> discussed? > >> >> On Sat, 27 Oct 2018 at 22:41, Konstantin Shegunov < > kshegunov at gmail.com> wrote: > >> >> > > >> >> > On Sat, Oct 27, 2018 at 11:20 PM Thiago Macieira < > thiago.macieira at intel.com> wrote: > >> >> >> > >> >> >> The answer to all of those questions needs to be "yes". Anything > short of that > >> >> >> means the CoC is powerless and just for show. > >> >> > > >> >> > > >> >> > Which was my point exactly. > >> >> > > >> >> >> > >> >> >> Whether there's a termination of employment or not is out of > scope, since the > >> >> >> CoC does not rule TQtC employment and what other work there is > inside that > >> >> >> company. > >> >> >> > >> >> >> > >> >> >> Note also it applies to any company. If you're not welcome > anymore in the > >> >> >> community where your employer is asking you to do work, that is > going to > >> >> >> affect your employment. > >> >> > > >> >> > > >> >> > I agree. However my argument was that the QtC being a major > contributor to the codebase is going to have to abide by the ruling of the > proposed committee, which is a significant commitment (and a major nitpick > I admit). > >> >> > _______________________________________________ > >> >> > Development mailing list > >> >> > Development at qt-project.org > >> >> > http://lists.qt-project.org/mailman/listinfo/development > >> >> _______________________________________________ > >> >> Development mailing list > >> >> Development at qt-project.org > >> >> http://lists.qt-project.org/mailman/listinfo/development > >> > > >> > _______________________________________________ > >> > Development mailing list > >> > Development at qt-project.org > >> > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.edwards at kitware.com Sun Oct 28 18:59:07 2018 From: kyle.edwards at kitware.com (Kyle Edwards) Date: Sun, 28 Oct 2018 13:59:07 -0400 Subject: [Development] How to create dummy plugins in qtbase? Message-ID: Hello all, I am currently working on improving Qt's CMake support, and I've written some rather complicated logic that I want to test thoroughly - specifically, I want to make sure that an exact list of plugins that I've requested has been statically loaded, no more, and no less. The easiest way to do this would be to create a new dummy Qt module which contains a bunch of dummy plugins for me to load. However, I'm not sure how to create a new Qt module that's visible to the tests without also being installed/visible outside the tests. I've attempted to hack together an external project outside the qtbase tree that creates some plugins, but I'm not very familiar with qmake, and in its current state it is installing its plugins into the qtbase build tree, which is undesirable (I want it to install them into its own build tree instead.) Can someone who's more familiar with qmake help me out here? Thank you very much. Kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From giuseppe.dangelo at kdab.com Sun Oct 28 19:34:19 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Sun, 28 Oct 2018 19:34:19 +0100 Subject: [Development] Undeprecating Q_FOREACH (was: Re: qMoveToConst helper for rvalue references to movable Qt containers?) In-Reply-To: References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> <4b21d498-c513-53e7-5c20-2e8c88aeb0db@kdab.com> <34556951-f628-6499-ee3d-3b05b69570d6@woboq.com> Message-ID: Il 28/10/18 15:42, Kevin Kofler ha scritto: > As long as it is not actually removed, it is not too late to undo this > totally incorrect decision. > > See also:https://valdyas.org/fading/hacking/happy-porting/ > > (Technically, it could be readded even after it is removed, but it would be > much easier to undeprecate it now.) Please bring technical arguments to the table for undoing this deprecation. So far, this hasn't been done, so the deprecation stands and likely go into effect the first time we get a chance of breaking SC. Note that "annoyance for end-users" is not an argument. In the absence of infinite development bandwidth, and given the natural evolution of software, Qt will need to shed some old crust from time to time, even if that means annoyances for the users. I briefly discussed about this here: > https://www.kdab.com/un-deprecate-qt-project/ Specifically for Q_FOREACH, if a project doesn't want to move away, then the solution takes 5 minutes: 1) copy and paste Q_FOREACH's implementation in a central header of your project 2) rename it to MY_FOREACH 3) do a search/replace of Q_FOREACH to MY_FOREACH throughout the project's code base And that's it. Yes, this is effectively a fork, which means you'll also need to backport any fixes that in the meanwhile land upstream. And they _do land_, even for something apparently as "mundane" as Q_FOREACH: > https://codereview.qt-project.org/#/c/179396/ > https://codereview.qt-project.org/#/c/176299/ > https://codereview.qt-project.org/#/c/176298/ > https://codereview.qt-project.org/#/c/170073/ > https://codereview.qt-project.org/#/c/167065/ > https://codereview.qt-project.org/#/c/140268/ Why should the Qt Project invest any resource whatsoever maintaining a solution to a problem that has also been solved by the C++ language (and in a more efficient and general way than Q_FOREACH)? -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From olivier at woboq.com Sun Oct 28 19:49:08 2018 From: olivier at woboq.com (Olivier Goffart) Date: Sun, 28 Oct 2018 19:49:08 +0100 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> <4b21d498-c513-53e7-5c20-2e8c88aeb0db@kdab.com> <34556951-f628-6499-ee3d-3b05b69570d6@woboq.com> Message-ID: On 10/27/18 5:27 PM, Sérgio Martins wrote: >> Den lör 27 okt. 2018 kl 13:37 skrev Olivier Goffart : >>> Jokes aside, I think we still should let users use Q_FOREACH for implicitly >>> shared containers. > > But what's the percentage of Qt developers that understand the > subtleties between Q_FOREACH and range-for ? > Having a toolbox with two similar-but-not-quite constructs is bad for > less seasoned users. > I prefer explicitly assigning the container to a const local variable > instead of relying in the magic behind macros. I don't know... what's the percentage of Qt developers that understands when to use this qAsConst or const copy gymnastic? It is a bit ironic that one reason given to deprecate Q_FOREACH is that it may copy the container in some cases, while the alternative has the same problem in much more common cases. (It is my impression that implicitly shared container such as QList/QVector are by far much more used than the one that are not within a typical Qt code base) What could be done is to only deprecate partial specialization of qMakeForeachContainer for QVarLenghtArray and the standard containers. Or for containers that do not have a 'detach' function. That way, users would get a warning for the problematic containers, but would continue to work just fine with with the containers most Qt developer use. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From thiago.macieira at intel.com Sun Oct 28 20:10:00 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 28 Oct 2018 12:10:00 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <20181028153617.GA1855@klara.mpi.htwm.de> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <20181028153617.GA1855@klara.mpi.htwm.de> Message-ID: <22401396.2MeYvLZH0H@tjmaciei-mobl1> On Sunday, 28 October 2018 08:36:17 PDT André Pönitz wrote: > That would be a valid reason in case there had been or we would > expect to be unstoppable abusive behaviour. > > Most abusive behaviour on the mailing lists and IRC can be > stopped by technical means, in exceptional cases like the recent > spam attack on FreeNode also a coc won't help. Spam is pretty obvious, since spammy messages are off-topic and the spammer is not going to bother contesting the filter. But if it isn't spam, what gives the list moderator the right to intervene in something that he/she believes is abusive behaviour? Same thing about IRC: we do have one annoying person who does come along every now and then, but most of his messages are just that: annoyance. It's only when he uses profanity that I feel justified in kicking him out of the channel. Am I the one abusing my position as channel op to kick him? Am I being arbitrary? > > We need a formal procedure to enable that, and the CoC is that > > procedure. > > This "we" needs qualification. It apparently does not include me. Of course it does. Why do you feel excluded? Or did you mean you feel you don't need a procedure? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Oct 28 20:17:25 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 28 Oct 2018 12:17:25 -0700 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: Message-ID: <2935486.kRNsAma0Ab@tjmaciei-mobl1> On Sunday, 28 October 2018 11:49:08 PDT Olivier Goffart wrote: > It is a bit ironic that one reason given to deprecate Q_FOREACH is that it > may copy the container in some cases, while the alternative has the same > problem in much more common cases. (It is my impression that implicitly > shared container such as QList/QVector are by far much more used than the > one that are not within a typical Qt code base) There are two problems with Q_FOREACH: 1) it will copy containers. For Qt containers, that's rather cheap (two atomic refcount operations), but it's not free. And for Standard Library containers, that is likely very expensive. 2) it's implemented by way of a for loop inside a for loop, which is known to throw optimisers out, generating slightly worse code Our rule already was: Don't use foreach in Qt code. (it was fine in examples) Using iterators and now using the ranged for may need more typing, but produces optimal code. > What could be done is to only deprecate partial specialization of > qMakeForeachContainer for QVarLenghtArray and the standard containers. > Or for containers that do not have a 'detach' function. > That way, users would get a warning for the problematic containers, but > would continue to work just fine with with the containers most Qt developer > use. I disagree. The optimisation problem is not solved. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sierdzio at gmail.com Sun Oct 28 20:29:00 2018 From: sierdzio at gmail.com (Tomasz Siekierda) Date: Sun, 28 Oct 2018 20:29:00 +0100 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3713880.AgeDxuVClM@tjmaciei-mobl1> Message-ID: > > вс, 28 окт. 2018 г. в 10:47, Tomasz Siekierda : > > Hi Alexey, I've just read the QUIP proposal and couldn't find any > > controversial sentences. Could you elaborate? Which points shall be > > discussed? > > > > > The controversial discrimination protection sentences at least should be carefully discussed. It's not some thing that we could accept as easy as rewrite. On Sun, 28 Oct 2018 at 11:34, Alexey Andreyev wrote: > > Hello, Tomasz! :) > Thank you for the question! > > > [...] > > Do we have any research about effects it leading? > > How many discrimination suspicions do we have right now? > > How could it be resolved successfully at digital community? > > How many misuse examples do we have at open projects since accepting similar rules? > > How CoC board are going to protect community from discrimination and harassment? > > Are CoC committee ready for "affirmative action"? > > [...] So, as far as I see you have not identified any controversial sentences either, your questions are more general and have been answered already (see people reporting on successes of KDE CoC and problems with kernel one). Regarding: > How CoC board are going to protect community from discrimination and harassment? The text is clear - actions will be taken to stop the discrimination. That involves technical means (kick / ban) but also more social means (talking with both parties, trying to mediate, trying to understand what is going on etc. - all this is mentioned in CoC draft). From thiago.macieira at intel.com Sun Oct 28 04:13:47 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 27 Oct 2018 20:13:47 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3713880.AgeDxuVClM@tjmaciei-mobl1> Message-ID: <29700408.okRehY1OKL@tjmaciei-mobl1> On Saturday, 27 October 2018 13:40:42 PDT Konstantin Shegunov wrote: > > Note also it applies to any company. If you're not welcome anymore in the > > community where your employer is asking you to do work, that is going to > > affect your employment. > > I agree. However my argument was that the QtC being a major contributor to > the codebase is going to have to abide by the ruling of the proposed > committee, which is a significant commitment (and a major nitpick I admit). Correct, they would have to, but given that it looks like the majority of them are in agreement, it doesn't look problematic. And besides, if any of them or the KDABians started being obnoxious and hostile, given how many of their coworkers are working on this project, I'm pretty sure their company HR would want to have a chat anyway. That's also a good reason to choose the KDE CoC, as both TQtC and KDAB recruit heavily from the KDE community and its CoC is basically a statement of shared values. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From yetanotherandreyev at gmail.com Sun Oct 28 21:18:02 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Sun, 28 Oct 2018 23:18:02 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3713880.AgeDxuVClM@tjmaciei-mobl1> Message-ID: > So, as far as I see you have not identified any controversial > sentences either I've defined controversial sentences previously about proposed harassment-free pledge part and KDE's protection from discrimination part. > see people reporting on successes of KDE CoC and > problems with kernel one Could you provide the link with research or any other details about successes of the KDE CoC? > The text is clear - actions will be taken to stop the discrimination. > That involves technical means (kick / ban) but also more social means It is not clear. Intruder could ask to ban some person pretending it's discrimination problem. intruder could ask to accept vulnerable changes. All the described situations requires resources from the community. It also could be used to something could be called denial-of-community situation. In general, it could be used to change the image of the community to made it less popular and decrease the number of new members. Anyway, I guess there's still no scientific research and social survey about the number of the situations that could be called conflicts. So I don't see what problem should be solved right now. I could not accept an answer like "let's try and see" since we didn't even proposed metrics how to check new CoC is helping. вс, 28 окт. 2018 г. в 22:29, Tomasz Siekierda : > > > вс, 28 окт. 2018 г. в 10:47, Tomasz Siekierda : > > > Hi Alexey, I've just read the QUIP proposal and couldn't find any > > > controversial sentences. Could you elaborate? Which points shall be > > > discussed? > > > > > > > The controversial discrimination protection sentences at least > should be carefully discussed. It's not some thing that we could accept as > easy as rewrite. > > On Sun, 28 Oct 2018 at 11:34, Alexey Andreyev > wrote: > > > > Hello, Tomasz! :) > > Thank you for the question! > > > > > > [...] > > > > Do we have any research about effects it leading? > > > > How many discrimination suspicions do we have right now? > > > > How could it be resolved successfully at digital community? > > > > How many misuse examples do we have at open projects since accepting > similar rules? > > > > How CoC board are going to protect community from discrimination and > harassment? > > > > Are CoC committee ready for "affirmative action"? > > > > [...] > > So, as far as I see you have not identified any controversial > sentences either, your questions are more general and have been > answered already (see people reporting on successes of KDE CoC and > problems with kernel one). > > Regarding: > > > How CoC board are going to protect community from discrimination and > harassment? > > The text is clear - actions will be taken to stop the discrimination. > That involves technical means (kick / ban) but also more social means > (talking with both parties, trying to mediate, trying to understand > what is going on etc. - all this is mentioned in CoC draft). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kshegunov at gmail.com Sun Oct 28 22:02:49 2018 From: kshegunov at gmail.com (Konstantin Shegunov) Date: Sun, 28 Oct 2018 23:02:49 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3844322.YypU1izrmg@tjmaciei-mobl1> <0e234f3c30608991ee64882ca30933ebfadba344.camel@bernhard-lindner.de> <7304455.ZYRPdxLY82@tjmaciei-mobl1> <93296ea28154daeee5607b87ef26310a28dc7cf7.camel@bernhard-lindner.de> Message-ID: On Sun, Oct 28, 2018 at 2:08 PM Martin Smith wrote: > No, it isn't a resolution. Not reacting to a complaint is no resolution. Given the (current) structure of the community I take that as the offence not carrying merit. But even if "the community" does react to the alleged offense, how is that > different from mob rule? > It is not. Note that having a committee doesn't exclude mob rule either. In all fairness, though, it makes it less likely, as I can easily imagine the people voted in are going to be of significant integrity. >Not only can I, I pretty much have to. > > No. You don't. You used the word "heinous." It has a meaning. You used it > deliberately to draw attention away from the problems the CoC is meant to > resolve. > I did no such thing, and I resent the accusation. I'm not defending the CoC text and premise. I'm defending the goal of > establishing a CoC. > Then I have no idea why we are arguing. I was just responding in good faith to a question that was put forth. From the very beginning of this thread I have operated under the assumption that a CoC is going to be adopted in some form or another. My turn to bite. What is a heinous act that is not a criminal act? > Personal attacks, baseless accusations, mean-spirited comments, a combination thereof. Anything that's beyond distasteful, but still doesn't constitute a crime. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kshegunov at gmail.com Sun Oct 28 22:04:11 2018 From: kshegunov at gmail.com (Konstantin Shegunov) Date: Sun, 28 Oct 2018 23:04:11 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <29700408.okRehY1OKL@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <3713880.AgeDxuVClM@tjmaciei-mobl1> <29700408.okRehY1OKL@tjmaciei-mobl1> Message-ID: On Sun, Oct 28, 2018 at 9:51 PM Thiago Macieira wrote: > I'm pretty sure their company HR would want to have a chat anyway. > Well, I'm not as sure as you, but I am hopeful. > That's also a good reason to choose the KDE CoC, as both TQtC and KDAB > recruit > heavily from the KDE community and its CoC is basically a statement of > shared > values. > A very good point. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sun Oct 28 22:27:38 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 28 Oct 2018 14:27:38 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <29700408.okRehY1OKL@tjmaciei-mobl1> Message-ID: <1988001.CJqIEh3YNP@tjmaciei-mobl1> On Sunday, 28 October 2018 14:04:11 PDT Konstantin Shegunov wrote: > > I'm pretty sure their company HR would want to have a chat anyway. > > Well, I'm not as sure as you, but I am hopeful. Then trust me. I know a lot of people in those two companies, I am from the same background as most of them (KDE community) and I have worked for Trolltech, whose values and ethic remain in TQtC. So trust me when I say they, like my colleagues at Intel right now, are expected to behave themselves according to rules very similar, if not identical, to those set forth in the CC and KDE CoC. And here's the cinch: would *you*, Konstantin, feel qualified to contact their HR? Do you even know whom to contact? This is where the CoC committee can come in, because they have the community standing to contact an HR representative or the person's manager to see if they can also be of help. Maybe those two are aware of this person going through a rough patch in their lives and could advise in other ways to solve the situation. Note I didn't say "contact to get them fired", but "to see if they can be of help". We don't want to lose the contributor, we want to see the situation resolved in such a way that we keep both parties. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Oct 28 22:17:15 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 28 Oct 2018 14:17:15 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: <1613934.u2FelxWX76@tjmaciei-mobl1> On Sunday, 28 October 2018 13:18:02 PDT Alexey Andreyev wrote: > > The text is clear - actions will be taken to stop the discrimination. > > That involves technical means (kick / ban) but also more social means > > It is not clear. Intruder could ask to ban some person pretending it's > discrimination problem. Sure, but again that's why we have a committee behind who will evaluate the charges and decide what the proper action to be taken is. If the charges are fake, then the accused would of course not be affected in any way. And if the accuser keeps making false accusations, that's the one who could face sanctions. > intruder could ask to accept vulnerable changes. And why would you or an approver accept technically inferior solutions? No one is saying that we should do that. All that is required is to be civil and harassment-free when discussing such a solution. > All the described situations requires resources from the community. > It also could be used to something could be called denial-of-community > situation. Yes, it does require resources from the community. No one said that keeping a community welcoming is free. It requires all of us to look after one another and our shared values. But I think it's a price we're willing to pay. And I'm pretty sure the KDE Community WG can easily compile a list of times that they were maliciously asked to look into situations and how much time it took them to give it the attention it was due. > In general, it could be used to change the image of the community to made > it less popular > and decrease the number of new members. How could it be used to do that? > Anyway, I guess there's still no scientific research and social survey > about the number of the situations that could be called conflicts. > So I don't see what problem should be solved right now. First of all, there are enough situations handled by multiple CoC committees in several communities to prove that it's worth it. There have been situations when they've been called to act and they have. I'd like to know about situations that were resolved peacefully and the person who was found to be doing harassing changed their behaviour. As for a scientific research, it's pretty hard with social situations, like almost anything related to people's behaviour: communities are different from one another and you can't have a control group to see what happens if you don't adopt a CoC. > I could not accept an answer like "let's try and see" since we didn't even > proposed metrics how to check new CoC is helping. Tell us how to measure the benefit compared to not having a CoC. I'll be very satisfied even if we have a total of zero times the CoC acts in the next 5 years and that no new contributor mentions reading the CoC before joining the community. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kshegunov at gmail.com Sun Oct 28 22:57:42 2018 From: kshegunov at gmail.com (Konstantin Shegunov) Date: Sun, 28 Oct 2018 23:57:42 +0200 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <1988001.CJqIEh3YNP@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <29700408.okRehY1OKL@tjmaciei-mobl1> <1988001.CJqIEh3YNP@tjmaciei-mobl1> Message-ID: On Sun, Oct 28, 2018 at 11:27 PM Thiago Macieira wrote: > > Well, I'm not as sure as you, but I am hopeful. > > Then trust me. I know a lot of people in those two companies, I am from > the > same background as most of them (KDE community) and I have worked for > Trolltech, whose values and ethic remain in TQtC. > > So trust me when I say they, like my colleagues at Intel right now, are > expected to behave themselves according to rules very similar, if not > identical, to those set forth in the CC and KDE CoC. > Okay, I have no reason to doubt it. I only meant I have no personal experience to base my conviction on, unlike you. And here's the cinch: would *you*, Konstantin, feel qualified to contact > their > HR? Do you even know whom to contact? Probably not. Granted I'm arrogant enough to send a hot mail to some person at the company, but I would hardly expect a response out of such a thing. This is where the CoC committee can come > in, because they have the community standing to contact an HR > representative > or the person's manager to see if they can also be of help. Maybe those > two > are aware of this person going through a rough patch in their lives and > could > advise in other ways to solve the situation. > > Note I didn't say "contact to get them fired", but "to see if they can be > of > help". We don't want to lose the contributor, we want to see the situation > resolved in such a way that we keep both parties. > I grant you that one. I still believe the enforcement and internal details should be separate from the main text, but that's a minor detail at this point. Note: I continue to think that KDE's CoC's text is written better and more clearly. On Sun, Oct 28, 2018 at 11:44 PM Thiago Macieira wrote: > On Sunday, 28 October 2018 13:18:02 PDT Alexey Andreyev wrote: > > > The text is clear - actions will be taken to stop the discrimination. > > > That involves technical means (kick / ban) but also more social means > > > > It is not clear. Intruder could ask to ban some person pretending it's > > discrimination problem. > > And I'm pretty sure the KDE Community WG can easily compile a list of > times > that they were maliciously asked to look into situations and how much time > it > took them to give it the attention it was due. > That'd be interesting to see, even if only out of curiosity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lydia at kde.org Mon Oct 29 00:53:01 2018 From: lydia at kde.org (Lydia Pintscher) Date: Mon, 29 Oct 2018 00:53:01 +0100 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <1613934.u2FelxWX76@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <1613934.u2FelxWX76@tjmaciei-mobl1> Message-ID: On Sun, Oct 28, 2018 at 10:45 PM Thiago Macieira wrote: > And I'm pretty sure the KDE Community WG can easily compile a list of times > that they were maliciously asked to look into situations and how much time it > took them to give it the attention it was due. I don't have an exact number but less than 10. And we could always deal with it very quickly thanks to some common sense and good knowledge of the situation and people involved. No big deal. (For those who don't know me: I'm one of the people who wrote KDE's CoC and has been a member of it's community working group since then. I'm also the current president of the non-profit behind KDE.) If you have further questions about KDE's Code of Conduct please let me know. I'm happy to answer them. Cheers Lydia PS: As someone on the fringes of the Qt Project some emails in this thread sadly make me see part of the project in a different light. I fear I'm not the only one. -- Lydia Pintscher - http://about.me/lydia.pintscher KDE e.V. Board of Directors http://kde.org - http://open-advice.org From yetanotherandreyev at gmail.com Mon Oct 29 01:20:04 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Mon, 29 Oct 2018 03:20:04 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <1613934.u2FelxWX76@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <1613934.u2FelxWX76@tjmaciei-mobl1> Message-ID: > Sure, but again that's why we have a committee behind who will evaluate the > charges and decide what the proper action to be taken is. If the charges are > fake, then the accused would of course not be affected in any way. And if the > accuser keeps making false accusations, that's the one who could face > sanctions. Sanctions like ban with additional false accusations about harassment could be sent to mass media to create negative image of the community. > No one said that keeping a > community welcoming is free. It requires all of us to look after one another > and our shared values. > But I think it's a price we're willing to pay. I'm not saying we should not work on shared values. As I said earlier many times, I agree we need rules. Let's take a look at archlinux CoC for example: https://wiki.archlinux.org/index.php/Code_of_conduct Literally no vulnerable promises about protecting from harassment that could be hard to keep. Additional mention at archwiki not to play with controvertial non-related subjects at technical place: "The staff certainly realize that such issues are deeply ingrained human realities. However, this is a technical community and is not intended nor able to effectively facilitate such commentary nor the resulting unrest." > And I'm pretty sure the KDE Community WG can easily compile a list of times > that they were maliciously asked to look into situations and how much time it > took them to give it the attention it was due. Thank you! It would be nice to see with general numbers, to make a comparison, but I agree it is very hard to research > Tell us how to measure the benefit compared to not having a CoC. I never said we don't need a CoC. I've said that not any CoC is healthy. пн, 29 окт. 2018 г. в 0:44, Thiago Macieira : > On Sunday, 28 October 2018 13:18:02 PDT Alexey Andreyev wrote: > > > The text is clear - actions will be taken to stop the discrimination. > > > That involves technical means (kick / ban) but also more social means > > > > It is not clear. Intruder could ask to ban some person pretending it's > > discrimination problem. > > Sure, but again that's why we have a committee behind who will evaluate > the > charges and decide what the proper action to be taken is. If the charges > are > fake, then the accused would of course not be affected in any way. And if > the > accuser keeps making false accusations, that's the one who could face > sanctions. > > > intruder could ask to accept vulnerable changes. > > And why would you or an approver accept technically inferior solutions? No > one > is saying that we should do that. All that is required is to be civil and > harassment-free when discussing such a solution. > > > All the described situations requires resources from the community. > > It also could be used to something could be called denial-of-community > > situation. > > Yes, it does require resources from the community. No one said that > keeping a > community welcoming is free. It requires all of us to look after one > another > and our shared values. > > But I think it's a price we're willing to pay. > > And I'm pretty sure the KDE Community WG can easily compile a list of > times > that they were maliciously asked to look into situations and how much time > it > took them to give it the attention it was due. > > > In general, it could be used to change the image of the community to made > > it less popular > > and decrease the number of new members. > > How could it be used to do that? > > > Anyway, I guess there's still no scientific research and social survey > > about the number of the situations that could be called conflicts. > > So I don't see what problem should be solved right now. > > First of all, there are enough situations handled by multiple CoC > committees > in several communities to prove that it's worth it. There have been > situations > when they've been called to act and they have. I'd like to know about > situations that were resolved peacefully and the person who was found to > be > doing harassing changed their behaviour. > > As for a scientific research, it's pretty hard with social situations, > like > almost anything related to people's behaviour: communities are different > from > one another and you can't have a control group to see what happens if you > don't adopt a CoC. > > > I could not accept an answer like "let's try and see" since we didn't > even > > proposed metrics how to check new CoC is helping. > > Tell us how to measure the benefit compared to not having a CoC. > > I'll be very satisfied even if we have a total of zero times the CoC acts > in > the next 5 years and that no new contributor mentions reading the CoC > before > joining the community. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yetanotherandreyev at gmail.com Mon Oct 29 01:24:52 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Mon, 29 Oct 2018 03:24:52 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <1613934.u2FelxWX76@tjmaciei-mobl1> Message-ID: Thank you, Lydia and everyone! I hope I'm not upsetting anyone. I could accept I'm taking too much attention to the subject. Qt project is very valuable for me as a user and a developer. пн, 29 окт. 2018 г. в 2:53, Lydia Pintscher : > On Sun, Oct 28, 2018 at 10:45 PM Thiago Macieira > wrote: > > And I'm pretty sure the KDE Community WG can easily compile a list of > times > > that they were maliciously asked to look into situations and how much > time it > > took them to give it the attention it was due. > > I don't have an exact number but less than 10. And we could always > deal with it very quickly thanks to some common sense and good > knowledge of the situation and people involved. No big deal. > > (For those who don't know me: I'm one of the people who wrote KDE's > CoC and has been a member of it's community working group since then. > I'm also the current president of the non-profit behind KDE.) > If you have further questions about KDE's Code of Conduct please let > me know. I'm happy to answer them. > > > Cheers > Lydia > > PS: As someone on the fringes of the Qt Project some emails in this > thread sadly make me see part of the project in a different light. I > fear I'm not the only one. > > -- > Lydia Pintscher - http://about.me/lydia.pintscher > KDE e.V. Board of Directors > http://kde.org - http://open-advice.org > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Oct 29 04:45:42 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 28 Oct 2018 20:45:42 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <1988001.CJqIEh3YNP@tjmaciei-mobl1> Message-ID: <1724833.CAE3hiklg8@tjmaciei-mobl1> On Sunday, 28 October 2018 14:57:42 PDT Konstantin Shegunov wrote: > Note: I continue to think that KDE's CoC's text is written better and more > clearly. me too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Oct 29 04:52:53 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 28 Oct 2018 20:52:53 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <1613934.u2FelxWX76@tjmaciei-mobl1> Message-ID: <2635333.mRs2FyqhBL@tjmaciei-mobl1> On Sunday, 28 October 2018 16:53:01 PDT Lydia Pintscher wrote: > On Sun, Oct 28, 2018 at 10:45 PM Thiago Macieira > > wrote: > > And I'm pretty sure the KDE Community WG can easily compile a list of > > times > > that they were maliciously asked to look into situations and how much time > > it took them to give it the attention it was due. > > I don't have an exact number but less than 10. And we could always > deal with it very quickly thanks to some common sense and good > knowledge of the situation and people involved. No big deal. Hi Lydia Thanks for chiming in. Note I asked about malicious request to the CWG, not legitimate ones. I mean baseless accusations, based on no actual fact, just attempts to smear someone or generate useless expediture of people's time. Has that happened, at all? If so, how long did the committee spend addressing it? How much effort was put into it? Maybe we can also expand to accusations that, though not malicious, were found not to be under the CoC's purview, like asking someone to be removed due to some action on their personal time. > PS: As someone on the fringes of the Qt Project some emails in this > thread sadly make me see part of the project in a different light. I > fear I'm not the only one. You must remember we discussion we had in KDE 10 years ago. As I wrote in my email here, I was one of those not convinced of the need to have a text at all, and I do think several other proeminent community members were like me. But the discussion went through and we were won out. Now I see the value of it that I didn't then. Almost all the emails in this thread have been civil and willing to engage in discussion, though not without some language barriers sometimes. I'm not seeing anyone in a different light as I did a week ago. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Oct 29 05:08:42 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 28 Oct 2018 21:08:42 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <1613934.u2FelxWX76@tjmaciei-mobl1> Message-ID: <57137783.Y9GKUMOgDo@tjmaciei-mobl1> On Sunday, 28 October 2018 17:20:04 PDT Alexey Andreyev wrote: > > Sure, but again that's why we have a committee behind who will evaluate > the > > charges and decide what the proper action to be taken is. If the charges > are > > fake, then the accused would of course not be affected in any way. And if > the > > accuser keeps making false accusations, that's the one who could face > > sanctions. > > Sanctions like ban with additional false accusations about harassment could > be sent to mass media to create negative image of the community. And if the mass media does buy into the fake story, what can we do? The attacker can seize on any particular point of our community, whether there's a CoC or not. They could attack us for *not* having one in the first place and having no method to address their fake injutsice. They could attack us for having a security mailing list that judged a particular issue they reported not to be a security problem, etc. If they want to be malicious, they'll find a way. And if the media sides with them, not giving us a chance to explain, what are we going to do? > Let's take a look at archlinux CoC for example: > https://wiki.archlinux.org/index.php/Code_of_conduct > > Literally no vulnerable promises about protecting from harassment that > could be hard to keep. Additional mention at archwiki not to play with > controvertial non-related subjects at technical place: Which promises in other CoCs do you find vulnerable? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From yetanotherandreyev at gmail.com Mon Oct 29 08:52:49 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Mon, 29 Oct 2018 10:52:49 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <57137783.Y9GKUMOgDo@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <1613934.u2FelxWX76@tjmaciei-mobl1> <57137783.Y9GKUMOgDo@tjmaciei-mobl1> Message-ID: > If they want to be malicious, they'll find a way. Opposite extreme is "who cares, let's accept something and sort it out on the go later" > Which promises in other CoCs do you find vulnerable? Talking about CC and KDE's CoC, it's not obvious for me how to perform politics, religion, race, etc -- harassment protection correctly at international digital community with provided rules. I'm not saying we don't need rules. You said KDE's version looks better comparing to CC. Archlinux version looks even better for me. Anyway, I'm not a professional at such social tasks and want to step back. I do not want to look like annoying person, just wanted to help with controversial subjects. I have no doubts about Qt people professionalism and happy do be a part of the community. пн, 29 окт. 2018 г. в 7:08, Thiago Macieira : > On Sunday, 28 October 2018 17:20:04 PDT Alexey Andreyev wrote: > > > Sure, but again that's why we have a committee behind who will evaluate > > the > > > charges and decide what the proper action to be taken is. If the > charges > > are > > > fake, then the accused would of course not be affected in any way. And > if > > the > > > accuser keeps making false accusations, that's the one who could face > > > sanctions. > > > > Sanctions like ban with additional false accusations about harassment > could > > be sent to mass media to create negative image of the community. > > And if the mass media does buy into the fake story, what can we do? The > attacker can seize on any particular point of our community, whether > there's a > CoC or not. They could attack us for *not* having one in the first place > and > having no method to address their fake injutsice. They could attack us for > having a security mailing list that judged a particular issue they > reported > not to be a security problem, etc. > > If they want to be malicious, they'll find a way. > > And if the media sides with them, not giving us a chance to explain, what > are > we going to do? > > > Let's take a look at archlinux CoC for example: > > https://wiki.archlinux.org/index.php/Code_of_conduct > > > > Literally no vulnerable promises about protecting from harassment that > > could be hard to keep. Additional mention at archwiki not to play with > > controvertial non-related subjects at technical place: > > Which promises in other CoCs do you find vulnerable? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Uwe.Rathmann at tigertal.de Mon Oct 29 09:40:03 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Mon, 29 Oct 2018 08:40:03 +0000 (UTC) Subject: [Development] QUIP 12: Code of Conduct References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <1613934.u2FelxWX76@tjmaciei-mobl1> Message-ID: On Mon, 29 Oct 2018 00:53:01 +0100, Lydia Pintscher wrote: > PS: As someone on the fringes of the Qt Project some emails in this > thread sadly make me see part of the project in a different light. I'm not too much interested in the topic of an CoC - not even in the discussion about it - but that doesn't mean, that it should not be allowed to have it here. But in this whole thread there is indeed one posting, that annoys me - and this is yours. I will never understand, why someone feels entitled to judge others so easily - and in your case without even giving any indication about what you are referring to. > I fear I'm not the only one. I guess you are. Nothing for ungood, Uwe From Liang.Qi at qt.io Mon Oct 29 10:18:12 2018 From: Liang.Qi at qt.io (Liang Qi) Date: Mon, 29 Oct 2018 09:18:12 +0000 Subject: [Development] Merge and Integration status report - 2018.10.29 Message-ID: <8FA6C2BD-BB1D-4C90-858F-FE460346F2F7@qt.io> Integrations * qt5 5.9/5.11/5.12/dev integrations are healthy Merges * qtdeclarative 5.11->5.12 merge(10 days) is ongoing, https://codereview.qt-project.org/#/c/243050/ * qtbase 5.11->5.12 merge, need help, https://codereview.qt-project.org/#/c/243826/ * qtbase 5.12->dev merged on Saturday, https://codereview.qt-project.org/#/c/243500/ I will check other 5.11->5.12 merges today before the latest 5.12->5.12.0 final down merge. Provisionings * qt5 5.12: Android NDK(r18b) and SDK updated on all host platforms on Oct. 20 * qt5 dev: Trying to integrate https://codereview.qt-project.org/#/c/240554/ (Docker Provisioning: Install Docker-based test servers on macOS) soon -- Liang From Oswald.Buddenhagen at qt.io Mon Oct 29 11:30:48 2018 From: Oswald.Buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 29 Oct 2018 10:30:48 +0000 Subject: [Development] How to create dummy plugins in qtbase? In-Reply-To: References: Message-ID: <20181029103046.GA1270@troll08> On Sun, Oct 28, 2018 at 01:59:07PM -0400, Kyle Edwards wrote: > However, I'm not sure how to create a new Qt module that's visible > to the tests without also being installed/visible outside the > tests. > that's an unsolved problem. qtmultimedia/tests/auto/unit/qmediaserviceprovider also just installs them "for real". From olivier at woboq.com Mon Oct 29 12:43:09 2018 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 29 Oct 2018 12:43:09 +0100 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <2935486.kRNsAma0Ab@tjmaciei-mobl1> References: <2935486.kRNsAma0Ab@tjmaciei-mobl1> Message-ID: On 10/28/18 8:17 PM, Thiago Macieira wrote: > On Sunday, 28 October 2018 11:49:08 PDT Olivier Goffart wrote: >> It is a bit ironic that one reason given to deprecate Q_FOREACH is that it >> may copy the container in some cases, while the alternative has the same >> problem in much more common cases. (It is my impression that implicitly >> shared container such as QList/QVector are by far much more used than the >> one that are not within a typical Qt code base) > > There are two problems with Q_FOREACH: > > 1) it will copy containers. For Qt containers, that's rather cheap (two atomic > refcount operations), but it's not free. And for Standard Library containers, > that is likely very expensive. But using for(:) with a Qt container will cause a detach in the most common case, so I'd say is even worse. Which is why i'm saying using this reason is a bit ironic. > > 2) it's implemented by way of a for loop inside a for loop, which is known to > throw optimisers out, generating slightly worse code I would consider that the missed optimization is quite small, if not negligible. And it can be solved in C++17: https://codereview.qt-project.org/243984/ > Our rule already was: Don't use foreach in Qt code. (it was fine in examples) > > Using iterators and now using the ranged for may need more typing, but > produces optimal code. > >> What could be done is to only deprecate partial specialization of >> qMakeForeachContainer for QVarLenghtArray and the standard containers. >> Or for containers that do not have a 'detach' function. >> That way, users would get a warning for the problematic containers, but >> would continue to work just fine with with the containers most Qt developer >> use. > > I disagree. The optimisation problem is not solved. I'm ok with discouraging Q_FOREACH, but deprecating such a function need more thinking. Deprecating means you will force user to port all their codebase away from it, which is a huge work. If the rationale is just that they will save a couple of atomic operations, i do not think it is worth it. Deprecating it only for non-shared container seems more logical, since we then warn only when there is actually a problem. And for the Qt shared container case, using foreach is less typing, but also less error prone. (do i have to use qAsConst? or make a copy? or even return a const object which even lead to more problems) -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From andre.hartmann at iseg-hv.de Mon Oct 29 13:00:07 2018 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Mon, 29 Oct 2018 13:00:07 +0100 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: <2935486.kRNsAma0Ab@tjmaciei-mobl1> Message-ID: <4acb56ff-d382-01b5-346f-5c40b6b003ed@iseg-hv.de> Hi all, I fully agree, Olivier. Looking at https://docs.kdab.com/analysis/qtcreator/clazy.html gives currently 223 potential detaching containers within range-based for, and qtbase alone has 46 (https://docs.kdab.com/analysis/qt5/clazy.html). Even if there may be some false positives, who is going to check and fix them all? If we don't manage to use the range-based for correctly (for Qt-containers), why should we force the user to port away from foreach? Just my two cent. Best regards, André Am 29.10.18 um 12:43 schrieb Olivier Goffart: > On 10/28/18 8:17 PM, Thiago Macieira wrote: >> On Sunday, 28 October 2018 11:49:08 PDT Olivier Goffart wrote: >>> It is a bit ironic that one reason given to deprecate Q_FOREACH is >>> that it >>> may copy the container in some cases, while the alternative has the same >>> problem in much more common cases. (It is my impression that implicitly >>> shared container such as QList/QVector are by far much more used than >>> the >>> one that are not within a typical Qt code base) >> >> There are two problems with Q_FOREACH: >> >> 1) it will copy containers. For Qt containers, that's rather cheap >> (two atomic >> refcount operations), but it's not free. And for Standard Library >> containers, >> that is likely very expensive. > > But using for(:) with a Qt container will cause a detach in the most > common case, so I'd say is even worse. > Which is why i'm saying using this reason is a bit ironic. > >> >> 2) it's implemented by way of a for loop inside a for loop, which is >> known to >> throw optimisers out, generating slightly worse code > > I would consider that the missed optimization is quite small, if not > negligible. > And it can be solved in C++17: > https://codereview.qt-project.org/243984/ > >> Our rule already was: Don't use foreach in Qt code. (it was fine in >> examples) >> >> Using iterators and now using the ranged for may need more typing, but >> produces optimal code. >> >>> What could be done is to only deprecate partial specialization of >>> qMakeForeachContainer for QVarLenghtArray and the standard containers. >>> Or for containers that do not have a 'detach' function. >>> That way, users would get a warning for the problematic containers, but >>> would continue to work just fine with with the containers most Qt >>> developer >>> use. >> >> I disagree. The optimisation problem is not solved. > > I'm ok with discouraging Q_FOREACH, but deprecating such a function need > more thinking. > Deprecating means you will force user to port all their codebase away > from it, which is a huge work. If the rationale is just that they will > save a couple of atomic operations, i do not think it is worth it. > > Deprecating it only for non-shared container seems more logical, since > we then warn only when there is actually a problem. > > And for the Qt shared container case, using foreach is less typing, but > also less error prone. (do i have to use qAsConst? or make a copy? or > even return a const object which even lead to more problems) > From lars.knoll at qt.io Mon Oct 29 13:17:04 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 29 Oct 2018 12:17:04 +0000 Subject: [Development] Build system for Qt 6 Message-ID: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Hi all, As you will probably remember, there have been lively discussions around what kind of build tool to use for Qt 6 both during Qt Contributor Summits as well as on this mailing list. There has been a strong consent that we should move away from qmake as our build tool for Qt due to many shortcomings and the burden we have maintaining the system. Thiago wrote a set of relatively strict requirements for such a build tool in his mail in July. While some of the requirements had a bit of a Linux specific background, they have been a good basis. There have been rather lively discussions around alternatives, but most focused around two possible choices for us: Qbs and cmake. Qbs is something that has been developed almost exclusively by The Qt Company. As such, TQtC had to also look at it from a business perspective and how it fits into the larger picture of making Qt successful. To make a long story short, while Qbs is pretty cool and interesting technology, it doesn’t really help us expand the Qt ecosystem and usage. To make Qbs really successful would require a rather large effort and investment in promoting it towards the larger C++ ecosystem as a new build tool. At the same time it has to be an open source product to stand any chance in the market. Together this makes it challenging for TQtC to see how to recover that investment. Thus this investment would be at the expense of other things we’d like to do, like improving our IDE, working on rearchitecting and cleaning up our core frameworks for Qt 6 or the design tooling we are currently investing into. The Qt Company believes that those other investments are more important for the future of Qt than our choice of build tool. As such, we were left with the question on whether we need Qbs as the build system for Qt 6 or whether cmake (as the other alternative) would be up to the task. Given that background, we’ve done some more research on using both Qbs and cmake to build Qt. Both projects did give us good results but we were actually surprised on how far we got with cmake in a rather limited period of time. In addition, cmake has the advantage of being very widely used in the C++ ecosystem (amongst many others by KDE), has a very wide support in many IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of knowledge about the build system available in the ecosystem. Using it with Qt 6 would also mean that we can focus our support on two build systems for our users (qmake and cmake) and we would not have to add a third one to the mix. Given that we are confident we can build Qt 6 with cmake, I believe that it makes most sense to follow down that route. In case you’re interested, you can have a look at the cmake prototype code for qtbase on Gerrit in the wip/cmake branch. Please also let us know if you’re interested in helping with the effort of porting Qt’s build system over to cmake. We have been developing Qbs over the last years, and as such are committed to it for some more time. We are planning on another feature release in the first quarter of next year and will support it in Qt Creator for at least another year. Qbs is open source and if someone wants to take over and develop it further let us know as well. I’d also like to use this place to thank Christian and Jörg for all their great work on Qbs (and of course also anybody else who contributed to it). Cheers, Lars From Tobias.Hunger at qt.io Mon Oct 29 13:31:34 2018 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Mon, 29 Oct 2018 12:31:34 +0000 Subject: [Development] wip/cmake status information Message-ID: Hi! Some technical details on the wip/cmake branch in Gerrit. You can also find this information in cmake/README.md there. # Status Initial port is on-going. Some modules of QtBase are ported, incl. some of the platform modules. Most are missing still. Basic functionality is there (moc, uic, etc.), but documentation, translations, qdbusxml2cpp, etc. are missing. # Intro The CMake update offers an opportunity to revisit some topics that came up during the last few years. * The Qt build system does not support building host tools during a cross-compilation run. You need to build a Qt for your host machine first and then use the platform tools from that version. The decision to do this was reached independent of cmake: This does save resources on build machines as the host tools will only get built once. * 3rd-party dependencies are no longer built as part of Qt. zlib, libpng, etc. from src/3rdparty need to be supplied from the outside to the build now. You may find apt-get/brew/etc. useful for this. Otherwise you may consider using vcpkg as in the next section. The decision to remove 3rd party dependencies from Qt repositories was reached independent of the decision to use cmake, we just use the opportunity to implement this decision. * There is less need for bootstrapping. Only moc and rcc (plus the lesser known tracegen and qfloat16-tables) are linking against the bootstrap Qt library. Everything else can link against the full QtCore. This will include qmake, which is currently missing from a cmake build. This will change: Qmake is supported as a build system for applications *using* Qt going forward and will not go away anytime soon. * For the time being we try to keep qmake working so that we do not interfere too much with ongoing development. # Building against VCPKG You may use vcpkg to install dependencies needed to build QtBase.   * ```git clone -b qt https://github.com/tronical/vcpkg```   * Run ```bootstrap-vcpkg.bat``` or ```bootstrap-vcpkg.sh```   * Set the ``VCPKG_DEFAULT_TRIPLET`` environment variable to     * Linux: ``x64-linux``     * Windows: ``qt-x86-windows-static``   * Build Qt dependencies:  ``vcpkg install zlib pcre2 double-conversion harfbuzz``   * When running cmake in qtbase, pass ``-DCMAKE_PREFIX_PATH=/path/to/your/vcpkg/installed/$VCPKG_DEFAULT_TRIPLET`` or ``-DCMAKE_PREFIX_PATH=/path/to/your/vcpkg/installed/%VCPKG_DEFAULT_TRIPLET%`` on Windows. # Building The basic way of building with cmake is as follows: ```     cd {build directory}     cmake {path to source directory}     cmake --build . ``` ``cmake --build`` is just a simple wrapper around the basic build tool that CMake generated a build system for. It works with any supported build backend supported by cmake, but you can also use the backend build tool directly, e.g. by running ``make`` in this case. CMake has a ninja backend that works quite well and is noticeably faster than make, so you may want to use that: ```     cd {build directory}     cmake -GNinja {path to source directory}     cmake --build . # ... or ninja ;-) ``` You can look into the generated ``build.ninja`` file if you're curious and you can also build targets directory such as ``ninja lib/libQt5Core.so``. When you're done with the build, you may want to install it, using ``ninja install`` or ``make install``. The installation prefix is chosen when running cmake though: ```     cd {build directory}     cmake -GNinja -DCMAKE_INSTALL_PREFIX=/path/where/to/install {path to source directory}     ninja     ninja install ``` You can use ``cmake-gui {path to build directory}`` or ``ccmake {path to build directory}`` to configure the values of individual cmake variables or Qt features. After changing a value, you need to choose the *configure* step (usually several times:-/), followed by the *generate* step (to generate makefiles/ninja files). # Debugging CMake files CMake allows specifying the ``--trace`` and ``--trace-expand`` options, which work like ``qmake -d -d``: As the cmake code is evaluated, the values of parameters and variables is shown. This can be a lot of output, so you may want to redirect it to a file. # Porting Help We have some python scripts to help with the conversion from qmake to cmake. These scripts can be found in ``utils/cmake``. ## configurejson2cmake.py This script converts all ``configure.json`` in the Qt repository to ``configure.cmake`` files for use with CMake. We want to generate configure.cmake files for the foreseeable future, so if you need to tweak the generated configure.cmake files, please tweak the generation script instead. ``configurejson2cmake.py`` is run like this: ``util/cmake/configurejson2cmake.py .`` in the top-level source directory of a Qt repository. ## pro2cmake.py ``pro2cmake.py`` generates a skeleton CMakeLists.txt file from a .pro-file. You will need to polish the resulting CMakeLists.txt file, but e.g. the list of files, etc. should be extracted for you. ``pro2cmake.py`` is run like this: ``/path/to/pro2cmake.py some.pro``. ## run_pro2cmake.py `` A small helper script to run pro2cmake.py on all .pro-files in a directory. Very useful to e.g. convert all the unit tests for a Qt module over to cmake;-) ``run_pro2cmake.py`` is run like this: ``/path/to/run_pro2cmake.py some_dir``. ## How to convert certain constructs | qmake                 | CMake                   | | ------                | ------                  | | ``qtHaveModule(foo)`` | ``if(TARGET Qt::foo)``  | | ``qtConfig(foo)``     | ``if (QT_FEATURE_foo)`` | From Frederik.Gladhorn at qt.io Mon Oct 29 14:22:11 2018 From: Frederik.Gladhorn at qt.io (Frederik Gladhorn) Date: Mon, 29 Oct 2018 13:22:11 +0000 Subject: [Development] wip/cmake status information In-Reply-To: References: Message-ID: <1747287.tBDr3HcQjm@frederik-thinkcentre-m93p> I just changed it into a review request, so everyone can have a look in gerrit: https://codereview.qt-project.org/#/c/244005/ Cheers, Frederik From Frederik.Gladhorn at qt.io Mon Oct 29 14:22:14 2018 From: Frederik.Gladhorn at qt.io (Frederik Gladhorn) Date: Mon, 29 Oct 2018 13:22:14 +0000 Subject: [Development] wip/cmake status information In-Reply-To: References: Message-ID: <102727537.xYxl5FNFQW@frederik-thinkcentre-m93p> I just changed it into a review request, so everyone can have a look in gerrit: https://codereview.qt-project.org/#/c/244005/ Cheers, Frederik From olivier at woboq.com Mon Oct 29 14:53:20 2018 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 29 Oct 2018 14:53:20 +0100 Subject: [Development] Undeprecating Q_FOREACH In-Reply-To: References: <8787b14f-4a62-7c3d-1044-7dc73cab382b@kdab.com> <4b21d498-c513-53e7-5c20-2e8c88aeb0db@kdab.com> <34556951-f628-6499-ee3d-3b05b69570d6@woboq.com> Message-ID: <899a7952-8ee6-ce33-d840-61104ebf969b@woboq.com> I'm just replying to this email to sumarize my opinion from the other email in the "qMoveToConst helper for rvalue references to movable Qt containers?" thread. I do not think it is time to deprecate foreach. Currently, the documentation says it is discouraged, and that's fine. But the alternative are harder to use with Qt containers and I do not think it is wise to tell everybody to port away from foreach. One problem of foreach is that it does not work well with QVerLenghtArray and standard containers. But in practice, Qt user are not using them so much. But I guess it would be fine to deprecate and warn for this case: https://codereview.qt-project.org/244010 The other problems seems really minors, and not a reason to port away from it, especially when the alternative is much more difficult to use right. On 10/28/18 7:34 PM, Giuseppe D'Angelo via Development wrote: [...] > Why should the Qt Project invest any resource whatsoever maintaining a solution > to a problem that has also been solved by the C++ language (and in a more > efficient and general way than Q_FOREACH)? Historical reason, and for the same reason the Qt project maintains its own containers. I guess it would be good to discourage uses of QVector/QMap/QSet/... But we can't just force everybody to move away from it just like that. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From jhihn at gmx.com Mon Oct 29 15:10:51 2018 From: jhihn at gmx.com (Jason H) Date: Mon, 29 Oct 2018 15:10:51 +0100 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <1613934.u2FelxWX76@tjmaciei-mobl1> Message-ID: Lydia, First, let me say I've stated my support of the KDE CoC. Thank you for your effort in it. But then you make a statement in your post script that demonstrates exactly what I'm talking about. You stated "some emails in this thread sadly make me see part of the project in a different light. I fear I'm not the only one."? Would you say the project has created fear in you and this has somehow "harmed" the project in some way? Who were these people that changed your mind? We need to identify these people and ban them because they are not casting the widest inclusive and protective audience and anything less than that is harm... Let the witch hunt begin... right? Everyone, This is the slippery slope that I'm talking about accusations start in wide-abstractions like your statement and devolve into direct accusations. While no one yet here has the motivation to conduct a witch hunt, we cannot assume that will be the case. So far common sense has prevailed, but common sense is, well, uncommon. It may be that Cone day oraline et. al. go on a witch hunt for those the opposed her Covenant. I've spent some time thinking about this this weekend. Here's what I don't get. Coraline authored the CC. She then goes into projects attacking them with it, but fortunately(?) it hasn't worked. But to put it a different way, if I design an instrument, publish the plans, and try to use it in a community, if it doesn't work, is it the instrument or the user that is at fault? If that instrument is intended to be destructive (say like a bomb), then can we see how she really means for this to be used? To my knowledge none of the people singled out in the witch hunts actually did anything offensive in the projects they were participating in. It could be that eventually those who opposed the CoC in some way get labeled as "intolerant" by the larger community. Lydia's statement has already given me pause in this regard and I'm not being hyperbolic. Political views, and things we don't consider as political today, can eventually become political. I think we have two camps: We want a CoC as a feel-good statement of inclusion and tolerance (I think everyone is committed to this) AND 1) We want to use existing situation of laws/self-policing OR 2) We want a CoC that contains a framework that can get people banned or more I've always assumed that there was some line that could be crossed that would get your accounts shut down and removed from the community. If someone makes it so that the community cannot function, in whole or in part, then removal is warranted. These Codes of Conducts lower the barrier to an incredibly low bar and don't say what lower threshold of "harm" is needed to run afoul. I haven't even had a response as to if it is perceived or demonstrable harm that is required. So far cooler heads and common sense have prevailed, but I don't trust that will always be the case. This is why if we go with a CoC that can prescribe punishments, that it be explicit both in determination and punishment stages. *Not that I have anything against witches. I have several wiccan friends. Is the term "witch hunt" offensive? Can I get banned for using that term now or in the future? > Sent: Sunday, October 28, 2018 at 7:53 PM > From: "Lydia Pintscher" > To: development at qt-project.org > Subject: Re: [Development] QUIP 12: Code of Conduct > > On Sun, Oct 28, 2018 at 10:45 PM Thiago Macieira > wrote: > > And I'm pretty sure the KDE Community WG can easily compile a list of times > > that they were maliciously asked to look into situations and how much time it > > took them to give it the attention it was due. > > I don't have an exact number but less than 10. And we could always > deal with it very quickly thanks to some common sense and good > knowledge of the situation and people involved. No big deal. > > (For those who don't know me: I'm one of the people who wrote KDE's > CoC and has been a member of it's community working group since then. > I'm also the current president of the non-profit behind KDE.) > If you have further questions about KDE's Code of Conduct please let > me know. I'm happy to answer them. > > > Cheers > Lydia > > PS: As someone on the fringes of the Qt Project some emails in this > thread sadly make me see part of the project in a different light. I > fear I'm not the only one. > > -- > Lydia Pintscher - http://about.me/lydia.pintscher > KDE e.V. Board of Directors > http://kde.org - http://open-advice.org > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From ulf.hermann at qt.io Mon Oct 29 15:25:20 2018 From: ulf.hermann at qt.io (Ulf Hermann) Date: Mon, 29 Oct 2018 14:25:20 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <1613934.u2FelxWX76@tjmaciei-mobl1> Message-ID: <9043feb7-dc9a-bbdc-d52f-19add7492825@qt.io> > But then you make a statement in your post script that demonstrates > exactly what I'm talking about. You stated "some emails in this > thread sadly make me see part of the project in a different light. I > fear I'm not the only one."? Would you say the project has created > fear in you and this has somehow "harmed" the project in some way? > Who were these people that changed your mind? We need to identify > these people and ban them because they are not casting the widest > inclusive and protective audience and anything less than that is > harm... Let the witch hunt begin... right? All the proposals for codes of conduct that I have seen so far mention banning only as a last resort and have several less drastic measures that should be applied before. Also, the point of having a neutral third party decide on the issue, rather than people directly involved in the conflict should result in that third party deciding on the measurements to be taken, not any victims of harassment, harm, or whatever. Ulf From volker.hilsheimer at qt.io Mon Oct 29 16:33:16 2018 From: volker.hilsheimer at qt.io (Volker Hilsheimer) Date: Mon, 29 Oct 2018 15:33:16 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <1613934.u2FelxWX76@tjmaciei-mobl1> Message-ID: <484EC37F-746E-45FA-AF45-8C7D7D2E4536@qt.io> Hey Jason, You seem to assume that without a code of conduct there is no way that people can get banned. That is not the case. In practice, people can be kicked out of the Qt Project by the folks that control the respective systems. And by extension by those who have some influence over those people. You call that “self-policing”, but in fact it’s about us trusting that the folks that have those privileges do not abuse their power. That’s great as long as it works, but if the project somehow does become “more political”, then I do think this lack of transparency is not in the interest of the project. A CoC tries to formulate what environment we want our behaviors to create, and it establishes a less opaque process for managing situations where an individual seems to do more harm than good to the project. That doesn’t mean that there won’t be mistakes. It doesn’t take much to cause someone distress through an email or a quick comment to their code, esp when we want to include people that are regularly exposed to all sorts of harassment, and are not quite as thick-skinned and self-assured as you and I might be. But I think that, by simply establishing a CoC that community members agree to, we can create an atmosphere where even a rough piece of language is received in the spirit of collaboration. And that also doens’t mean that there won’t be abuse. I’m sure there are people that have made it a way of life to be offended. However, they do not need a Code of Conduct (which is not a legal document anyway). I’d rather have them raise their voice in the open, and direct them towards a transparent process, than to have them use backdoor tactics to get influence over the project. The question to you is then: If someone like Coraline were to direct her energy to the Qt Project, how much in the open would you want their efforts to be? Or would you rather simply trust that there are not enough maintainers in the Qt project that would fall for their chain of arguments and backdoor schemings? Volker > On 29 Oct 2018, at 15:10, Jason H wrote: > > Lydia, > > First, let me say I've stated my support of the KDE CoC. Thank you for your effort in it. > > But then you make a statement in your post script that demonstrates exactly what I'm talking about. You stated "some emails in this thread sadly make me see part of the project in a different light. I fear I'm not the only one."? Would you say the project has created fear in you and this has somehow "harmed" the project in some way? Who were these people that changed your mind? We need to identify these people and ban them because they are not casting the widest inclusive and protective audience and anything less than that is harm... Let the witch hunt begin... right? > > Everyone, > This is the slippery slope that I'm talking about accusations start in wide-abstractions like your statement and devolve into direct accusations. While no one yet here has the motivation to conduct a witch hunt, we cannot assume that will be the case. So far common sense has prevailed, but common sense is, well, uncommon. It may be that Cone day oraline et. al. go on a witch hunt for those the opposed her Covenant. > > I've spent some time thinking about this this weekend. Here's what I don't get. Coraline authored the CC. She then goes into projects attacking them with it, but fortunately(?) it hasn't worked. But to put it a different way, if I design an instrument, publish the plans, and try to use it in a community, if it doesn't work, is it the instrument or the user that is at fault? If that instrument is intended to be destructive (say like a bomb), then can we see how she really means for this to be used? To my knowledge none of the people singled out in the witch hunts actually did anything offensive in the projects they were participating in. > > It could be that eventually those who opposed the CoC in some way get labeled as "intolerant" by the larger community. Lydia's statement has already given me pause in this regard and I'm not being hyperbolic. Political views, and things we don't consider as political today, can eventually become political. > > I think we have two camps: > We want a CoC as a feel-good statement of inclusion and tolerance (I think everyone is committed to this) > AND > 1) We want to use existing situation of laws/self-policing OR > 2) We want a CoC that contains a framework that can get people banned or more > > I've always assumed that there was some line that could be crossed that would get your accounts shut down and removed from the community. If someone makes it so that the community cannot function, in whole or in part, then removal is warranted. These Codes of Conducts lower the barrier to an incredibly low bar and don't say what lower threshold of "harm" is needed to run afoul. I haven't even had a response as to if it is perceived or demonstrable harm that is required. > > So far cooler heads and common sense have prevailed, but I don't trust that will always be the case. This is why if we go with a CoC that can prescribe punishments, that it be explicit both in determination and punishment stages. > > > *Not that I have anything against witches. I have several wiccan friends. Is the term "witch hunt" offensive? Can I get banned for using that term now or in the future? > > >> Sent: Sunday, October 28, 2018 at 7:53 PM >> From: "Lydia Pintscher" >> To: development at qt-project.org >> Subject: Re: [Development] QUIP 12: Code of Conduct >> >> On Sun, Oct 28, 2018 at 10:45 PM Thiago Macieira >> wrote: >>> And I'm pretty sure the KDE Community WG can easily compile a list of times >>> that they were maliciously asked to look into situations and how much time it >>> took them to give it the attention it was due. >> >> I don't have an exact number but less than 10. And we could always >> deal with it very quickly thanks to some common sense and good >> knowledge of the situation and people involved. No big deal. >> >> (For those who don't know me: I'm one of the people who wrote KDE's >> CoC and has been a member of it's community working group since then. >> I'm also the current president of the non-profit behind KDE.) >> If you have further questions about KDE's Code of Conduct please let >> me know. I'm happy to answer them. >> >> >> Cheers >> Lydia >> >> PS: As someone on the fringes of the Qt Project some emails in this >> thread sadly make me see part of the project in a different light. I >> fear I'm not the only one. >> >> -- >> Lydia Pintscher - http://about.me/lydia.pintscher >> KDE e.V. Board of Directors >> http://kde.org - http://open-advice.org >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Robert.Loehning at qt.io Mon Oct 29 16:39:06 2018 From: Robert.Loehning at qt.io (Robert Loehning) Date: Mon, 29 Oct 2018 15:39:06 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2157984.flhv5agb7N@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <4145998.dxsAPVRcBo@tjmaciei-mobl1> <2157984.flhv5agb7N@tjmaciei-mobl1> Message-ID: Am 26.10.2018 um 18:11 schrieb Thiago Macieira: > On Friday, 26 October 2018 01:12:35 PDT Andy Nichols wrote: >> The details of this are tricky though because it depends a lot on trust >> (similarly the security list). Much of the concern with this proposal has >> to do with the potential for abuse, and rightly so. I'm not super happy >> with the idea of a Conduct Cabal who has to the power to banish people from >> the community either. > > One idea I've seen recently is to populate the panel members at random, on a > need basis, much like jury duty. I don't know of project adopting this > solution and whether they've been successful at it. Would be nice to research. > I'm not aware of software projects using such, but the concept of giving power to random people seems to have been used for more than 2000 years: https://en.wikipedia.org/wiki/Sortition Cheers, Robert From thiago.macieira at intel.com Mon Oct 29 16:40:29 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Oct 2018 08:40:29 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <57137783.Y9GKUMOgDo@tjmaciei-mobl1> Message-ID: <2505797.krPY0VdK3e@tjmaciei-mobl1> On Monday, 29 October 2018 00:52:49 PDT Alexey Andreyev wrote: > Talking about CC and KDE's CoC, it's not obvious for me how to perform > politics, religion, race, etc -- harassment protection correctly at > international digital community with provided rules. > I'm not saying we don't need rules. You said KDE's version looks better > comparing to CC. Archlinux version looks even better for me. > > Anyway, I'm not a professional at such social tasks and want to step back. > I do not want to look like annoying person, just wanted to help with > controversial subjects. > I have no doubts about Qt people professionalism and happy do be a part of > the community. For me, the fact that it doesn't say we'll try to address those problems that are currently extant in many communities (though, hopefully, not ours), ArchLinux's CoC is inferior to KDE's. I'd like a text that says states the goals we'll strive for, not just what we can be sure of. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lydia at kde.org Mon Oct 29 16:48:53 2018 From: lydia at kde.org (Lydia Pintscher) Date: Mon, 29 Oct 2018 16:48:53 +0100 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2635333.mRs2FyqhBL@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <1613934.u2FelxWX76@tjmaciei-mobl1> <2635333.mRs2FyqhBL@tjmaciei-mobl1> Message-ID: On Mon, Oct 29, 2018 at 4:53 AM Thiago Macieira wrote: > Hi Lydia > > Thanks for chiming in. > > Note I asked about malicious request to the CWG, not legitimate ones. I mean > baseless accusations, based on no actual fact, just attempts to smear someone > or generate useless expediture of people's time. Has that happened, at all? If > so, how long did the committee spend addressing it? How much effort was put > into it? Maybe 2 or 3 times by people not part of the broadly construed core community on forums like reddit etc. Nothing that I'm aware of ever ended up in any official channel or took any noteworthy amount of time from anyone. > Maybe we can also expand to accusations that, though not malicious, were found > not to be under the CoC's purview, like asking someone to be removed due to > some action on their personal time. Asking? Maybe 1 or 2 times. (Sorry for not being super specific. There might be things I'm simply forgetting since it's been 10 years and there might be things that were not brought up to the whole committee but simply mentioned in a chat with one member of the group to get some input and guidance about how to handle a situation that was not further escalated because the problem was solved with that.) Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher KDE e.V. Board of Directors http://kde.org - http://open-advice.org From thiago.macieira at intel.com Mon Oct 29 16:56:12 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Oct 2018 08:56:12 -0700 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: <2935486.kRNsAma0Ab@tjmaciei-mobl1> Message-ID: <3275016.bOrGJx8hF2@tjmaciei-mobl1> On Monday, 29 October 2018 04:43:09 PDT Olivier Goffart wrote: > > 1) it will copy containers. For Qt containers, that's rather cheap (two > > atomic refcount operations), but it's not free. And for Standard Library > > containers, that is likely very expensive. > > But using for(:) with a Qt container will cause a detach in the most common > case, so I'd say is even worse. > Which is why i'm saying using this reason is a bit ironic. True, which is why we didn't deprecate, but did add qAsConst. > > 2) it's implemented by way of a for loop inside a for loop, which is known > > to throw optimisers out, generating slightly worse code > > I would consider that the missed optimization is quite small, if not > negligible. And it can be solved in C++17: > https://codereview.qt-project.org/243984/ I'd solve this the other way around, by making the macro: if (const auto &_container_ = (container); true) \ for (variable : _container_) This creates a scope-only const reference to the original container and then uses the ranged for on it. We should be able to depend on this for Qt 6.4 or something. > > I disagree. The optimisation problem is not solved. > > I'm ok with discouraging Q_FOREACH, but deprecating such a function need > more thinking. I'm with you. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lydia at kde.org Mon Oct 29 16:57:43 2018 From: lydia at kde.org (Lydia Pintscher) Date: Mon, 29 Oct 2018 16:57:43 +0100 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <1613934.u2FelxWX76@tjmaciei-mobl1> Message-ID: On Mon, Oct 29, 2018 at 3:11 PM Jason H wrote: > Lydia, > > First, let me say I've stated my support of the KDE CoC. Thank you for your effort in it. > > But then you make a statement in your post script that demonstrates exactly what I'm talking about. You stated "some emails in this thread sadly make me see part of the project in a different light. I fear I'm not the only one."? Would you say the project has created fear in you and this has somehow "harmed" the project in some way? Who were these people that changed your mind? We need to identify these people and ban them because they are not casting the widest inclusive and protective audience and anything less than that is harm... Let the witch hunt begin... right? Sorry. I seem to have been misunderstood here. As others have said at the core a Code of Conduct should not be about banning anyone. That's a measure of very last resort. A lot of work should be put in before that happens. Talking, making aware of an issue, mediation, bringing in a neutral third party, separating the parties and a lot of other things are possible before that to address a problem. A Code of Conduct should be as much about stating what a community wants to be as about what it doesn't want. I think about it as a statement of intent that broadcasts values to the rest of the world and gets shared understanding in a community. Some communities then decide to add rules and punishments for violations. Other decide to hand that over to a committee or something similar. There are pros and cons to either. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher KDE e.V. Board of Directors http://kde.org - http://open-advice.org From thiago.macieira at intel.com Mon Oct 29 16:58:10 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Oct 2018 08:58:10 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <2635333.mRs2FyqhBL@tjmaciei-mobl1> Message-ID: <7737445.fd0HTJd11T@tjmaciei-mobl1> On Monday, 29 October 2018 08:48:53 PDT Lydia Pintscher wrote: > Asking? Maybe 1 or 2 times. (Sorry for not being super specific. There > might be things I'm simply forgetting since it's been 10 years and > there might be things that were not brought up to the whole committee > but simply mentioned in a chat with one member of the group to get > some input and guidance about how to handle a situation that was not > further escalated because the problem was solved with that.) Thank you, Lydia. That's heartening. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From olivier at woboq.com Mon Oct 29 17:05:37 2018 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 29 Oct 2018 17:05:37 +0100 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <3275016.bOrGJx8hF2@tjmaciei-mobl1> References: <2935486.kRNsAma0Ab@tjmaciei-mobl1> <3275016.bOrGJx8hF2@tjmaciei-mobl1> Message-ID: <6e159a45-3d0f-20a1-985d-74a228acd79e@woboq.com> On 10/29/18 4:56 PM, Thiago Macieira wrote: >>> 2) it's implemented by way of a for loop inside a for loop, which is known >>> to throw optimisers out, generating slightly worse code >> >> I would consider that the missed optimization is quite small, if not >> negligible. And it can be solved in C++17: >> https://codereview.qt-project.org/243984/ > > I'd solve this the other way around, by making the macro: > > if (const auto &_container_ = (container); true) \ > for (variable : _container_) > > This creates a scope-only const reference to the original container and then > uses the ranged for on it. That does not work, because foreach need to support a variable which is already declare: "QString str; foreach (str, list)" (see the documentation http://doc.qt.io/qt-5/containers.html#foreach ), and this construct is not allowed in a ranged-based for. Othewise, we could have that in C++11: for (variable : qMakeForeachContainer(container)) > We should be able to depend on this for Qt 6.4 or something. I tought Qt6 would probably require C++17. But even if one does not, it's completely optional. From sergio.martins at kdab.com Mon Oct 29 17:05:44 2018 From: sergio.martins at kdab.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Mon, 29 Oct 2018 16:05:44 +0000 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <3275016.bOrGJx8hF2@tjmaciei-mobl1> References: <2935486.kRNsAma0Ab@tjmaciei-mobl1> <3275016.bOrGJx8hF2@tjmaciei-mobl1> Message-ID: <6d2ee8c41cc99402ab4566b64f44f35f@kdab.com> On 2018-10-29 15:56, Thiago Macieira wrote: > On Monday, 29 October 2018 04:43:09 PDT Olivier Goffart wrote: >> > 1) it will copy containers. For Qt containers, that's rather cheap (two >> > atomic refcount operations), but it's not free. And for Standard Library >> > containers, that is likely very expensive. >> >> But using for(:) with a Qt container will cause a detach in the most >> common >> case, so I'd say is even worse. >> Which is why i'm saying using this reason is a bit ironic. > > True, which is why we didn't deprecate, but did add qAsConst. > >> > 2) it's implemented by way of a for loop inside a for loop, which is known >> > to throw optimisers out, generating slightly worse code >> >> I would consider that the missed optimization is quite small, if not >> negligible. And it can be solved in C++17: >> https://codereview.qt-project.org/243984/ > > I'd solve this the other way around, by making the macro: > > if (const auto &_container_ = (container); true) \ > for (variable : _container_) That's not behaviour-compatible and will introduce bugs where users rely on iterating over a copy. Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From yetanotherandreyev at gmail.com Mon Oct 29 17:22:42 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Mon, 29 Oct 2018 19:22:42 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <1613934.u2FelxWX76@tjmaciei-mobl1> Message-ID: > I think we have two camps: > We want a CoC as a feel-good statement of inclusion and tolerance (I think everyone is > committed to this) > AND > 1) We want to use existing situation of laws/self-policing OR > 2) We want a CoC that contains a framework that can get people banned or more Hello, Jason! What do you say about Archlinux CoC? [1] For me it's probably an option to explicitly say at new CoC that "witch hunt" questions from your terminology is not a task for a technical project itself. See part 2.3.3 among others. [1]: https://wiki.archlinux.org/index.php/Code_of_conduct пн, 29 окт. 2018 г. в 17:11, Jason H : > Lydia, > > First, let me say I've stated my support of the KDE CoC. Thank you for > your effort in it. > > But then you make a statement in your post script that demonstrates > exactly what I'm talking about. You stated "some emails in this thread > sadly make me see part of the project in a different light. I fear I'm not > the only one."? Would you say the project has created fear in you and this > has somehow "harmed" the project in some way? Who were these people that > changed your mind? We need to identify these people and ban them because > they are not casting the widest inclusive and protective audience and > anything less than that is harm... Let the witch hunt begin... right? > > Everyone, > This is the slippery slope that I'm talking about accusations start in > wide-abstractions like your statement and devolve into direct accusations. > While no one yet here has the motivation to conduct a witch hunt, we cannot > assume that will be the case. So far common sense has prevailed, but common > sense is, well, uncommon. It may be that Cone day oraline et. al. go on a > witch hunt for those the opposed her Covenant. > > I've spent some time thinking about this this weekend. Here's what I don't > get. Coraline authored the CC. She then goes into projects attacking them > with it, but fortunately(?) it hasn't worked. But to put it a different > way, if I design an instrument, publish the plans, and try to use it in a > community, if it doesn't work, is it the instrument or the user that is at > fault? If that instrument is intended to be destructive (say like a bomb), > then can we see how she really means for this to be used? To my knowledge > none of the people singled out in the witch hunts actually did anything > offensive in the projects they were participating in. > > It could be that eventually those who opposed the CoC in some way get > labeled as "intolerant" by the larger community. Lydia's statement has > already given me pause in this regard and I'm not being hyperbolic. > Political views, and things we don't consider as political today, can > eventually become political. > > I think we have two camps: > We want a CoC as a feel-good statement of inclusion and tolerance (I think > everyone is committed to this) > AND > 1) We want to use existing situation of laws/self-policing OR > 2) We want a CoC that contains a framework that can get people banned or > more > > I've always assumed that there was some line that could be crossed that > would get your accounts shut down and removed from the community. If > someone makes it so that the community cannot function, in whole or in > part, then removal is warranted. These Codes of Conducts lower the barrier > to an incredibly low bar and don't say what lower threshold of "harm" is > needed to run afoul. I haven't even had a response as to if it is perceived > or demonstrable harm that is required. > > So far cooler heads and common sense have prevailed, but I don't trust > that will always be the case. This is why if we go with a CoC that can > prescribe punishments, that it be explicit both in determination and > punishment stages. > > > *Not that I have anything against witches. I have several wiccan friends. > Is the term "witch hunt" offensive? Can I get banned for using that term > now or in the future? > > > > Sent: Sunday, October 28, 2018 at 7:53 PM > > From: "Lydia Pintscher" > > To: development at qt-project.org > > Subject: Re: [Development] QUIP 12: Code of Conduct > > > > On Sun, Oct 28, 2018 at 10:45 PM Thiago Macieira > > wrote: > > > And I'm pretty sure the KDE Community WG can easily compile a list of > times > > > that they were maliciously asked to look into situations and how much > time it > > > took them to give it the attention it was due. > > > > I don't have an exact number but less than 10. And we could always > > deal with it very quickly thanks to some common sense and good > > knowledge of the situation and people involved. No big deal. > > > > (For those who don't know me: I'm one of the people who wrote KDE's > > CoC and has been a member of it's community working group since then. > > I'm also the current president of the non-profit behind KDE.) > > If you have further questions about KDE's Code of Conduct please let > > me know. I'm happy to answer them. > > > > > > Cheers > > Lydia > > > > PS: As someone on the fringes of the Qt Project some emails in this > > thread sadly make me see part of the project in a different light. I > > fear I'm not the only one. > > > > -- > > Lydia Pintscher - http://about.me/lydia.pintscher > > KDE e.V. Board of Directors > > http://kde.org - http://open-advice.org > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.jabot at gmail.com Mon Oct 29 17:24:17 2018 From: corentin.jabot at gmail.com (Corentin) Date: Mon, 29 Oct 2018 17:24:17 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: Having had the pleasure to use QBS quite extensively (and successfully) in the past, I would like to thank the QBS team and contributors for showing us what a sane, modern build system could look like. So long! On Mon, 29 Oct 2018 at 13:17 Lars Knoll wrote: > Hi all, > > As you will probably remember, there have been lively discussions around > what kind of build tool to use for Qt 6 both during Qt Contributor Summits > as well as on this mailing list. > > There has been a strong consent that we should move away from qmake as our > build tool for Qt due to many shortcomings and the burden we have > maintaining the system. > > Thiago wrote a set of relatively strict requirements for such a build tool > in his mail in July. While some of the requirements had a bit of a Linux > specific background, they have been a good basis. > > There have been rather lively discussions around alternatives, but most > focused around two possible choices for us: Qbs and cmake. > > Qbs is something that has been developed almost exclusively by The Qt > Company. As such, TQtC had to also look at it from a business perspective > and how it fits into the larger picture of making Qt successful. To make a > long story short, while Qbs is pretty cool and interesting technology, it > doesn’t really help us expand the Qt ecosystem and usage. > > To make Qbs really successful would require a rather large effort and > investment in promoting it towards the larger C++ ecosystem as a new build > tool. At the same time it has to be an open source product to stand any > chance in the market. Together this makes it challenging for TQtC to see > how to recover that investment. Thus this investment would be at the > expense of other things we’d like to do, like improving our IDE, working on > rearchitecting and cleaning up our core frameworks for Qt 6 or the design > tooling we are currently investing into. The Qt Company believes that those > other investments are more important for the future of Qt than our choice > of build tool. > > As such, we were left with the question on whether we need Qbs as the > build system for Qt 6 or whether cmake (as the other alternative) would be > up to the task. > > Given that background, we’ve done some more research on using both Qbs and > cmake to build Qt. Both projects did give us good results but we were > actually surprised on how far we got with cmake in a rather limited period > of time. > > In addition, cmake has the advantage of being very widely used in the C++ > ecosystem (amongst many others by KDE), has a very wide support in many > IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of > knowledge about the build system available in the ecosystem. Using it with > Qt 6 would also mean that we can focus our support on two build systems for > our users (qmake and cmake) and we would not have to add a third one to the > mix. > > Given that we are confident we can build Qt 6 with cmake, I believe that > it makes most sense to follow down that route. In case you’re interested, > you can have a look at the cmake prototype code for qtbase on Gerrit in the > wip/cmake branch. Please also let us know if you’re interested in helping > with the effort of porting Qt’s build system over to cmake. > > We have been developing Qbs over the last years, and as such are committed > to it for some more time. We are planning on another feature release in the > first quarter of next year and will support it in Qt Creator for at least > another year. Qbs is open source and if someone wants to take over and > develop it further let us know as well. I’d also like to use this place to > thank Christian and Jörg for all their great work on Qbs (and of course > also anybody else who contributed to it). > > 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: From mingw.android at gmail.com Mon Oct 29 17:32:11 2018 From: mingw.android at gmail.com (Ray Donnelly) Date: Mon, 29 Oct 2018 16:32:11 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: Agreed, a brilliant bit of technology, such a shame to see it deprecated. On Mon, Oct 29, 2018 at 4:24 PM Corentin wrote: > > > Having had the pleasure to use QBS quite extensively (and successfully) in the past, I would like to thank the QBS team and contributors for showing us what a sane, modern build system could look like. > So long! > > On Mon, 29 Oct 2018 at 13:17 Lars Knoll wrote: >> >> Hi all, >> >> As you will probably remember, there have been lively discussions around what kind of build tool to use for Qt 6 both during Qt Contributor Summits as well as on this mailing list. >> >> There has been a strong consent that we should move away from qmake as our build tool for Qt due to many shortcomings and the burden we have maintaining the system. >> >> Thiago wrote a set of relatively strict requirements for such a build tool in his mail in July. While some of the requirements had a bit of a Linux specific background, they have been a good basis. >> >> There have been rather lively discussions around alternatives, but most focused around two possible choices for us: Qbs and cmake. >> >> Qbs is something that has been developed almost exclusively by The Qt Company. As such, TQtC had to also look at it from a business perspective and how it fits into the larger picture of making Qt successful. To make a long story short, while Qbs is pretty cool and interesting technology, it doesn’t really help us expand the Qt ecosystem and usage. >> >> To make Qbs really successful would require a rather large effort and investment in promoting it towards the larger C++ ecosystem as a new build tool. At the same time it has to be an open source product to stand any chance in the market. Together this makes it challenging for TQtC to see how to recover that investment. Thus this investment would be at the expense of other things we’d like to do, like improving our IDE, working on rearchitecting and cleaning up our core frameworks for Qt 6 or the design tooling we are currently investing into. The Qt Company believes that those other investments are more important for the future of Qt than our choice of build tool. >> >> As such, we were left with the question on whether we need Qbs as the build system for Qt 6 or whether cmake (as the other alternative) would be up to the task. >> >> Given that background, we’ve done some more research on using both Qbs and cmake to build Qt. Both projects did give us good results but we were actually surprised on how far we got with cmake in a rather limited period of time. >> >> In addition, cmake has the advantage of being very widely used in the C++ ecosystem (amongst many others by KDE), has a very wide support in many IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of knowledge about the build system available in the ecosystem. Using it with Qt 6 would also mean that we can focus our support on two build systems for our users (qmake and cmake) and we would not have to add a third one to the mix. >> >> Given that we are confident we can build Qt 6 with cmake, I believe that it makes most sense to follow down that route. In case you’re interested, you can have a look at the cmake prototype code for qtbase on Gerrit in the wip/cmake branch. Please also let us know if you’re interested in helping with the effort of porting Qt’s build system over to cmake. >> >> We have been developing Qbs over the last years, and as such are committed to it for some more time. We are planning on another feature release in the first quarter of next year and will support it in Qt Creator for at least another year. Qbs is open source and if someone wants to take over and develop it further let us know as well. I’d also like to use this place to thank Christian and Jörg for all their great work on Qbs (and of course also anybody else who contributed to it). >> >> Cheers, >> Lars >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From pierluigi.fiorini at gmail.com Mon Oct 29 17:36:07 2018 From: pierluigi.fiorini at gmail.com (Pier Luigi Fiorini) Date: Mon, 29 Oct 2018 17:36:07 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: I too feel like thanks are in order to the Qbs team. Hopefully CMake integration with QtCreator will quickly improve and include mobile platforms as well as embedded and desktop. Il giorno lun 29 ott 2018 alle ore 17:24 Corentin ha scritto: > > Having had the pleasure to use QBS quite extensively (and successfully) in > the past, I would like to thank the QBS team and contributors for showing > us what a sane, modern build system could look like. > So long! > > On Mon, 29 Oct 2018 at 13:17 Lars Knoll wrote: > >> Hi all, >> >> As you will probably remember, there have been lively discussions around >> what kind of build tool to use for Qt 6 both during Qt Contributor Summits >> as well as on this mailing list. >> >> There has been a strong consent that we should move away from qmake as >> our build tool for Qt due to many shortcomings and the burden we have >> maintaining the system. >> >> Thiago wrote a set of relatively strict requirements for such a build >> tool in his mail in July. While some of the requirements had a bit of a >> Linux specific background, they have been a good basis. >> >> There have been rather lively discussions around alternatives, but most >> focused around two possible choices for us: Qbs and cmake. >> >> Qbs is something that has been developed almost exclusively by The Qt >> Company. As such, TQtC had to also look at it from a business perspective >> and how it fits into the larger picture of making Qt successful. To make a >> long story short, while Qbs is pretty cool and interesting technology, it >> doesn’t really help us expand the Qt ecosystem and usage. >> >> To make Qbs really successful would require a rather large effort and >> investment in promoting it towards the larger C++ ecosystem as a new build >> tool. At the same time it has to be an open source product to stand any >> chance in the market. Together this makes it challenging for TQtC to see >> how to recover that investment. Thus this investment would be at the >> expense of other things we’d like to do, like improving our IDE, working on >> rearchitecting and cleaning up our core frameworks for Qt 6 or the design >> tooling we are currently investing into. The Qt Company believes that those >> other investments are more important for the future of Qt than our choice >> of build tool. >> >> As such, we were left with the question on whether we need Qbs as the >> build system for Qt 6 or whether cmake (as the other alternative) would be >> up to the task. >> >> Given that background, we’ve done some more research on using both Qbs >> and cmake to build Qt. Both projects did give us good results but we were >> actually surprised on how far we got with cmake in a rather limited period >> of time. >> >> In addition, cmake has the advantage of being very widely used in the C++ >> ecosystem (amongst many others by KDE), has a very wide support in many >> IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of >> knowledge about the build system available in the ecosystem. Using it with >> Qt 6 would also mean that we can focus our support on two build systems for >> our users (qmake and cmake) and we would not have to add a third one to the >> mix. >> >> Given that we are confident we can build Qt 6 with cmake, I believe that >> it makes most sense to follow down that route. In case you’re interested, >> you can have a look at the cmake prototype code for qtbase on Gerrit in the >> wip/cmake branch. Please also let us know if you’re interested in helping >> with the effort of porting Qt’s build system over to cmake. >> >> We have been developing Qbs over the last years, and as such are >> committed to it for some more time. We are planning on another feature >> release in the first quarter of next year and will support it in Qt Creator >> for at least another year. Qbs is open source and if someone wants to take >> over and develop it further let us know as well. I’d also like to use this >> place to thank Christian and Jörg for all their great work on Qbs (and of >> course also anybody else who contributed to it). >> >> Cheers, >> Lars >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- https://liri.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From abbapoh at gmail.com Mon Oct 29 17:36:53 2018 From: abbapoh at gmail.com (=?koi8-r?B?6dfBziDrz83J09PB0s/X?=) Date: Mon, 29 Oct 2018 17:36:53 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: RIP Qbs=( Иван Комиссаров > 29 окт. 2018 г., в 17:32, Ray Donnelly написал(а): > > Agreed, a brilliant bit of technology, such a shame to see it deprecated. >> On Mon, Oct 29, 2018 at 4:24 PM Corentin wrote: >> >> >> Having had the pleasure to use QBS quite extensively (and successfully) in the past, I would like to thank the QBS team and contributors for showing us what a sane, modern build system could look like. >> So long! >> >>> On Mon, 29 Oct 2018 at 13:17 Lars Knoll wrote: >>> >>> Hi all, >>> >>> As you will probably remember, there have been lively discussions around what kind of build tool to use for Qt 6 both during Qt Contributor Summits as well as on this mailing list. >>> >>> There has been a strong consent that we should move away from qmake as our build tool for Qt due to many shortcomings and the burden we have maintaining the system. >>> >>> Thiago wrote a set of relatively strict requirements for such a build tool in his mail in July. While some of the requirements had a bit of a Linux specific background, they have been a good basis. >>> >>> There have been rather lively discussions around alternatives, but most focused around two possible choices for us: Qbs and cmake. >>> >>> Qbs is something that has been developed almost exclusively by The Qt Company. As such, TQtC had to also look at it from a business perspective and how it fits into the larger picture of making Qt successful. To make a long story short, while Qbs is pretty cool and interesting technology, it doesn’t really help us expand the Qt ecosystem and usage. >>> >>> To make Qbs really successful would require a rather large effort and investment in promoting it towards the larger C++ ecosystem as a new build tool. At the same time it has to be an open source product to stand any chance in the market. Together this makes it challenging for TQtC to see how to recover that investment. Thus this investment would be at the expense of other things we’d like to do, like improving our IDE, working on rearchitecting and cleaning up our core frameworks for Qt 6 or the design tooling we are currently investing into. The Qt Company believes that those other investments are more important for the future of Qt than our choice of build tool. >>> >>> As such, we were left with the question on whether we need Qbs as the build system for Qt 6 or whether cmake (as the other alternative) would be up to the task. >>> >>> Given that background, we’ve done some more research on using both Qbs and cmake to build Qt. Both projects did give us good results but we were actually surprised on how far we got with cmake in a rather limited period of time. >>> >>> In addition, cmake has the advantage of being very widely used in the C++ ecosystem (amongst many others by KDE), has a very wide support in many IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of knowledge about the build system available in the ecosystem. Using it with Qt 6 would also mean that we can focus our support on two build systems for our users (qmake and cmake) and we would not have to add a third one to the mix. >>> >>> Given that we are confident we can build Qt 6 with cmake, I believe that it makes most sense to follow down that route. In case you’re interested, you can have a look at the cmake prototype code for qtbase on Gerrit in the wip/cmake branch. Please also let us know if you’re interested in helping with the effort of porting Qt’s build system over to cmake. >>> >>> We have been developing Qbs over the last years, and as such are committed to it for some more time. We are planning on another feature release in the first quarter of next year and will support it in Qt Creator for at least another year. Qbs is open source and if someone wants to take over and develop it further let us know as well. I’d also like to use this place to thank Christian and Jörg for all their great work on Qbs (and of course also anybody else who contributed to it). >>> >>> Cheers, >>> Lars >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Jedrzej.Nowacki at qt.io Mon Oct 29 17:39:16 2018 From: Jedrzej.Nowacki at qt.io (Jedrzej Nowacki) Date: Mon, 29 Oct 2018 16:39:16 +0000 Subject: [Development] Metatype system in Qt6 Message-ID: <2756315.1D9YIM6Clu@snoll> Hi everyone! While main heat on the mailing list is taken by topic how to encode that we are nice, friendly and respectful to each other, I would like to show some side project that I had. It is a proposal for base of metatype system for Qt6. You can look and comment at it here: https://github.com/nierob/qmetatype. It is quite fresh and it was rather a storage for functionality ideas. I haven't tried to compare performance of it to the current system, but for sure it has more flexibility and I believe, that conceptually it could serve us during Qt6. Anyway before spending too much time on it I would like to get some early feedback and questions. Cheers, Jędrek From bogdan.vatra at kdab.com Mon Oct 29 17:39:22 2018 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Mon, 29 Oct 2018 18:39:22 +0200 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: <5627437.H1gup227mp@dragon> Yup, it's a sad day for people who liked QBS. Personally I'll check GN, which has a nice syntax, not as nice as QBS but ... :) . În ziua de luni, 29 octombrie 2018, la 18:32:11 EET, Ray Donnelly a scris: > Agreed, a brilliant bit of technology, such a shame to see it deprecated. > > On Mon, Oct 29, 2018 at 4:24 PM Corentin wrote: > > Having had the pleasure to use QBS quite extensively (and successfully) in > > the past, I would like to thank the QBS team and contributors for showing > > us what a sane, modern build system could look like. So long! > > > > On Mon, 29 Oct 2018 at 13:17 Lars Knoll wrote: > >> Hi all, > >> > >> As you will probably remember, there have been lively discussions around > >> what kind of build tool to use for Qt 6 both during Qt Contributor > >> Summits as well as on this mailing list. > >> > >> There has been a strong consent that we should move away from qmake as > >> our build tool for Qt due to many shortcomings and the burden we have > >> maintaining the system. > >> > >> Thiago wrote a set of relatively strict requirements for such a build > >> tool in his mail in July. While some of the requirements had a bit of a > >> Linux specific background, they have been a good basis. > >> > >> There have been rather lively discussions around alternatives, but most > >> focused around two possible choices for us: Qbs and cmake. > >> > >> Qbs is something that has been developed almost exclusively by The Qt > >> Company. As such, TQtC had to also look at it from a business > >> perspective and how it fits into the larger picture of making Qt > >> successful. To make a long story short, while Qbs is pretty cool and > >> interesting technology, it doesn’t really help us expand the Qt > >> ecosystem and usage. > >> > >> To make Qbs really successful would require a rather large effort and > >> investment in promoting it towards the larger C++ ecosystem as a new > >> build tool. At the same time it has to be an open source product to > >> stand any chance in the market. Together this makes it challenging for > >> TQtC to see how to recover that investment. Thus this investment would > >> be at the expense of other things we’d like to do, like improving our > >> IDE, working on rearchitecting and cleaning up our core frameworks for > >> Qt 6 or the design tooling we are currently investing into. The Qt > >> Company believes that those other investments are more important for the > >> future of Qt than our choice of build tool. > >> > >> As such, we were left with the question on whether we need Qbs as the > >> build system for Qt 6 or whether cmake (as the other alternative) would > >> be up to the task. > >> > >> Given that background, we’ve done some more research on using both Qbs > >> and cmake to build Qt. Both projects did give us good results but we > >> were actually surprised on how far we got with cmake in a rather limited > >> period of time. > >> > >> In addition, cmake has the advantage of being very widely used in the C++ > >> ecosystem (amongst many others by KDE), has a very wide support in many > >> IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of > >> knowledge about the build system available in the ecosystem. Using it > >> with Qt 6 would also mean that we can focus our support on two build > >> systems for our users (qmake and cmake) and we would not have to add a > >> third one to the mix. > >> > >> Given that we are confident we can build Qt 6 with cmake, I believe that > >> it makes most sense to follow down that route. In case you’re > >> interested, you can have a look at the cmake prototype code for qtbase > >> on Gerrit in the wip/cmake branch. Please also let us know if you’re > >> interested in helping with the effort of porting Qt’s build system over > >> to cmake. > >> > >> We have been developing Qbs over the last years, and as such are > >> committed to it for some more time. We are planning on another feature > >> release in the first quarter of next year and will support it in Qt > >> Creator for at least another year. Qbs is open source and if someone > >> wants to take over and develop it further let us know as well. I’d also > >> like to use this place to thank Christian and Jörg for all their great > >> work on Qbs (and of course also anybody else who contributed to it). > >> > >> Cheers, > >> Lars > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From yetanotherandreyev at gmail.com Mon Oct 29 17:42:21 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Mon, 29 Oct 2018 19:42:21 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2505797.krPY0VdK3e@tjmaciei-mobl1> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <57137783.Y9GKUMOgDo@tjmaciei-mobl1> <2505797.krPY0VdK3e@tjmaciei-mobl1> Message-ID: I've got your idea. My personal position for now is probably more like do not promise things you can't keep. I still have no doubts about Qt and KDE people professionalism. I agree discrimination solving is very important idea. But I guess it probably should be solved via some additional international organization. Such organization could be focused specifically on that, while technical communities like KDE and Qt project could follow it. I want to thank Lydia too for sharing details about approximate number of the situations. I could not interpret it as "good or bad" for the community with current details, but I guess it could be helpful for future comparition. пн, 29 окт. 2018 г. в 18:40, Thiago Macieira : > On Monday, 29 October 2018 00:52:49 PDT Alexey Andreyev wrote: > > Talking about CC and KDE's CoC, it's not obvious for me how to perform > > politics, religion, race, etc -- harassment protection correctly at > > international digital community with provided rules. > > I'm not saying we don't need rules. You said KDE's version looks better > > comparing to CC. Archlinux version looks even better for me. > > > > Anyway, I'm not a professional at such social tasks and want to step > back. > > I do not want to look like annoying person, just wanted to help with > > controversial subjects. > > I have no doubts about Qt people professionalism and happy do be a part > of > > the community. > > For me, the fact that it doesn't say we'll try to address those problems > that > are currently extant in many communities (though, hopefully, not ours), > ArchLinux's CoC is inferior to KDE's. I'd like a text that says states the > goals we'll strive for, not just what we can be sure of. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch.curtis at qt.io Mon Oct 29 17:42:36 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Mon, 29 Oct 2018 16:42:36 +0000 Subject: [Development] Serialising UI state in QML via QSettings and JSON: QByteArray vs QString Message-ID: Hi. I'm trying to sort out some way of saving SplitView's (Qt Quick Controls 2) state. The goals that I have are: #1 Allow SplitView's state to easily be saved to QSettings. That's covered by the patch in its current form. #2 Allow SplitView's state to easily be saved to a custom project file, so that applications that need to save UI state on a per-project basis can do so. Both of these should be doable in QML (besides the IO-related details of saving to a custom project file). So far, my patch bases its API on that of QMainWindow. Here's the usage documentation showing how it's currently done in QML: https://codereview.qt-project.org/gitweb?p=qt/qtquickcontrols2.git;a=blob;f=src/quicktemplates2/qquicksplitview.cpp;h=6c5f72b1952e58f3f9c956ac129fc221a3017cb4;hb=4cdc2942c69a15484a65d7c8a48b1f129d7bd3d0#l194 Here's the implementation: https://codereview.qt-project.org/gitweb?p=qt/qtquickcontrols2.git;a=blob;f=src/quicktemplates2/qquicksplitview.cpp;h=6c5f72b1952e58f3f9c956ac129fc221a3017cb4;hb=4cdc2942c69a15484a65d7c8a48b1f129d7bd3d0#l1143 Here's what QMainWindow does: http://code.qt.io/cgit/qt/qtbase.git/tree/src/widgets/widgets/qmainwindow.cpp?h=dev&id=00b2e45a97205975ee91aa43f00e3dbef1a8907b#n1240 To solve #2, I first tried simply saving a QVariant containing a QByteArray (the contents of which were QDataStream's output). This didn't work because Qt's JSON implementation doesn't support QByteArray; it only supports QString. That is, calling QJsonObject::fromVariantMap(map) where "map" contains a QVariant containing a QByteArray will result in the corresponding JSON value being invalid/null. I thought that I could get around this by using Qt.atob() and Qt.btoa() in QML to convert the byte array into a Base64 QString, but it turns out that those functions expect a string: http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/qml/qml/v8/qqmlbuiltinfunctions.cpp?h=5.12&id=475c74a9926efcd968572563e678988e53804603#n996 Running the attached project gives the following output: created QString from SplitView state: QVariant(QByteArray, "\x00\x00\x00{\x01") qml: Saved state in QML as QVariant(QByteArray): qml: Converted state in QML to a Base64 string: expected base64 string in a QVariant, got: QVariant(QString, "") qml: Converted state in QML from Base64 string to QVariant(QByteArray): in C++, state from QML is: QVariant(QString, "") read i as 0 and b as false So now I'm considering what I should do. I'm thinking about making SplitView convert the QByteArray it creates with QDataStream into a Base64 QString and returning that instead. That can still be saved in QSettings, and can easily be used by both Qt's JSON implementation and Qt.atob() and Qt.btoa(). However, I understand that Base64 encoding can result in slightly larger strings when used on small input (which SplitView's serialisable state will typically be). With these uncertainties, I thought I'd ask what others think of my proposed approach, and if there are any better ways to solve this. Cheers. -------------- next part -------------- A non-text attachment was scrubbed... Name: splitview-state.zip Type: application/x-zip-compressed Size: 2891 bytes Desc: splitview-state.zip URL: From jhihn at gmx.com Mon Oct 29 17:42:39 2018 From: jhihn at gmx.com (Jason H) Date: Mon, 29 Oct 2018 17:42:39 +0100 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <484EC37F-746E-45FA-AF45-8C7D7D2E4536@qt.io> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <1613934.u2FelxWX76@tjmaciei-mobl1> <484EC37F-746E-45FA-AF45-8C7D7D2E4536@qt.io> Message-ID: Hi Volker, I think you ask a very good question. "If someone like Coraline were to direct her energy to the Qt Project, how much in the open would you want their efforts to be? Or would you rather simply trust that there are not enough maintainers in the Qt project that would fall for their chain of arguments and backdoor schemings?" Let's break that down. "If someone like Coraline were to direct her energy to the Qt Project" - 1) If by energy you mean, she wants to contribute, I would not have a problem with her participation despite me not agreeing with her previous behavior. Contributions would be judged on technical merits alone. 2) If by energy you mean a witch hunt, then it should be done publicly as to add to her existing history. 3) If by energy you mean a "legitimate complaint" then I guess it would depend on the nature of her claims. If the items of transgression are Qt community items, then it's already in public. If things were done in private then it would be debatable what influence the Qt community resolution process would have. So I don't have a clear answer for you, but that should set up some kind of framework. The agreement on venue is difficult. I could both see wanting public resolution or private resolution, and I can't even typify that based on scenario. Admittedly, I don't understand the last part of your question. "simply trust that there are not enough maintainers in the Qt project that would fall for their chain of arguments and backdoor schemings". Previously I suggested that the people selected to judge the process be entirely at random to prevent politicisation of the decision makers. And also evidence should only be considered if on a Qt community property. At the same time, these incidents may have confidential information, which should be protected from public disclosure. I think all of that fell on deaf ears? I've asked repeatedly for very specific definitions and standards of things to be considered. This would go along way to getting my approval. I will always resist an ambiguous judgements on ambiguous standards. The process should be transparent to those involved in it, such that you should know how it will turn out before entering into the process. I don't think ambiguity serves anyone justly. > Sent: Monday, October 29, 2018 at 11:33 AM > From: "Volker Hilsheimer" > To: "Jason H" > Cc: "Lydia Pintscher" , "Qt development mailing list" > Subject: Re: [Development] QUIP 12: Code of Conduct > > Hey Jason, > > > You seem to assume that without a code of conduct there is no way that people can get banned. That is not the case. In practice, people can be kicked out of the Qt Project by the folks that control the respective systems. And by extension by those who have some influence over those people. > > You call that “self-policing”, but in fact it’s about us trusting that the folks that have those privileges do not abuse their power. That’s great as long as it works, but if the project somehow does become “more political”, then I do think this lack of transparency is not in the interest of the project. > > A CoC tries to formulate what environment we want our behaviors to create, and it establishes a less opaque process for managing situations where an individual seems to do more harm than good to the project. > > That doesn’t mean that there won’t be mistakes. It doesn’t take much to cause someone distress through an email or a quick comment to their code, esp when we want to include people that are regularly exposed to all sorts of harassment, and are not quite as thick-skinned and self-assured as you and I might be. But I think that, by simply establishing a CoC that community members agree to, we can create an atmosphere where even a rough piece of language is received in the spirit of collaboration. > > And that also doens’t mean that there won’t be abuse. I’m sure there are people that have made it a way of life to be offended. However, they do not need a Code of Conduct (which is not a legal document anyway). I’d rather have them raise their voice in the open, and direct them towards a transparent process, than to have them use backdoor tactics to get influence over the project. > > The question to you is then: If someone like Coraline were to direct her energy to the Qt Project, how much in the open would you want their efforts to be? Or would you rather simply trust that there are not enough maintainers in the Qt project that would fall for their chain of arguments and backdoor schemings? > > > Volker > > > > On 29 Oct 2018, at 15:10, Jason H wrote: > > > > Lydia, > > > > First, let me say I've stated my support of the KDE CoC. Thank you for your effort in it. > > > > But then you make a statement in your post script that demonstrates exactly what I'm talking about. You stated "some emails in this thread sadly make me see part of the project in a different light. I fear I'm not the only one."? Would you say the project has created fear in you and this has somehow "harmed" the project in some way? Who were these people that changed your mind? We need to identify these people and ban them because they are not casting the widest inclusive and protective audience and anything less than that is harm... Let the witch hunt begin... right? > > > > Everyone, > > This is the slippery slope that I'm talking about accusations start in wide-abstractions like your statement and devolve into direct accusations. While no one yet here has the motivation to conduct a witch hunt, we cannot assume that will be the case. So far common sense has prevailed, but common sense is, well, uncommon. It may be that Cone day oraline et. al. go on a witch hunt for those the opposed her Covenant. > > > > I've spent some time thinking about this this weekend. Here's what I don't get. Coraline authored the CC. She then goes into projects attacking them with it, but fortunately(?) it hasn't worked. But to put it a different way, if I design an instrument, publish the plans, and try to use it in a community, if it doesn't work, is it the instrument or the user that is at fault? If that instrument is intended to be destructive (say like a bomb), then can we see how she really means for this to be used? To my knowledge none of the people singled out in the witch hunts actually did anything offensive in the projects they were participating in. > > > > It could be that eventually those who opposed the CoC in some way get labeled as "intolerant" by the larger community. Lydia's statement has already given me pause in this regard and I'm not being hyperbolic. Political views, and things we don't consider as political today, can eventually become political. > > > > I think we have two camps: > > We want a CoC as a feel-good statement of inclusion and tolerance (I think everyone is committed to this) > > AND > > 1) We want to use existing situation of laws/self-policing OR > > 2) We want a CoC that contains a framework that can get people banned or more > > > > I've always assumed that there was some line that could be crossed that would get your accounts shut down and removed from the community. If someone makes it so that the community cannot function, in whole or in part, then removal is warranted. These Codes of Conducts lower the barrier to an incredibly low bar and don't say what lower threshold of "harm" is needed to run afoul. I haven't even had a response as to if it is perceived or demonstrable harm that is required. > > > > So far cooler heads and common sense have prevailed, but I don't trust that will always be the case. This is why if we go with a CoC that can prescribe punishments, that it be explicit both in determination and punishment stages. > > > > > > *Not that I have anything against witches. I have several wiccan friends. Is the term "witch hunt" offensive? Can I get banned for using that term now or in the future? > > > > > >> Sent: Sunday, October 28, 2018 at 7:53 PM > >> From: "Lydia Pintscher" > >> To: development at qt-project.org > >> Subject: Re: [Development] QUIP 12: Code of Conduct > >> > >> On Sun, Oct 28, 2018 at 10:45 PM Thiago Macieira > >> wrote: > >>> And I'm pretty sure the KDE Community WG can easily compile a list of times > >>> that they were maliciously asked to look into situations and how much time it > >>> took them to give it the attention it was due. > >> > >> I don't have an exact number but less than 10. And we could always > >> deal with it very quickly thanks to some common sense and good > >> knowledge of the situation and people involved. No big deal. > >> > >> (For those who don't know me: I'm one of the people who wrote KDE's > >> CoC and has been a member of it's community working group since then. > >> I'm also the current president of the non-profit behind KDE.) > >> If you have further questions about KDE's Code of Conduct please let > >> me know. I'm happy to answer them. > >> > >> > >> Cheers > >> Lydia > >> > >> PS: As someone on the fringes of the Qt Project some emails in this > >> thread sadly make me see part of the project in a different light. I > >> fear I'm not the only one. > >> > >> -- > >> Lydia Pintscher - http://about.me/lydia.pintscher > >> KDE e.V. Board of Directors > >> http://kde.org - http://open-advice.org > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > >> > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > From Frederik.Gladhorn at qt.io Mon Oct 29 18:00:43 2018 From: Frederik.Gladhorn at qt.io (Frederik Gladhorn) Date: Mon, 29 Oct 2018 17:00:43 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> Message-ID: <770422469.DYPMngzlOe@frederik-thinkcentre-m93p> Hi all, I would like to thank the people who have started this discussion. For me this is a very positive thing and a step forward for the Qt community. I really enjoy being part of the community. I want it to continue to be the great group of people that it is today. And hopefully bigger, more diverse and inclusive going forward. I am very sure that a big silent majority does support this initiative. Again, thank you! Reading through the mails (an impressive amount), I feel there is consensus towards the KDE CoC. I also appreciate the positive wording. Maybe we don't need many more mails in this thread, I have the feeling we will not discover a whole lot of new information at this point. I'd like us to move on to the next constructive phase of this process. Let's adopt the more positively phrased CoC from KDE. It is under a license that allows us to use it and is clearly meant to be picked up by others. I am happy that so many people have strong opinions on our culture and value it. For me this is about culture, how we treat each other. That is what being a community is all about. We have a common goal - making Qt the best it can be, and nobody is able to do that alone. We will always have some style of communication in the project. I am happy when I see positive reviews. In my opinion that can be a -1 with good comments which problems to address. Let's set ourselves a high standard, on the communication side as well as on the technical one. I hope we use this as an opportunity to remind ourselves that in reviews we should give ideas what to improve (and how). Reviews are important to share knowledge, which is important to us as community. In emails we should be respectful, on the forums sensible and so on. I think we mostly succeed nowadays. Moving on... we should find out how to deal with the occasional problems that might arise. I do think that we want to establish some form of enforcement. I firmly believe that the first means of action in all cases will be an email or two, just to clarify the situation. Maybe a phone call. Often enough conflicts turn out to be small misunderstandings and we want a reasonable small group of people that keeps things confidential and just nudges people to talk to each other and move on. Only when everything goes wrong should stronger measures ever be considered. Thus we want a group we can trust with making sensible decisions in how to uphold the CoC. I would want them to have some diplomatic skills, respect privacy and be sensitive to different cultures - good communicators. Cheers, Frederik From iamsergio at gmail.com Mon Oct 29 18:21:27 2018 From: iamsergio at gmail.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Mon, 29 Oct 2018 17:21:27 +0000 Subject: [Development] wip/cmake status information In-Reply-To: References: Message-ID: On Mon, Oct 29, 2018 at 12:31 PM Tobias Hunger wrote: > > Hi! > > Some technical details on the wip/cmake branch in Gerrit. You can also > find this information in cmake/README.md there. I'm wondering if you have any performance numbers regarding incremental builds on Windows, and specially "nmake install", which currently takes *several* minutes for qtbase alone. Through ETW I noticed it's due to hundreds of qmake processes being created, so I guess the problem is gone now :) Thanks, and nice work everyone! Regards, Sérgio Martins From olivier at woboq.com Mon Oct 29 18:46:18 2018 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 29 Oct 2018 18:46:18 +0100 Subject: [Development] Metatype system in Qt6 In-Reply-To: <2756315.1D9YIM6Clu@snoll> References: <2756315.1D9YIM6Clu@snoll> Message-ID: <3d810856-fe12-7dea-6b6b-d7aba2876a7c@woboq.com> On 10/29/18 5:39 PM, Jedrzej Nowacki wrote: > Hi everyone! > > While main heat on the mailing list is taken by topic how to encode that we > are nice, friendly and respectful to each other, I would like to show some > side project that I had. It is a proposal for base of metatype system for Qt6. > You can look and comment at it here: https://github.com/nierob/qmetatype. It > is quite fresh and it was rather a storage for functionality ideas. I haven't > tried to compare performance of it to the current system, but for sure it has > more flexibility and I believe, that conceptually it could serve us during > Qt6. Anyway before spending too much time on it I would like to get some early > feedback and questions. The discussion in that other thread are not finished, so please wait until there is consensus before being nice! But thanks for caring about the QMetaType system. I had a short look. I think it would be usefull if you already used names closer to what they are supposed to be. Namespace N, P, are not so nice names. The idea of using a single function with operation is quite a good idea I like it. As long as the function takes the typeid as a parameter. Indeed, I'm thinking about dynamic types that would come from language bindings: in this situation, while it is easy to allocate memory on the heap, it is not easy to create a new function pointer for every dynamic type that we would register. Regarding the extension, i don't know if it is such a good idea, because you never know what you can rely on. say you have a QVariant with some type that comes from some part of your code, how do you know if you can print it with qDebug, or convert it to string, how do you register that? IMHO, there should not be extensions! All operation that we want to make available for a type should be always available. Using SFINAE to find out if it is available. So what are the operation we want on a QMetaType: - for QVariant, and the queued connections: copy / destruction. Ideally in place. So we also need the size/alignement to be able to allocate the memory - for qDebug, we need the QDebug operator << - for QDataStream, we need the operator << and >>, and an unique identifier that stay the same. Currently, this is the type id for builtin types, and the name for custom type. I suggest we use the name, if we want to keep compatibility with old steam, we will need to keep a mapping from old type id, to new name. As for the name, we can indeed find a way to extract it from parsing it from __PRETTY_FUNC__ as you do. It would work on every compiler we support i guess, but we need spcial code for that as it is not really standard. In Qt5, we also need the name for the string-based connection syntax. However, I believe we can do that without relying on the name "as-seen-by-moc", if the moc generated code always register the types. (this is already almost the case) - What about QSequentialIterable / QAssociativeIterable? We also need something there. In the design document you say: > The whole registry is kept behind a mutex and it is very central, the mutex > usage actually shows on profilers. This used to be the case before Qt 5.7, but since then, QReadWriteMutex was greatly optimized, does it still show in the profiler? You will need that anyway, because relying on a static variable in a function template does not work on MSVC as far as i know. (Last time i tried was a long time ago, and they had different address and value in different libraries) That's why we will probably need to initialize it with a name lookup. It is probably still a good idea to register builtin type at compile time, since we want to save in registering time. There are some data structures out there with compile time hash table that can be extended at runtime. So the early feedback i can give on your code is that it is a bit more complicated than necessary with the extension. and i think it can be simplified. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From edward.welbourne at qt.io Mon Oct 29 18:48:09 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 29 Oct 2018 17:48:09 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <857668e0-6209-244a-732f-2415263e6551@qt.io> <2539432.vSGsD3zg6Y@vkpc19> <20181025173945.GA16670@klara.mpi.htwm.de> <20181026095004.21207e9c@ckandeler-archlinux> , Message-ID: In a context of witch-hunts against even allegations of minimal harm, NIkolai Marchenko (26 October 2018 20:17) wrote >> And we already see the budding sentiments to that exact tune: >> (quote from Edward Welbourne) >>> That sometimes folk have felt so intimidated that they give up on >>> trying to make a contribution; and that, were potential worse >>> conduct to cause distress to a contributor, we have no process in >>> place that could give them confidence that their distress will be >>> respected and honest efforts will be made to relieve it. Various >>> variations and permutations on these themes may also be relevant; >>> see Simon's mail. >> Note: I understand that he means well, but Within the context of >> Contributor Covenant the punishability of the potential harm of >> people not contributing can escalate to stupid proportions. I have >> nothing against KDE's code. It strives to add positivity. I am very >> much against Qt's CoC being drafted from Covenant. Covenant is >> focused on oppression and excluding ppl. Just to be clear: I was speaking of the case for having *a* code of conduct and a publicly-described process around coaxing folk into honouring it. In particular, I'm not particularly attached to the present wording, nor do I know more than the present discussion has (since I wrote the above) told me about the Contributors' Covenant on which it is based. What I asked for was a process that a contributor can turn to, with reasonable hopes of being heard and getting help, if they feel persecuted. If their feelings of persecution are not anchored in any actual conduct by a community member that actually persecutes them I am all for the process (politely and respectfully) teaching them to not feel persecuted when they aren't being persecuted. I am firmly in favour of the code of conduct's associated processes being proportionate, precisely so that they avoid any objection to an alleged or potential harm escalating "to stupid proportions". I do, indeed, find the Covenant-derived wording and process somewhat heavy-handed and hope I shall soon find the time to read the KDE CoC, of which several voices here have spoken favourably. I'm in favour of *a* code of conduct, and associated processes, precisely if it assures folk who deal with this community of reasonable and respectful treatment. It rather sounds as if the Contributors' Covenant (or, at least, the history of how it's been used) undermines your confidence that you'll be treated reasonably and respectfully, if what we adopt is based on it. Please make the case for that, rather than imputing that I am a preparing the way (however unwittingly) for witch-finders ;^> Jason H (29 October 2018 17:42) ended a recent missive with: > I've asked repeatedly for very specific definitions and standards of > things to be considered. This would go along way to getting my > approval. I will always resist an ambiguous judgements on ambiguous > standards. The process should be transparent to those involved in it, > such that you should know how it will turn out before entering into > the process. I don't think ambiguity serves anyone justly. Specifics are exactly what the code review is for. Come join us at: https://codereview.qt-project.org/243623 I assure you, you are not alone in wanting this thing nailed down tidily enough that there aren't loose flaps under which Aliens with Agendas (whether of the left or the right, whether progressive or reactionary) can slip in and work mischief for our community, Eddy. From edward.welbourne at qt.io Mon Oct 29 19:30:47 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 29 Oct 2018 18:30:47 +0000 Subject: [Development] Serialising UI state in QML via QSettings and JSON: QByteArray vs QString In-Reply-To: References: Message-ID: Mitch Curtis (29 October 2018 17:42) > To solve #2, I first tried simply saving a QVariant containing a > QByteArray (the contents of which were QDataStream's output). This > didn't work because Qt's JSON implementation doesn't support > QByteArray; it only supports QString. That is, calling > QJsonObject::fromVariantMap(map) where "map" contains a QVariant > containing a QByteArray will result in the corresponding JSON value > being invalid/null. I'm not sure where JSON got involved in that, but if you can manage to use CBOR instead, it's just as happy with QByteArray as with QString (and round-trips them to QByteArray, IIRC). For details, see qtbase/src/corelib/serialization/qcborstream.h I've also no idea how well it plays with QSettings; hopefully you know enough to work it out from the QCbor API ... Eddy. From tobias.hunger at gmail.com Mon Oct 29 19:53:31 2018 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Mon, 29 Oct 2018 19:53:31 +0100 Subject: [Development] wip/cmake status information In-Reply-To: References: Message-ID: On Mon, Oct 29, 2018 at 6:21 PM Sérgio Martins wrote: > I'm wondering if you have any performance numbers regarding > incremental builds on Windows, and specially "nmake install", which > currently takes *several* minutes for qtbase alone. Through ETW I > noticed it's due to hundreds of qmake processes being created, so I > guess the problem is gone now :) Not yet. So far too much is missing to do a meaningful comparisons. Best Regards, Tobias From apoenitz at t-online.de Mon Oct 29 21:18:53 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Mon, 29 Oct 2018 21:18:53 +0100 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <9043feb7-dc9a-bbdc-d52f-19add7492825@qt.io> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <1613934.u2FelxWX76@tjmaciei-mobl1> <9043feb7-dc9a-bbdc-d52f-19add7492825@qt.io> Message-ID: <20181029201853.GA2391@klara.mpi.htwm.de> On Mon, Oct 29, 2018 at 02:25:20PM +0000, Ulf Hermann wrote: > > But then you make a statement in your post script that demonstrates > > exactly what I'm talking about. You stated "some emails in this > > thread sadly make me see part of the project in a different light. I > > fear I'm not the only one."? Would you say the project has created > > fear in you and this has somehow "harmed" the project in some way? > > Who were these people that changed your mind? We need to identify > > these people and ban them because they are not casting the widest > > inclusive and protective audience and anything less than that is > > harm... Let the witch hunt begin... right? > > All the proposals for codes of conduct that I have seen so far mention > banning only as a last resort and have several less drastic measures > that should be applied before. That's exactly the way the Project has operated before, without the suggested burocratic overhead and without giving some committee super-powers ranking over all other mechanisms in the project. Sure, each time when action has to be taken on IRC or by mailing list moderation, people taking that decision feel somewhat uneasy, lest they be accused of censorship or similar. But that is *good*, as it makes people exercise any extra powers very consciously. > Also, the point of having a neutral third > party decide on the issue, rather than people directly involved in the > conflict should result in that third party deciding on the measurements > to be taken, not any victims of harassment, harm, or whatever. Currently the Qt Project defines itself as "meritocratic, consensus-based community interested in Qt". After the suggested I fail to see how it can be called either. Andre' From yetanotherandreyev at gmail.com Mon Oct 29 20:45:42 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Mon, 29 Oct 2018 22:45:42 +0300 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <20181029201853.GA2391@klara.mpi.htwm.de> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <1613934.u2FelxWX76@tjmaciei-mobl1> <9043feb7-dc9a-bbdc-d52f-19add7492825@qt.io> <20181029201853.GA2391@klara.mpi.htwm.de> Message-ID: Hello! I've tried to provide Code of Conduct based on Arch Linux CoC, pasted here: https://paste.kde.org/pzdmvyi3t Will try to send it to codereview later, feel free to do it instead of me if it will be easier for you, I'm going to spend some time to learn how to do it correctly пн, 29 окт. 2018 г. в 22:19, André Pönitz : > On Mon, Oct 29, 2018 at 02:25:20PM +0000, Ulf Hermann wrote: > > > But then you make a statement in your post script that demonstrates > > > exactly what I'm talking about. You stated "some emails in this > > > thread sadly make me see part of the project in a different light. I > > > fear I'm not the only one."? Would you say the project has created > > > fear in you and this has somehow "harmed" the project in some way? > > > Who were these people that changed your mind? We need to identify > > > these people and ban them because they are not casting the widest > > > inclusive and protective audience and anything less than that is > > > harm... Let the witch hunt begin... right? > > > > All the proposals for codes of conduct that I have seen so far mention > > banning only as a last resort and have several less drastic measures > > that should be applied before. > > That's exactly the way the Project has operated before, without the > suggested burocratic overhead and without giving some committee > super-powers ranking over all other mechanisms in the project. > > Sure, each time when action has to be taken on IRC or by mailing > list moderation, people taking that decision feel somewhat uneasy, > lest they be accused of censorship or similar. But that is *good*, > as it makes people exercise any extra powers very consciously. > > > Also, the point of having a neutral third > > party decide on the issue, rather than people directly involved in the > > conflict should result in that third party deciding on the measurements > > to be taken, not any victims of harassment, harm, or whatever. > > Currently the Qt Project defines itself as "meritocratic, > consensus-based community interested in Qt". > > After the suggested I fail to see how it can be called either. > > Andre' > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Oct 29 20:44:01 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Oct 2018 12:44:01 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <20181029201853.GA2391@klara.mpi.htwm.de> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <9043feb7-dc9a-bbdc-d52f-19add7492825@qt.io> <20181029201853.GA2391@klara.mpi.htwm.de> Message-ID: <3557699.MfSfXolpKe@tjmaciei-mobl1> On Monday, 29 October 2018 13:18:53 PDT André Pönitz wrote: > Currently the Qt Project defines itself as "meritocratic, > consensus-based community interested in Qt". > > After the suggested I fail to see how it can be called either. We'd have to amend to say that unprofessional behaviour (as defined by the CoC) will not be welcome, regardless of how much merit the particular person may have accumulated. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nospam at vuorela.dk Mon Oct 29 21:36:30 2018 From: nospam at vuorela.dk (Sune Vuorela) Date: Mon, 29 Oct 2018 20:36:30 +0000 (UTC) Subject: [Development] QUIP 12: Code of Conduct References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <20181028153617.GA1855@klara.mpi.htwm.de> <22401396.2MeYvLZH0H@tjmaciei-mobl1> Message-ID: On 2018-10-28, Thiago Macieira wrote: > But if it isn't spam, what gives the list moderator the right to intervene in > something that he/she believes is abusive behaviour? Same thing about IRC: we > do have one annoying person who does come along every now and then, but most > of his messages are just that: annoyance. It's only when he uses profanity > that I feel justified in kicking him out of the channel. > > Am I the one abusing my position as channel op to kick him? Am I being > arbitrary? I feel you are using your position as chan op to kick him far too rare. But I'm not sure where to bring that up. /Sune - also these days in favour of a CoC, but has also protested against such things in the past. From thiago.macieira at intel.com Mon Oct 29 22:08:47 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Oct 2018 14:08:47 -0700 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <22401396.2MeYvLZH0H@tjmaciei-mobl1> Message-ID: <1816644.OX8Gd64zvP@tjmaciei-mobl1> On Monday, 29 October 2018 13:36:30 PDT Sune Vuorela wrote: > I feel you are using your position as chan op to kick him far too rare. > But I'm not sure where to bring that up. The 15-day ban expired yesterday, so he's back today. Next one will be 45 days. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ola at silentwings.no Mon Oct 29 22:53:47 2018 From: ola at silentwings.no (=?UTF-8?Q?Ola_R=C3=B8er_Thorsen?=) Date: Mon, 29 Oct 2018 22:53:47 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: <5627437.H1gup227mp@dragon> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <5627437.H1gup227mp@dragon> Message-ID: > > > > >> We have been developing Qbs over the last years, and as such are > > >> committed to it for some more time. We are planning on another feature > > >> release in the first quarter of next year and will support it in Qt > > >> Creator for at least another year. > This is _really_ disappointing news. I'd be happy to see qmake go, now this. We (at work, commercial Qt license) recently ported a rather big build system to Qbs, replacing qmake and scons. We now have good IDE integration for all our projects in QtCreator, both the Qt-based applications as well as pure C/C++-based projects for desktop, embedded Linux and "bare metal" embedded. We spent some time debugging and reporting/fixing bugs in Qbs too. Now with Qbs 1.12.0 we're having good and stable results. Incremental builds are _very_ fast. Project files are easy to set up, read and extend, even with custom code generation rules, things we never were able to do with (even undocumented) qmake. It's really impressive. Well I guess all that was for nothing, let's rewrite the build system next year again, and make really sure not to embrace new Qt technologies so fast next time. Cheers, Ola -------------- next part -------------- An HTML attachment was scrubbed... URL: From sierdzio at gmail.com Mon Oct 29 22:57:45 2018 From: sierdzio at gmail.com (Tomasz Siekierda) Date: Mon, 29 Oct 2018 22:57:45 +0100 Subject: [Development] wip/cmake status information In-Reply-To: References: Message-ID: On Mon, 29 Oct 2018 at 13:31, Tobias Hunger wrote: > > Hi! > [...] > # Building > > The basic way of building with cmake is as follows: > > ``` > cd {build directory} > cmake {path to source directory} > cmake --build . > ``` Just a quick question wrt to that snippet: what is the planed way of building Qt after the whole transition is done? Will it be cmake && make, or configure && make, or configure && cmake && make? From Simon.Hausmann at qt.io Mon Oct 29 23:06:41 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Mon, 29 Oct 2018 22:06:41 +0000 Subject: [Development] wip/cmake status information In-Reply-To: References: , Message-ID: <06377B98-3507-416C-A1BB-551DC8616D8D@qt.io> The idea is to stick to the cmake way. So cmake with a generator of choice, potential cmake-gui usage to tweak if you’d like and finally the build tool that corresponds to the generator. Simon > On 29. Oct 2018, at 17:58, Tomasz Siekierda wrote: > >> On Mon, 29 Oct 2018 at 13:31, Tobias Hunger wrote: >> >> Hi! >> [...] >> # Building >> >> The basic way of building with cmake is as follows: >> >> ``` >> cd {build directory} >> cmake {path to source directory} >> cmake --build . >> ``` > > Just a quick question wrt to that snippet: what is the planed way of > building Qt after the whole transition is done? Will it be cmake && > make, or configure && make, or configure && cmake && make? > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From enmarantispam at gmail.com Mon Oct 29 23:15:38 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue, 30 Oct 2018 01:15:38 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <5627437.H1gup227mp@dragon> Message-ID: I don't understand how can Qt just let QBS die like that. It's absolutely fantastic. I really hope open source development happens becuase ti will be bloody shame if ti doesn't :( On Tue, Oct 30, 2018 at 12:54 AM Ola Røer Thorsen wrote: > >> > >> We have been developing Qbs over the last years, and as such are >> > >> committed to it for some more time. We are planning on another >> feature >> > >> release in the first quarter of next year and will support it in Qt >> > >> Creator for at least another year. >> > > This is _really_ disappointing news. I'd be happy to see qmake go, now > this. > > We (at work, commercial Qt license) recently ported a rather big build > system to Qbs, replacing qmake and scons. We now have good IDE integration > for all our projects in QtCreator, both the Qt-based applications as well > as pure C/C++-based projects for desktop, embedded Linux and "bare metal" > embedded. We spent some time debugging and reporting/fixing bugs in Qbs > too. Now with Qbs 1.12.0 we're having good and stable results. Incremental > builds are _very_ fast. Project files are easy to set up, read and extend, > even with custom code generation rules, things we never were able to do > with (even undocumented) qmake. It's really impressive. > > Well I guess all that was for nothing, let's rewrite the build system next > year again, and make really sure not to embrace new Qt technologies so fast > next time. > > Cheers, > Ola > > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Mon Oct 29 23:55:58 2018 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 29 Oct 2018 22:55:58 +0000 Subject: [Development] wip/cmake status information References: Message-ID: Tomasz Siekierda wrote: > On Mon, 29 Oct 2018 at 13:31, Tobias Hunger wrote: >> >> Hi! >> [...] >> # Building >> >> The basic way of building with cmake is as follows: >> >> ``` >> cd {build directory} >> cmake {path to source directory} >> cmake --build . >> ``` > > Just a quick question wrt to that snippet: what is the planed way of > building Qt after the whole transition is done? Will it be cmake && > make, or configure && make, or configure && cmake && make? cmake .. -G Ninja or cmake .. -G "Visual Studio 15 2017" or cmake-gui etc then cmake --build . --target install or cmake --build . --target install --config release if on Windows. Thanks, Stephen. From enmarantispam at gmail.com Tue Oct 30 02:20:35 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue, 30 Oct 2018 04:20:35 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: Lars, I have to wonder, don't you guys miss an opportunity here? Qt 5 was not developed with QBS in mind. As such it probably took more effort than needed to fit QBS to something that was originally QMake based. At the same time you will have to fit CMake to suit the needs for Qt6. (or vice versa) Would it really be so much extra investment to have a build system fully integrated into Qt framework process that you can just make fit on the fly, over fiddling around the system that is overgeneralized and perhaps doesn't support everything as much as you'd want? You've said it yourself that qbs did give good results. Maybe give it a chance? On Mon, Oct 29, 2018 at 3:17 PM Lars Knoll wrote: > Hi all, > > As you will probably remember, there have been lively discussions around > what kind of build tool to use for Qt 6 both during Qt Contributor Summits > as well as on this mailing list. > > There has been a strong consent that we should move away from qmake as our > build tool for Qt due to many shortcomings and the burden we have > maintaining the system. > > Thiago wrote a set of relatively strict requirements for such a build tool > in his mail in July. While some of the requirements had a bit of a Linux > specific background, they have been a good basis. > > There have been rather lively discussions around alternatives, but most > focused around two possible choices for us: Qbs and cmake. > > Qbs is something that has been developed almost exclusively by The Qt > Company. As such, TQtC had to also look at it from a business perspective > and how it fits into the larger picture of making Qt successful. To make a > long story short, while Qbs is pretty cool and interesting technology, it > doesn’t really help us expand the Qt ecosystem and usage. > > To make Qbs really successful would require a rather large effort and > investment in promoting it towards the larger C++ ecosystem as a new build > tool. At the same time it has to be an open source product to stand any > chance in the market. Together this makes it challenging for TQtC to see > how to recover that investment. Thus this investment would be at the > expense of other things we’d like to do, like improving our IDE, working on > rearchitecting and cleaning up our core frameworks for Qt 6 or the design > tooling we are currently investing into. The Qt Company believes that those > other investments are more important for the future of Qt than our choice > of build tool. > > As such, we were left with the question on whether we need Qbs as the > build system for Qt 6 or whether cmake (as the other alternative) would be > up to the task. > > Given that background, we’ve done some more research on using both Qbs and > cmake to build Qt. Both projects did give us good results but we were > actually surprised on how far we got with cmake in a rather limited period > of time. > > In addition, cmake has the advantage of being very widely used in the C++ > ecosystem (amongst many others by KDE), has a very wide support in many > IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of > knowledge about the build system available in the ecosystem. Using it with > Qt 6 would also mean that we can focus our support on two build systems for > our users (qmake and cmake) and we would not have to add a third one to the > mix. > > Given that we are confident we can build Qt 6 with cmake, I believe that > it makes most sense to follow down that route. In case you’re interested, > you can have a look at the cmake prototype code for qtbase on Gerrit in the > wip/cmake branch. Please also let us know if you’re interested in helping > with the effort of porting Qt’s build system over to cmake. > > We have been developing Qbs over the last years, and as such are committed > to it for some more time. We are planning on another feature release in the > first quarter of next year and will support it in Qt Creator for at least > another year. Qbs is open source and if someone wants to take over and > develop it further let us know as well. I’d also like to use this place to > thank Christian and Jörg for all their great work on Qbs (and of course > also anybody else who contributed to it). > > 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: From thiago.macieira at intel.com Tue Oct 30 04:34:22 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Oct 2018 20:34:22 -0700 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: <1678597.qZIjjK9tzR@tjmaciei-mobl1> On Monday, 29 October 2018 18:20:35 PDT NIkolai Marchenko wrote: > Lars, I have to wonder, don't you guys miss an opportunity here? > Qt 5 was not developed with QBS in mind. As such it probably took more > effort than needed to fit QBS to something that was originally QMake based. > > At the same time you will have to fit CMake to suit the needs for Qt6. (or > vice versa) > > Would it really be so much extra investment to have a build system fully > integrated into Qt framework process that you can just make fit on the fly, > over fiddling around the system that is overgeneralized and perhaps doesn't > support everything as much as you'd want? I'm not Lars. But yes. The Qt 6 organisation won't be too different from Qt 5's, aside from the changes that Lars and Tobias have already mentioned and that make a lot of sense to me. So I don't see how any kind of organisation will make it easier. More importantly, the problem is keeping that specific buildsystem working. If the work isn't shared and others don't pitch in, the price to pay to keep a Qt-only buildsystem working is too high: that's what Lars' email says. Finally, I'm sure any reasonable request we may have on something CMake doesn't support yet, upstream will be willing to hear us and implement where necessary. I quite frankly don't expect there to be much, especially since Lars' email says that they made so much progress in so little time. > You've said it yourself that qbs did give good results. Maybe give it a > chance? It's been given a chance. The wip/qbs branch has existed for years in qtbase. The tool has existed for years. Can you name any project of moderate complexity using it? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Tue Oct 30 06:10:48 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 30 Oct 2018 05:10:48 +0000 Subject: [Development] HEADS-UP: Branching from '5.12' to '5.12.0' (almost) done In-Reply-To: References: Message-ID: Hi all, Final downmerge from '5.12' to '5.12.0' is mostly done; only qtbase and qtdeclarative is still ongoing. So from now on all changes targeted to Qt 5.12.0 release needs to be done in '5.12.0' and '5.12' is for Qt 5.12.1 release. br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Monday, October 22, 2018 6:45 PM To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Development] HEADS-UP: Branching from '5.12' to '5.12.0' started Hi, We have soft branched '5.12.0' from '5.12'. Please start using '5.12.0' for new changes targeted to Qt 5.12.0 release. Final downmerge from '5.12' to '5.12.0' will happen Mon 29th October so there should be enough time to finalize ongoing changes in '5.12' and start using '5.12.0'. Target is to release Qt 5.12.0 RC mid November so it is time to fix remaining blockers from blocker list (https://bugreports.qt.io/issues/?filter=19961) BR, Jani _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From resurrection at centrum.cz Tue Oct 30 06:29:39 2018 From: resurrection at centrum.cz (resurrection at centrum.cz) Date: Tue, 30 Oct 2018 06:29:39 +0100 Subject: [Development] =?utf-8?q?Build_system_for_Qt_6?= Message-ID: <20181030062939.85F46F36@centrum.cz> Honestly I feel very disappointed as well with this decision. I feel similarly to others, Qbs is now being phased out so fast (half a year of development, another half a year of maintanance after that it seems). So better get to porting stuff to CMake right away. Having experience with CMake this is gonna be very ugly...    What I do not understand is why the decision was qmake + cmake in the first place. Why not Qbs + CMake? Was not the qmake deemed unmaintainable? It is perfectly understandable to tap into wide CMake user base but why ditching Qbs and not qmake? I wouldn't expect people would mourn qmake...   Oh and on the point of CMake. Lets write a simple if statement as per docs:   set(var1 "Hello") set(var2 "Hello") if(var1 EQUAL var2)     message("They are equal") endif()   Guess what, it prints NOTHING despite docs explicitly saying this should work. Nothig will help, STREQUAL, MATCHES, dereferencing the arguments, whatever. This will work:   string(COMPARE EQUAL ${var1} ${var2} _cmp) if (_cmp)     message("They are equal") endif()   Yeah, fortunately there is a wide knowledge how to work around this kind of stuff. There are MANY other things like that that will make you cry when writing even simple things in CMake's "language". Not to mention CMake is not a build system, Qbs is.   Anyway, what's done is done I guess.  Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierluigi.fiorini at gmail.com Tue Oct 30 08:12:33 2018 From: pierluigi.fiorini at gmail.com (Pier Luigi Fiorini) Date: Tue, 30 Oct 2018 08:12:33 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: <1678597.qZIjjK9tzR@tjmaciei-mobl1> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1678597.qZIjjK9tzR@tjmaciei-mobl1> Message-ID: Il giorno mar 30 ott 2018 alle ore 04:34 Thiago Macieira < thiago.macieira at intel.com> ha scritto: > > > You've said it yourself that qbs did give good results. Maybe give it a > > chance? > > It's been given a chance. The wip/qbs branch has existed for years in > qtbase. > The tool has existed for years. > No Qbs hasn't got visibility outside the Qt project and even inside there are people, like me, who really learned about it a couple years ago and then it was planned to be the Qt 6 build system. With more visibility, documentation and examples in all those years, things might different now. Some people say Qt is not in the business of creating a build tool but it was not in the business of creating an IDE but we have QtCreator, which is an excellent IDE tailored to the needs of Qt developers. In less than two years we went from the build system planned for Qt 6 to a deprecated tool. Spending those years improving CMake (documentation, IDE integration, ...) would have been far better then. > > Can you name any project of moderate complexity using it? > > https://github.com/lirios -- https://liri.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From chgans at gmail.com Tue Oct 30 08:13:30 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Tue, 30 Oct 2018 20:13:30 +1300 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181030062939.85F46F36@centrum.cz> References: <20181030062939.85F46F36@centrum.cz> Message-ID: Warning: Free sarcasm, i'm not serious (well, maybe a little bit...) On Tue, 30 Oct 2018 at 18:29, wrote: > > Honestly I feel very disappointed as well with this decision. I feel similarly to others, Qbs is now being phased out so fast (half a year of development, another half a year of maintanance after that it seems). So better get to porting stuff to CMake right away. Having experience with CMake this is gonna be very ugly... Come on, the CMake project will quickly implement all the Qt project requirements. And Qt Creator is about to have full blown support for it. > What I do not understand is why the decision was qmake + cmake in the first place. Why not Qbs + CMake? Was not the qmake deemed unmaintainable? It is perfectly understandable to tap into wide CMake user base but why ditching Qbs and not qmake? I wouldn't expect people would mourn qmake... 2 unmaintainable systems are better than one. > Oh and on the point of CMake. Lets write a simple if statement as per docs: > set(var1 "Hello") > set(var2 "Hello") > if(var1 EQUAL var2) > message("They are equal") > endif() > > Guess what, it prints NOTHING despite docs explicitly saying this should work. Nothing will help, STREQUAL, MATCHES, dereferencing the arguments, whatever. This will work: > > string(COMPARE EQUAL ${var1} ${var2} _cmp) > if (_cmp) > message("They are equal") > endif() Looks cool! :P Big improvement over qmake! Writing Android/IOS/tvOS/embedded Linux/WinRT/whatever is about to get to the next level, can't wait! > Yeah, fortunately there is a wide knowledge how to work around this kind of stuff. There are MANY other things like that that will make you cry when writing even simple things in CMake's "language". Not to mention CMake is not a build system, Qbs is. Don't underestimate it, CMake is GNU m4 but better, like SVN was CVS but better. Honestly, i never switched to git, I don't need a Ferrari to go fast, you should see me on my bicycle. It even has a dynamo for the lights. Come on, haven't you see the new build instructions cmake -g Ninja cmake --build . --target install --config release Makes sense to me. Clear as mud! :) --build and --target are not to be confused with GNU autotools build/host/target, but the reader would have spotted that straight away. No need to explain '-g Ninja' (Capital N please), it makes sense to first tell your build system, what build system it needs to use. Ah yeah, BTW: "sudo cmake --build . --target install --config release". Just to make sure that your build tree will be own by root b/c CMake needs to go through the whole build phase before it dares evaluating the install phase... With CMake, you should drop your user account and log into X11R6 as root, like the good old time, it works better with auto login tho. For extra spice, try systemd's DHCP client. Chris From mitch.curtis at qt.io Tue Oct 30 08:37:24 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Tue, 30 Oct 2018 07:37:24 +0000 Subject: [Development] Serialising UI state in QML via QSettings and JSON: QByteArray vs QString In-Reply-To: References: Message-ID: > -----Original Message----- > From: Edward Welbourne > Sent: Monday, 29 October 2018 7:31 PM > To: Mitch Curtis > Cc: Qt development mailing list > Subject: Re: [Development] Serialising UI state in QML via QSettings and > JSON: QByteArray vs QString > > Mitch Curtis (29 October 2018 17:42) > > To solve #2, I first tried simply saving a QVariant containing a > > QByteArray (the contents of which were QDataStream's output). This > > didn't work because Qt's JSON implementation doesn't support > > QByteArray; it only supports QString. That is, calling > > QJsonObject::fromVariantMap(map) where "map" contains a QVariant > > containing a QByteArray will result in the corresponding JSON value > > being invalid/null. > > I'm not sure where JSON got involved in that What do you mean? It's in the title of the email; it's a popular choice for storing data like this, so I want SplitView's serialisation to be compatible with it. >but if you can manage to use > CBOR instead, it's just as happy with QByteArray as with QString (and round- > trips them to QByteArray, IIRC). For details, see > qtbase/src/corelib/serialization/qcborstream.h > > I've also no idea how well it plays with QSettings; hopefully you know enough > to work it out from the QCbor API ... Thanks, I'll take a look. > Eddy. From abbapoh at gmail.com Tue Oct 30 08:47:02 2018 From: abbapoh at gmail.com (=?koi8-r?B?6dfBziDrz83J09PB0s/X?=) Date: Tue, 30 Oct 2018 08:47:02 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: <1678597.qZIjjK9tzR@tjmaciei-mobl1> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1678597.qZIjjK9tzR@tjmaciei-mobl1> Message-ID: <6F562551-8F43-4048-860B-2C521DE1E421@gmail.com> Иван Комиссаров > 30 окт. 2018 г., в 4:34, Thiago Macieira написал(а): > >> On Monday, 29 October 2018 18:20:35 PDT NIkolai Marchenko wrote: >> Lars, I have to wonder, don't you guys miss an opportunity here? >> Qt 5 was not developed with QBS in mind. As such it probably took more >> effort than needed to fit QBS to something that was originally QMake based. >> >> At the same time you will have to fit CMake to suit the needs for Qt6. (or >> vice versa) >> >> Would it really be so much extra investment to have a build system fully >> integrated into Qt framework process that you can just make fit on the fly, >> over fiddling around the system that is overgeneralized and perhaps doesn't >> support everything as much as you'd want? > > I'm not Lars. > > But yes. > > The Qt 6 organisation won't be too different from Qt 5's, aside from the > changes that Lars and Tobias have already mentioned and that make a lot of > sense to me. So I don't see how any kind of organisation will make it easier. > > More importantly, the problem is keeping that specific buildsystem working. If > the work isn't shared and others don't pitch in, the price to pay to keep a > Qt-only buildsystem working is too high: that's what Lars' email says. > > Finally, I'm sure any reasonable request we may have on something CMake > doesn't support yet, upstream will be willing to hear us and implement where > necessary. I quite frankly don't expect there to be much, especially since > Lars' email says that they made so much progress in so little time. > >> You've said it yourself that qbs did give good results. Maybe give it a >> chance? > > It's been given a chance. The wip/qbs branch has existed for years in qtbase. > The tool has existed for years. > > Can you name any project of moderate complexity using it? > How about Qt creator? How about commercial projects? But what I would like to ask is how about porting Qt Creator to cmake first, before porting Qt? Of course, this is not as fun as porting Qt but we can _compare_ all three build tools on that project. It is huge, uses code generation so it was a good playground for qbs. Why not use it as a playground for cmake? Then we'all have _numbers_ (speed, project files size and so on) > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From vladstelmahovsky at gmail.com Tue Oct 30 08:51:44 2018 From: vladstelmahovsky at gmail.com (Vlad Stelmahovsky) Date: Tue, 30 Oct 2018 08:51:44 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: <62da9865-bdaa-b004-c763-99775e389210@gmail.com> feels like you hit the wall at full speed. disappointing :( On 10/29/18 1:17 PM, Lars Knoll wrote: > Hi all, > > As you will probably remember, there have been lively discussions around what kind of build tool to use for Qt 6 both during Qt Contributor Summits as well as on this mailing list. > > There has been a strong consent that we should move away from qmake as our build tool for Qt due to many shortcomings and the burden we have maintaining the system. > > Thiago wrote a set of relatively strict requirements for such a build tool in his mail in July. While some of the requirements had a bit of a Linux specific background, they have been a good basis. > > There have been rather lively discussions around alternatives, but most focused around two possible choices for us: Qbs and cmake. > > Qbs is something that has been developed almost exclusively by The Qt Company. As such, TQtC had to also look at it from a business perspective and how it fits into the larger picture of making Qt successful. To make a long story short, while Qbs is pretty cool and interesting technology, it doesn’t really help us expand the Qt ecosystem and usage. > > To make Qbs really successful would require a rather large effort and investment in promoting it towards the larger C++ ecosystem as a new build tool. At the same time it has to be an open source product to stand any chance in the market. Together this makes it challenging for TQtC to see how to recover that investment. Thus this investment would be at the expense of other things we’d like to do, like improving our IDE, working on rearchitecting and cleaning up our core frameworks for Qt 6 or the design tooling we are currently investing into. The Qt Company believes that those other investments are more important for the future of Qt than our choice of build tool. > > As such, we were left with the question on whether we need Qbs as the build system for Qt 6 or whether cmake (as the other alternative) would be up to the task. > > Given that background, we’ve done some more research on using both Qbs and cmake to build Qt. Both projects did give us good results but we were actually surprised on how far we got with cmake in a rather limited period of time. > > In addition, cmake has the advantage of being very widely used in the C++ ecosystem (amongst many others by KDE), has a very wide support in many IDEs and other tools (e.g. VCPkg, Conan etc.), and there’s a lot of knowledge about the build system available in the ecosystem. Using it with Qt 6 would also mean that we can focus our support on two build systems for our users (qmake and cmake) and we would not have to add a third one to the mix. > > Given that we are confident we can build Qt 6 with cmake, I believe that it makes most sense to follow down that route. In case you’re interested, you can have a look at the cmake prototype code for qtbase on Gerrit in the wip/cmake branch. Please also let us know if you’re interested in helping with the effort of porting Qt’s build system over to cmake. > > We have been developing Qbs over the last years, and as such are committed to it for some more time. We are planning on another feature release in the first quarter of next year and will support it in Qt Creator for at least another year. Qbs is open source and if someone wants to take over and develop it further let us know as well. I’d also like to use this place to thank Christian and Jörg for all their great work on Qbs (and of course also anybody else who contributed to it). > > Cheers, > Lars > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From chgans at gmail.com Tue Oct 30 08:59:15 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Tue, 30 Oct 2018 20:59:15 +1300 Subject: [Development] Build system for Qt 6 In-Reply-To: <6F562551-8F43-4048-860B-2C521DE1E421@gmail.com> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1678597.qZIjjK9tzR@tjmaciei-mobl1> <6F562551-8F43-4048-860B-2C521DE1E421@gmail.com> Message-ID: On Tue, 30 Oct 2018 at 20:47, Иван Комиссаров wrote: > Иван Комиссаров > > 30 окт. 2018 г., в 4:34, Thiago Macieira написал(а): > > Can you name any project of moderate complexity using it? > > > > How about Qt creator? How about commercial projects? > > But what I would like to ask is how about porting Qt Creator to cmake first, before porting Qt? Of course, this is not as fun as porting Qt but we can _compare_ all three build tools on that project. It is huge, uses code generation so it was a good playground for qbs. Why not use it as a playground for cmake? Then we'all have _numbers_ (speed, project files size and so on) > +1, if you cannot port QtCreator to CMake, then you have no chance to port Qt to Cmake. Both QtCreator and Qbs can be built and developed using QtCreator+Qbs. Interesting experience: port Qbs and QtCreator to CMake and let see what sort of experience it is to develop QtCreator and Qbs using QtCreator+CMake. From Ch.Ehrlicher at gmx.de Tue Oct 30 09:04:26 2018 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Tue, 30 Oct 2018 09:04:26 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181030062939.85F46F36@centrum.cz> References: <20181030062939.85F46F36@centrum.cz> Message-ID: <69e1fab2-91b2-3ed7-15f2-9c551d95422e@gmx.de> Am 30.10.2018 um 06:29 schrieb resurrection at centrum.cz: > > set(var1 "Hello") > > set(var2 "Hello") > > if(var1 EQUAL var2) > >     message("They are equal") > > endif() > > Guess what, it prints NOTHING despite docs explicitly saying this > should work. Nothig will help, STREQUAL, MATCHES, dereferencing the > arguments, whatever. > You read the docs wrong: EQUAL: True if the given string or variable’s value is a valid number and equal to that on the right. Neither var1 nor var2 is a valid numbers. You want if (var1 STREQUAL var2) and this works as expected (and documented). // Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: From resurrection at centrum.cz Tue Oct 30 09:21:02 2018 From: resurrection at centrum.cz (resurrection at centrum.cz) Date: Tue, 30 Oct 2018 09:21:02 +0100 Subject: [Development] =?utf-8?q?Build_system_for_Qt_6?= Message-ID: <20181030092102.E3EE3ACC@centrum.cz> //Christian Gagneraud wrote: // // // set(var1 "Hello") // // set(var2 "Hello") // //  // // if(var1 EQUAL var2) // //     message("They are equal") // // endif() // //  // // Guess what, it prints NOTHING despite docs explicitly saying this should work. Nothig will help, STREQUAL, MATCHES, dereferencing the arguments, whatever. //  // You read the docs wrong: // EQUAL: True if the given string or variable’s value is a valid number and equal to that on the right. // Neither var1 nor var2 is a valid numbers. //  // You want // if (var1 STREQUAL var2) and this works as expected (and documented). //  // // // Christian   No it does not. Have you tried it? As I mentioned it does not work. And even if you somehow managed to make it work it would break the moment someone would define the variable "Hello" elsewhere in the script. See https://cmake.org/pipermail/cmake/2013-February/053587.html   And that is the point. The fact we are discussing the very fundamental programming feature - control flow - that just does not work as expected (or documented) is the main problem with CMake. It is a software made of features botched together. You will be constantly running into these kinds of things because it is CMake "language" is not a standardized programming language (like JS is). Writing complex projects in it is extremely difficult which I have been unfortunate to experience first hand (had to write a few in it). While the business decision might be understandable from the technical standpoint it is an absolute nightmarish prospect. Not to mention it is very slow so working with codebase the size of Qt will be extra difficult. There will likely be effort to improve on that either on CMake side (if they cared) or QtComany side (more likely, because they do care).   However I have no problem with CMake becoming the primary build generator replacing qmake. It is widespread etc. My issue is with deprecating Qbs. Having 2 people (likely very motivated now after they spent years developing Qbs) transfered or replaced to CMake support in Qt can hardly mean "Deprecating Qbs allows us to significantly improve CMake support.". Sounds more like standard PR BS to me, sorry.   And saying Qbs got a chance when it was literally never promoted anywhere, not even in Qt project itself is riduclous. And coming from Thiago who even claimed before he never actually used it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ch.Ehrlicher at gmx.de Tue Oct 30 09:42:24 2018 From: Ch.Ehrlicher at gmx.de (Christian Ehrlicher) Date: Tue, 30 Oct 2018 09:42:24 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181030092102.E3EE3ACC@centrum.cz> References: <20181030092102.E3EE3ACC@centrum.cz> Message-ID: <83efbe7f-d9d2-ca09-b33b-c57e9f9359b6@gmx.de> Am 30.10.2018 um 09:21 schrieb resurrection at centrum.cz: > > // // set(var1 "Hello") > > // // set(var2 "Hello") > > // // > > // // if(var1 EQUAL var2) > > // //  message("They are equal") > > // // endif() > Using STREQUAL works here for me with cmake 3.12 on linux so if it does not work for you please file a bug report in the cmake bugtracker. set(var1 "Hello") set(var2 "Hello") set(var3 "Hello2") if(var1 STREQUAL var2)     message("They are equal") endif() if(NOT var1 STREQUAL var3)     message("They are *NOT* equal") endif() Christian -------------- next part -------------- An HTML attachment was scrubbed... URL: From enmarantispam at gmail.com Tue Oct 30 09:45:15 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue, 30 Oct 2018 11:45:15 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181030092102.E3EE3ACC@centrum.cz> References: <20181030092102.E3EE3ACC@centrum.cz> Message-ID: I really have to wonder how can they think QBS is a failure when it was literally never given a chance. Thiago, Lars : did you _really_ expect QBS to take off without any kind of proper documentation (has only started appearing in the last year) or advertisement? Seriously? I've pointed out this artificial entry barrier for years. It's not that QBS hasn't taken off, the people who were responsible for it to take off did not do even minimal effort to make sure it did. During the course of the last year QBS imporved in leaps in leaps and bounds and it suddenly comes to a schreeching halt now when it's really the time to push it to gain momentum.... I think you really need to revisit this topic before deprecating what could easily outclass CMAKE and the likes. On Tue, Oct 30, 2018 at 11:21 AM wrote: > //Christian Gagneraud wrote: > > // > > // // set(var1 "Hello") > > // // set(var2 "Hello") > > // // > > // // if(var1 EQUAL var2) > > // // message("They are equal") > > // // endif() > > // // > > // // Guess what, it prints NOTHING despite docs explicitly saying this > should work. Nothig will help, STREQUAL, MATCHES, dereferencing the > arguments, whatever. > > // > > // You read the docs wrong: > > // EQUAL: True if the given string or variable’s value is a valid number > and equal to that on the right. > > // Neither var1 nor var2 is a valid numbers. > > // > > // You want > > // if (var1 STREQUAL var2) and this works as expected (and documented). > > // > > // // > > // Christian > > > > No it does not. Have you tried it? As I mentioned it does not work. And > even if you somehow managed to make it work it would break the moment > someone would define the variable "Hello" elsewhere in the script. See > https://cmake.org/pipermail/cmake/2013-February/053587.html > > > > And that is the point. The fact we are discussing the very fundamental > programming feature - control flow - that just does not work as expected > (or documented) is the main problem with CMake. It is a software made of > features botched together. You will be constantly running into these kinds > of things because it is CMake "language" is not a standardized programming > language (like JS is). Writing complex projects in it is extremely > difficult which I have been unfortunate to experience first hand (had to > write a few in it). While the business decision might be understandable > from the technical standpoint it is an absolute nightmarish prospect. Not > to mention it is very slow so working with codebase the size of Qt will be > extra difficult. There will likely be effort to improve on that either on > CMake side (if they cared) or QtComany side (more likely, because they do > care). > > > > However I have no problem with CMake becoming the primary build generator > replacing qmake. It is widespread etc. My issue is with deprecating Qbs. > Having 2 people (likely very motivated now after they spent years > developing Qbs) transfered or replaced to CMake support in Qt can hardly > mean "Deprecating Qbs allows us to significantly improve CMake support.". > Sounds more like standard PR BS to me, sorry. > > > > And saying Qbs got a chance when it was literally never promoted anywhere, > not even in Qt project itself is riduclous. And coming from Thiago who even > claimed before he never actually used it. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From enmarantispam at gmail.com Tue Oct 30 09:50:58 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue, 30 Oct 2018 11:50:58 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <20181030092102.E3EE3ACC@centrum.cz> Message-ID: Main question is: why you even developing it, when you've never properly advertised/documented it? Just as an internal experiment? "Lets' make this thing and make sure almost no one knows of it or can find enough guidance to use it and then call it deprecated." Like... this makes no sense whatsoever. Part of it is me being annoyed at the loss of my primary build system ofc, but mostly I am generally baffled. On Tue, Oct 30, 2018 at 11:45 AM NIkolai Marchenko wrote: > I really have to wonder how can they think QBS is a failure when it was > literally never given a chance. > > Thiago, Lars : did you _really_ expect QBS to take off without any kind of > proper documentation (has only started appearing in the last year) or > advertisement? Seriously? > I've pointed out this artificial entry barrier for years. It's not that > QBS hasn't taken off, the people who were responsible for it to take off > did not do even minimal effort to make sure it did. > > During the course of the last year QBS imporved in leaps in leaps and > bounds and it suddenly comes to a schreeching halt now when it's really the > time to push it to gain momentum.... > > I think you really need to revisit this topic before deprecating what > could easily outclass CMAKE and the likes. > > > > On Tue, Oct 30, 2018 at 11:21 AM wrote: > >> //Christian Gagneraud wrote: >> >> // >> >> // // set(var1 "Hello") >> >> // // set(var2 "Hello") >> >> // // >> >> // // if(var1 EQUAL var2) >> >> // // message("They are equal") >> >> // // endif() >> >> // // >> >> // // Guess what, it prints NOTHING despite docs explicitly saying this >> should work. Nothig will help, STREQUAL, MATCHES, dereferencing the >> arguments, whatever. >> >> // >> >> // You read the docs wrong: >> >> // EQUAL: True if the given string or variable’s value is a valid number >> and equal to that on the right. >> >> // Neither var1 nor var2 is a valid numbers. >> >> // >> >> // You want >> >> // if (var1 STREQUAL var2) and this works as expected (and documented). >> >> // >> >> // // >> >> // Christian >> >> >> >> No it does not. Have you tried it? As I mentioned it does not work. And >> even if you somehow managed to make it work it would break the moment >> someone would define the variable "Hello" elsewhere in the script. See >> https://cmake.org/pipermail/cmake/2013-February/053587.html >> >> >> >> And that is the point. The fact we are discussing the very fundamental >> programming feature - control flow - that just does not work as expected >> (or documented) is the main problem with CMake. It is a software made of >> features botched together. You will be constantly running into these kinds >> of things because it is CMake "language" is not a standardized programming >> language (like JS is). Writing complex projects in it is extremely >> difficult which I have been unfortunate to experience first hand (had to >> write a few in it). While the business decision might be understandable >> from the technical standpoint it is an absolute nightmarish prospect. Not >> to mention it is very slow so working with codebase the size of Qt will be >> extra difficult. There will likely be effort to improve on that either on >> CMake side (if they cared) or QtComany side (more likely, because they do >> care). >> >> >> >> However I have no problem with CMake becoming the primary build generator >> replacing qmake. It is widespread etc. My issue is with deprecating Qbs. >> Having 2 people (likely very motivated now after they spent years >> developing Qbs) transfered or replaced to CMake support in Qt can hardly >> mean "Deprecating Qbs allows us to significantly improve CMake support.". >> Sounds more like standard PR BS to me, sorry. >> >> >> >> And saying Qbs got a chance when it was literally never promoted >> anywhere, not even in Qt project itself is riduclous. And coming from >> Thiago who even claimed before he never actually used it. >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From enmarantispam at gmail.com Tue Oct 30 09:55:07 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue, 30 Oct 2018 11:55:07 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <20181030092102.E3EE3ACC@centrum.cz> Message-ID: And if you want large projects using it, shouldn't you have invested time and people actually helping those large projects rewrite their build system to QBS and show them just how good it is? Any large project consists of a lot of experienced developers and every experienced developer knows that::"If i works, don't touch it". Qt needed to invest time and resources to show at least a few projects the real benefit of qbs instead of hoping someone randomly would decide to rewrite what amounts of hundreds of ours in an extremely poorly documented system. On Tue, Oct 30, 2018 at 11:50 AM NIkolai Marchenko wrote: > Main question is: why you even developing it, when you've never properly > advertised/documented it? Just as an internal experiment? > "Lets' make this thing and make sure almost no one knows of it or can find > enough guidance to use it and then call it deprecated." > > Like... this makes no sense whatsoever. > > Part of it is me being annoyed at the loss of my primary build system ofc, > but mostly I am generally baffled. > > On Tue, Oct 30, 2018 at 11:45 AM NIkolai Marchenko < > enmarantispam at gmail.com> wrote: > >> I really have to wonder how can they think QBS is a failure when it was >> literally never given a chance. >> >> Thiago, Lars : did you _really_ expect QBS to take off without any kind >> of proper documentation (has only started appearing in the last year) or >> advertisement? Seriously? >> I've pointed out this artificial entry barrier for years. It's not that >> QBS hasn't taken off, the people who were responsible for it to take off >> did not do even minimal effort to make sure it did. >> >> During the course of the last year QBS imporved in leaps in leaps and >> bounds and it suddenly comes to a schreeching halt now when it's really the >> time to push it to gain momentum.... >> >> I think you really need to revisit this topic before deprecating what >> could easily outclass CMAKE and the likes. >> >> >> >> On Tue, Oct 30, 2018 at 11:21 AM wrote: >> >>> //Christian Gagneraud wrote: >>> >>> // >>> >>> // // set(var1 "Hello") >>> >>> // // set(var2 "Hello") >>> >>> // // >>> >>> // // if(var1 EQUAL var2) >>> >>> // // message("They are equal") >>> >>> // // endif() >>> >>> // // >>> >>> // // Guess what, it prints NOTHING despite docs explicitly saying this >>> should work. Nothig will help, STREQUAL, MATCHES, dereferencing the >>> arguments, whatever. >>> >>> // >>> >>> // You read the docs wrong: >>> >>> // EQUAL: True if the given string or variable’s value is a valid number >>> and equal to that on the right. >>> >>> // Neither var1 nor var2 is a valid numbers. >>> >>> // >>> >>> // You want >>> >>> // if (var1 STREQUAL var2) and this works as expected (and documented). >>> >>> // >>> >>> // // >>> >>> // Christian >>> >>> >>> >>> No it does not. Have you tried it? As I mentioned it does not work. And >>> even if you somehow managed to make it work it would break the moment >>> someone would define the variable "Hello" elsewhere in the script. See >>> https://cmake.org/pipermail/cmake/2013-February/053587.html >>> >>> >>> >>> And that is the point. The fact we are discussing the very fundamental >>> programming feature - control flow - that just does not work as expected >>> (or documented) is the main problem with CMake. It is a software made of >>> features botched together. You will be constantly running into these kinds >>> of things because it is CMake "language" is not a standardized programming >>> language (like JS is). Writing complex projects in it is extremely >>> difficult which I have been unfortunate to experience first hand (had to >>> write a few in it). While the business decision might be understandable >>> from the technical standpoint it is an absolute nightmarish prospect. Not >>> to mention it is very slow so working with codebase the size of Qt will be >>> extra difficult. There will likely be effort to improve on that either on >>> CMake side (if they cared) or QtComany side (more likely, because they do >>> care). >>> >>> >>> >>> However I have no problem with CMake becoming the primary build >>> generator replacing qmake. It is widespread etc. My issue is with >>> deprecating Qbs. Having 2 people (likely very motivated now after they >>> spent years developing Qbs) transfered or replaced to CMake support in Qt >>> can hardly mean "Deprecating Qbs allows us to significantly improve >>> CMake support.". Sounds more like standard PR BS to me, sorry. >>> >>> >>> >>> And saying Qbs got a chance when it was literally never promoted >>> anywhere, not even in Qt project itself is riduclous. And coming from >>> Thiago who even claimed before he never actually used it. >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From enmarantispam at gmail.com Tue Oct 30 09:56:31 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue, 30 Oct 2018 11:56:31 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <20181030092102.E3EE3ACC@centrum.cz> Message-ID: That's basically how I switched ppl here at my workplace to QBS: I've rewritten their .pro files for them and they didn't look back. On Tue, Oct 30, 2018 at 11:55 AM NIkolai Marchenko wrote: > And if you want large projects using it, shouldn't you have invested time > and people actually helping those large projects rewrite their build system > to QBS and show them just how good it is? > Any large project consists of a lot of experienced developers and every > experienced developer knows that::"If i works, don't touch it". > > Qt needed to invest time and resources to show at least a few projects the > real benefit of qbs instead of hoping someone randomly would decide to > rewrite what amounts of hundreds of ours in an extremely poorly documented > system. > > On Tue, Oct 30, 2018 at 11:50 AM NIkolai Marchenko < > enmarantispam at gmail.com> wrote: > >> Main question is: why you even developing it, when you've never properly >> advertised/documented it? Just as an internal experiment? >> "Lets' make this thing and make sure almost no one knows of it or can >> find enough guidance to use it and then call it deprecated." >> >> Like... this makes no sense whatsoever. >> >> Part of it is me being annoyed at the loss of my primary build system >> ofc, but mostly I am generally baffled. >> >> On Tue, Oct 30, 2018 at 11:45 AM NIkolai Marchenko < >> enmarantispam at gmail.com> wrote: >> >>> I really have to wonder how can they think QBS is a failure when it was >>> literally never given a chance. >>> >>> Thiago, Lars : did you _really_ expect QBS to take off without any kind >>> of proper documentation (has only started appearing in the last year) or >>> advertisement? Seriously? >>> I've pointed out this artificial entry barrier for years. It's not that >>> QBS hasn't taken off, the people who were responsible for it to take off >>> did not do even minimal effort to make sure it did. >>> >>> During the course of the last year QBS imporved in leaps in leaps and >>> bounds and it suddenly comes to a schreeching halt now when it's really the >>> time to push it to gain momentum.... >>> >>> I think you really need to revisit this topic before deprecating what >>> could easily outclass CMAKE and the likes. >>> >>> >>> >>> On Tue, Oct 30, 2018 at 11:21 AM wrote: >>> >>>> //Christian Gagneraud wrote: >>>> >>>> // >>>> >>>> // // set(var1 "Hello") >>>> >>>> // // set(var2 "Hello") >>>> >>>> // // >>>> >>>> // // if(var1 EQUAL var2) >>>> >>>> // // message("They are equal") >>>> >>>> // // endif() >>>> >>>> // // >>>> >>>> // // Guess what, it prints NOTHING despite docs explicitly saying this >>>> should work. Nothig will help, STREQUAL, MATCHES, dereferencing the >>>> arguments, whatever. >>>> >>>> // >>>> >>>> // You read the docs wrong: >>>> >>>> // EQUAL: True if the given string or variable’s value is a valid >>>> number and equal to that on the right. >>>> >>>> // Neither var1 nor var2 is a valid numbers. >>>> >>>> // >>>> >>>> // You want >>>> >>>> // if (var1 STREQUAL var2) and this works as expected (and documented). >>>> >>>> // >>>> >>>> // // >>>> >>>> // Christian >>>> >>>> >>>> >>>> No it does not. Have you tried it? As I mentioned it does not work. And >>>> even if you somehow managed to make it work it would break the moment >>>> someone would define the variable "Hello" elsewhere in the script. See >>>> https://cmake.org/pipermail/cmake/2013-February/053587.html >>>> >>>> >>>> >>>> And that is the point. The fact we are discussing the very fundamental >>>> programming feature - control flow - that just does not work as expected >>>> (or documented) is the main problem with CMake. It is a software made of >>>> features botched together. You will be constantly running into these kinds >>>> of things because it is CMake "language" is not a standardized programming >>>> language (like JS is). Writing complex projects in it is extremely >>>> difficult which I have been unfortunate to experience first hand (had to >>>> write a few in it). While the business decision might be understandable >>>> from the technical standpoint it is an absolute nightmarish prospect. Not >>>> to mention it is very slow so working with codebase the size of Qt will be >>>> extra difficult. There will likely be effort to improve on that either on >>>> CMake side (if they cared) or QtComany side (more likely, because they do >>>> care). >>>> >>>> >>>> >>>> However I have no problem with CMake becoming the primary build >>>> generator replacing qmake. It is widespread etc. My issue is with >>>> deprecating Qbs. Having 2 people (likely very motivated now after they >>>> spent years developing Qbs) transfered or replaced to CMake support in Qt >>>> can hardly mean "Deprecating Qbs allows us to significantly improve >>>> CMake support.". Sounds more like standard PR BS to me, sorry. >>>> >>>> >>>> >>>> And saying Qbs got a chance when it was literally never promoted >>>> anywhere, not even in Qt project itself is riduclous. And coming from >>>> Thiago who even claimed before he never actually used it. >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Tue Oct 30 09:59:28 2018 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 30 Oct 2018 09:59:28 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181030062939.85F46F36@centrum.cz> References: <20181030062939.85F46F36@centrum.cz> Message-ID: On 10/30/18 6:29 AM, resurrection at centrum.cz wrote: > Honestly I feel very disappointed as well with this decision. I feel similarly > to others, Qbs is now being phased out so fast (half a year of development, > another half a year of maintanance after that it seems). So better get to > porting stuff to CMake right away. Having experience with CMake this is gonna > be very ugly... > > What I do not understand is why the decision was qmake + cmake in the first > place. Why not Qbs + CMake? Was not the qmake deemed unmaintainable? It is > perfectly understandable to tap into wide CMake user base but why ditching Qbs > and not qmake? I wouldn't expect people would mourn qmake... This is not about "qmake + cmake" vs. anything. Qbs did not disappear from one day to the other. What Lars said, if I read the email properly, is that the Qt Company does not see a business value in developing it further. But the project is open source and the code is there and anyone is free to take over if they are interested in it. It's exactly the same for qmake, which was already in just maintenance mode, and hasn't gotten new feature for a long time and will not get any. Just continue to work as is. And Qbs does not have to build Qt for you to use it. > Oh and on the point of CMake. Lets write a simple if statement as per docs: > > set(var1 "Hello") > set(var2 "Hello") > if(var1 EQUAL var2) >     message("They are equal") > endif() > > Guess what, it prints NOTHING despite docs explicitly saying this should work. > Nothig will help, STREQUAL, MATCHES, dereferencing the arguments, whatever. Well don't use C++ then. char var1[] = "Hello"; char var2[] = "Hello"; if (var1 == var2) puts("They are equal"); Guess what, it prints NOTHING. My point is that you should not trash the whole language just because of a few tricks. Every languages (including JS used by Qbs) has its small drawback. And there are more documentation and example of script using cmake out there than both qmake and qbs together. Nobody is forcing you to use cmake if you don't like it. (Unless you want to contribute to Qt.) There are plenty of other build system out there that can be used to build your C++ application using the Qt library. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From chgans at gmail.com Tue Oct 30 10:00:18 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Tue, 30 Oct 2018 22:00:18 +1300 Subject: [Development] Build system for Qt 6 In-Reply-To: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: On Tue, 30 Oct 2018 at 01:17, Lars Knoll wrote: > > Hi all, Hi Lars, Playing the devil's advocate here. May I ask: Which democratic/meritocratic process was used to take this decision? I do understand that the QtC is the Qbs instigator/maintainer, so nobody can blame you for pulling the plug off and adjusting resources allocation. Who/when/where was the decision of switching to CMake taken? Any trace record? A vote, a ballot, something? I havent's hear of any "Qt Project" event/announcement recently. So far i've seen some broad (but useful) un-authoritative requirements from Thiago, followed by a lengthy (endless) discussion, and suddenly your email that seems to announce the result of the "election". When did the election happened? So some claims that build systems are no "The Qt Company" business, yet you're about to take the road of having to bend a dinosaur (CMake, that's a personal opinion) to suit your modern requirements. Are you planning to have Qt employees fix CMake? Then why spend energy/money to fix something that is broken by design? (Again, that is a personal opinion, if needed to say) No conspiracy here, but i have a few more questions (not related, in no particular order) - Did Jake left the QtC due to your early decision to drop qbs? ( I personally do think that the decision was taken long time ago) - Did you drop Qbs due to it's "unsolvable" dependency on deprecated Qt Script? - Any track record that Qbs was not fit for the job? (Please no "we can't build Qt with it", as you cannot build Qt with anything but qmake right now) Sincerely, Chris From abbapoh at gmail.com Tue Oct 30 10:00:50 2018 From: abbapoh at gmail.com (=?koi8-r?B?6dfBziDrz83J09PB0s/X?=) Date: Tue, 30 Oct 2018 10:00:50 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <20181030092102.E3EE3ACC@centrum.cz> Message-ID: <38E7229D-3EF4-41C8-B47D-A7E381D79719@gmail.com> You have one year (or 2 Qt creator releases) to rewrite everything again=) 3, 2, 1, go! Иван Комиссаров > 30 окт. 2018 г., в 9:56, NIkolai Marchenko написал(а): > > That's basically how I switched ppl here at my workplace to QBS: I've rewritten their .pro files for them and they didn't look back. > >> On Tue, Oct 30, 2018 at 11:55 AM NIkolai Marchenko wrote: >> And if you want large projects using it, shouldn't you have invested time and people actually helping those large projects rewrite their build system to QBS and show them just how good it is? >> Any large project consists of a lot of experienced developers and every experienced developer knows that::"If i works, don't touch it". >> >> Qt needed to invest time and resources to show at least a few projects the real benefit of qbs instead of hoping someone randomly would decide to rewrite what amounts of hundreds of ours in an extremely poorly documented system. >> >>> On Tue, Oct 30, 2018 at 11:50 AM NIkolai Marchenko wrote: >>> Main question is: why you even developing it, when you've never properly advertised/documented it? Just as an internal experiment? >>> "Lets' make this thing and make sure almost no one knows of it or can find enough guidance to use it and then call it deprecated." >>> >>> Like... this makes no sense whatsoever. >>> >>> Part of it is me being annoyed at the loss of my primary build system ofc, but mostly I am generally baffled. >>> >>>> On Tue, Oct 30, 2018 at 11:45 AM NIkolai Marchenko wrote: >>>> I really have to wonder how can they think QBS is a failure when it was literally never given a chance. >>>> >>>> Thiago, Lars : did you _really_ expect QBS to take off without any kind of proper documentation (has only started appearing in the last year) or advertisement? Seriously? >>>> I've pointed out this artificial entry barrier for years. It's not that QBS hasn't taken off, the people who were responsible for it to take off did not do even minimal effort to make sure it did. >>>> >>>> During the course of the last year QBS imporved in leaps in leaps and bounds and it suddenly comes to a schreeching halt now when it's really the time to push it to gain momentum.... >>>> >>>> I think you really need to revisit this topic before deprecating what could easily outclass CMAKE and the likes. >>>> >>>> >>>> >>>>> On Tue, Oct 30, 2018 at 11:21 AM wrote: >>>>> //Christian Gagneraud wrote: >>>>> // >>>>> // // set(var1 "Hello") >>>>> // // set(var2 "Hello") >>>>> // // >>>>> // // if(var1 EQUAL var2) >>>>> // // message("They are equal") >>>>> // // endif() >>>>> // // >>>>> // // Guess what, it prints NOTHING despite docs explicitly saying this should work. Nothig will help, STREQUAL, MATCHES, dereferencing the arguments, whatever. >>>>> // >>>>> // You read the docs wrong: >>>>> // EQUAL: True if the given string or variable’s value is a valid number and equal to that on the right. >>>>> // Neither var1 nor var2 is a valid numbers. >>>>> // >>>>> // You want >>>>> // if (var1 STREQUAL var2) and this works as expected (and documented). >>>>> // >>>>> // // >>>>> // Christian >>>>> >>>>> No it does not. Have you tried it? As I mentioned it does not work. And even if you somehow managed to make it work it would break the moment someone would define the variable "Hello" elsewhere in the script. See https://cmake.org/pipermail/cmake/2013-February/053587.html >>>>> >>>>> And that is the point. The fact we are discussing the very fundamental programming feature - control flow - that just does not work as expected (or documented) is the main problem with CMake. It is a software made of features botched together. You will be constantly running into these kinds of things because it is CMake "language" is not a standardized programming language (like JS is). Writing complex projects in it is extremely difficult which I have been unfortunate to experience first hand (had to write a few in it). While the business decision might be understandable from the technical standpoint it is an absolute nightmarish prospect. Not to mention it is very slow so working with codebase the size of Qt will be extra difficult. There will likely be effort to improve on that either on CMake side (if they cared) or QtComany side (more likely, because they do care). >>>>> >>>>> However I have no problem with CMake becoming the primary build generator replacing qmake. It is widespread etc. My issue is with deprecating Qbs. Having 2 people (likely very motivated now after they spent years developing Qbs) transfered or replaced to CMake support in Qt can hardly mean "Deprecating Qbs allows us to significantly improve CMake support.". Sounds more like standard PR BS to me, sorry. >>>>> >>>>> And saying Qbs got a chance when it was literally never promoted anywhere, not even in Qt project itself is riduclous. And coming from Thiago who even claimed before he never actually used it. >>>>> _______________________________________________ >>>>> Development mailing list >>>>> Development at qt-project.org >>>>> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at weickelt.de Tue Oct 30 10:08:27 2018 From: richard at weickelt.de (Richard Weickelt) Date: Tue, 30 Oct 2018 10:08:27 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: > Qbs is something that has been developed almost exclusively by The Qt > Company. As such, TQtC had to also look at it from a business perspective > and how it fits into the larger picture of making Qt successful. To make > a long story short, while Qbs is pretty cool and interesting technology, > it doesn’t really help us expand the Qt ecosystem and usage. Qbs has made the development of multi-platform applications with multiple libraries a breeze for me. Even projects that contain firmware for different target architectures in addition to a Qt application are no problem at all with Qbs. Thanks to Qbs, I can focus on code and not on the build system. I achieve more in less time. I always thought that Qbs was a great example for using QML. > To make Qbs really successful would require a rather large effort and > investment in promoting it towards the larger C++ ecosystem as a new > build tool. At the same time it has to be an open source product to stand > any chance in the market. Together this makes it challenging for TQtC to > see how to recover that investment. Thus this investment would be at the > expense of other things we’d like to do, like improving our IDE, working > on rearchitecting and cleaning up our core frameworks for Qt 6 or the > design tooling we are currently investing into. The Qt Company believes > that those other investments are more important for the future of Qt than > our choice of build tool. It seems that Qbs never got much traction within the Qt Company either. Outside the regular blog posts, I don't see any attempt to promote Qbs anywhere. Correct me if I'm wrong. I may have noticed that Jake Petroules did his best to get the word out, but I guess that was his private mission rather than his official role in the Qt Company. What I can't complain about is the unprecedented dedication and professionalism of Christian, Jörg and Jake on this project. Also all support questions were answered in lightning speed. > As such, we were left with the question on whether we need Qbs as the > build system for Qt 6 or whether cmake (as the other alternative) would > be up to the task. > [..] > Given that we are confident we can build Qt 6 with cmake, I believe that > it makes most sense to follow down that route. In case you’re interested, > you can have a look at the cmake prototype code for qtbase on Gerrit in > the wip/cmake branch. Please also let us know if you’re interested in > helping with the effort of porting Qt’s build system over to cmake. > > We have been developing Qbs over the last years, and as such are > committed to it for some more time. We are planning on another feature > release in the first quarter of next year and will support it in Qt > Creator for at least another year. Qbs is open source and if someone > wants to take over and develop it further let us know as well. I’d also > like to use this place to thank Christian and Jörg for all their great > work on Qbs (and of course also anybody else who contributed to it). How can we leverage from the next half year to smoothly turn Qbs into a community-owned OS project? Does anybody know a positive role-model for this? I don't want to miss out on the productivity gains I've made with Qbs, but on the other hand I have very little free time. However, I would voluntarily contribute to the documentation of Qbs. Richard From chgans at gmail.com Tue Oct 30 10:26:33 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Tue, 30 Oct 2018 22:26:33 +1300 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: On Tue, 30 Oct 2018 at 22:18, Richard Weickelt wrote: > > Ich schick's doch nicht an die Liste, ist wenig konstruktiv :-/ > > No conspiracy here, but i have a few more questions (not related, in > > no particular order) > > - Did Jake left the QtC due to your early decision to drop qbs? ( I > > personally do think that the decision was taken long time ago) > > - Did you drop Qbs due to it's "unsolvable" dependency on deprecated Qt Script? > > - Any track record that Qbs was not fit for the job? (Please no "we > > can't build Qt with it", as you cannot build Qt with anything but > > qmake right now) > > Do You remember Tino Pyssysalo's ominous survey on the qbs mailing list in > June? I asked him explicitly for more transparency about the decision-making > process about the future of Qbs. Apart from a vague promise, I heard nothing > back. ,https://lists.qt-project.org/mailman/listinfo/qbs gives me: Secure Connection Failed An error occurred during a connection to lists.qt-project.org. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG As reported on qt-interest recently, lists.qt-project.org is serving plain HTTP over port 443. Chris From jeanmichael.celerier at gmail.com Tue Oct 30 10:41:17 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Tue, 30 Oct 2018 10:41:17 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: Hi all, I'd like to point you to a mailing list message of Brad King from a few months ago about alternative languages for CMake : https://cmake.org/pipermail/cmake-developers/2016-January/027379.html (damn, two years actually.. time flies) > In summary, I think work in this direction should first focus on designing a declarative (or functional) specification format where most of the project information can be specified. Then a cmake-language command can be written to load and evaluate a specification file (as a transition). Finally we could look at replacing the entry-point language with something else. At that point we could have closures passed as parameters to the evaluation of the pure spec in order to get custom generate-time logic. Brad for those who don't know is one of the main (dare I say *the* main) CMake contributors (https://www.kitware.com/brad-king/). So, why not just go and propose the declarative QBS syntax as a front-end for CMake ? This would make the world a better place. The CMake people *want* a better language, and for these use cases, QML is certainly much closer to the solution than others. ------- Jean-Michaël Celerier http://www.jcelerier.name On Tue, Oct 30, 2018 at 10:26 AM Christian Gagneraud wrote: > On Tue, 30 Oct 2018 at 22:18, Richard Weickelt > wrote: > > > > Ich schick's doch nicht an die Liste, ist wenig konstruktiv :-/ > > > No conspiracy here, but i have a few more questions (not related, in > > > no particular order) > > > - Did Jake left the QtC due to your early decision to drop qbs? ( I > > > personally do think that the decision was taken long time ago) > > > - Did you drop Qbs due to it's "unsolvable" dependency on deprecated > Qt Script? > > > - Any track record that Qbs was not fit for the job? (Please no "we > > > can't build Qt with it", as you cannot build Qt with anything but > > > qmake right now) > > > > Do You remember Tino Pyssysalo's ominous survey on the qbs mailing list > in > > June? I asked him explicitly for more transparency about the > decision-making > > process about the future of Qbs. Apart from a vague promise, I heard > nothing > > back. > > ,https://lists.qt-project.org/mailman/listinfo/qbs gives me: > Secure Connection Failed > An error occurred during a connection to lists.qt-project.org. SSL > received a record that exceeded the maximum permissible length. Error > code: SSL_ERROR_RX_RECORD_TOO_LONG > > As reported on qt-interest recently, lists.qt-project.org is serving > plain HTTP over port 443. > > Chris > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at weickelt.de Tue Oct 30 10:43:16 2018 From: richard at weickelt.de (Richard Weickelt) Date: Tue, 30 Oct 2018 10:43:16 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: <1678597.qZIjjK9tzR@tjmaciei-mobl1> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1678597.qZIjjK9tzR@tjmaciei-mobl1> Message-ID: > Can you name any project of moderate complexity using it? https://github.com/bjorn/tiled From jani.heikkinen at qt.io Tue Oct 30 10:46:27 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 30 Oct 2018 09:46:27 +0000 Subject: [Development] HEADS-UP: Branching from '5.12' to '5.12.0' done In-Reply-To: References: , Message-ID: Hi, Final downmerge is now completed in every submodule. If there is some open changes in '5.12' which needs to be in Qt 5.12.0 you need to retarget those in '5.12.0' instead. And staging in '5.12.0' is also restricted to release team only. Please do not try to put any nice-to-haves in '5.12.0' anymore! I (/we) will continuously monitor changes having '+2' and stage clear ones in. But if we think change isn't critical enough for Qt 5.12.0 anymore we well ask more information instead. br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Tuesday, October 30, 2018 7:10 AM To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Development] HEADS-UP: Branching from '5.12' to '5.12.0' (almost) done Hi all, Final downmerge from '5.12' to '5.12.0' is mostly done; only qtbase and qtdeclarative is still ongoing. So from now on all changes targeted to Qt 5.12.0 release needs to be done in '5.12.0' and '5.12' is for Qt 5.12.1 release. br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Monday, October 22, 2018 6:45 PM To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Development] HEADS-UP: Branching from '5.12' to '5.12.0' started Hi, We have soft branched '5.12.0' from '5.12'. Please start using '5.12.0' for new changes targeted to Qt 5.12.0 release. Final downmerge from '5.12' to '5.12.0' will happen Mon 29th October so there should be enough time to finalize ongoing changes in '5.12' and start using '5.12.0'. Target is to release Qt 5.12.0 RC mid November so it is time to fix remaining blockers from blocker list (https://bugreports.qt.io/issues/?filter=19961) BR, Jani _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From enmarantispam at gmail.com Tue Oct 30 10:47:55 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue, 30 Oct 2018 12:47:55 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1678597.qZIjjK9tzR@tjmaciei-mobl1> Message-ID: Actually, what is considered moderate complexity? I have a project at work that has been running for a few years, has 4 people working on it and has a few thousand commits. It has a couple dozen libraries, is integrated with gRPC and has code generated with protobuf on build via a custom QBS module. Is this considered moderate complexity? (though I siuspect Lars wants a bigger project) On Tue, Oct 30, 2018 at 12:43 PM Richard Weickelt wrote: > > Can you name any project of moderate complexity using it? > > https://github.com/bjorn/tiled > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Tue Oct 30 10:50:17 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Tue, 30 Oct 2018 12:50:17 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: Hi all, my personal things: Welcome to the era of stagnation and dinosaurs. The new "revolutioning" Qt6 will be released semi-dead. It will be overgrowned with mold, moss and fungi in the form of CMake. This will not be a new life, but it will be an attempt to prolong the convulsions. A real new life could give the QBS, that pushed be a new branch of the spiral of development. It would stimulate be the QBS integration with others IDE and etc. PS: I don't know, what is it: or an "effective management" or an "evil intent" or an "CMake lobby", or "not enough money". Perhaps the thesis that "Millions of flies cannot be mistaken when they choose shit" works here. Anyway, RIP QBS, You were a great friend, I never forget you. I drink Vodka and grieve about the innocently murdered projects for the sake of conjuncture. == R I P, QBS == IMHO, :( вт, 30 окт. 2018 г. в 12:08, Richard Weickelt : > > > Qbs is something that has been developed almost exclusively by The Qt > > Company. As such, TQtC had to also look at it from a business perspective > > and how it fits into the larger picture of making Qt successful. To make > > a long story short, while Qbs is pretty cool and interesting technology, > > it doesn’t really help us expand the Qt ecosystem and usage. > > Qbs has made the development of multi-platform applications with multiple > libraries a breeze for me. Even projects that contain firmware for > different > target architectures in addition to a Qt application are no problem at all > with Qbs. Thanks to Qbs, I can focus on code and not on the build system. I > achieve more in less time. > > I always thought that Qbs was a great example for using QML. > > > To make Qbs really successful would require a rather large effort and > > investment in promoting it towards the larger C++ ecosystem as a new > > build tool. At the same time it has to be an open source product to stand > > any chance in the market. Together this makes it challenging for TQtC to > > see how to recover that investment. Thus this investment would be at the > > expense of other things we’d like to do, like improving our IDE, working > > on rearchitecting and cleaning up our core frameworks for Qt 6 or the > > design tooling we are currently investing into. The Qt Company believes > > that those other investments are more important for the future of Qt than > > our choice of build tool. > > It seems that Qbs never got much traction within the Qt Company either. > Outside the regular blog posts, I don't see any attempt to promote Qbs > anywhere. Correct me if I'm wrong. I may have noticed that Jake Petroules > did his best to get the word out, but I guess that was his private mission > rather than his official role in the Qt Company. What I can't complain > about > is the unprecedented dedication and professionalism of Christian, Jörg and > Jake on this project. Also all support questions were answered in lightning > speed. > > > As such, we were left with the question on whether we need Qbs as the > > build system for Qt 6 or whether cmake (as the other alternative) would > > be up to the task. > > [..] > > Given that we are confident we can build Qt 6 with cmake, I believe that > > it makes most sense to follow down that route. In case you’re interested, > > you can have a look at the cmake prototype code for qtbase on Gerrit in > > the wip/cmake branch. Please also let us know if you’re interested in > > helping with the effort of porting Qt’s build system over to cmake. > > > > We have been developing Qbs over the last years, and as such are > > committed to it for some more time. We are planning on another feature > > release in the first quarter of next year and will support it in Qt > > Creator for at least another year. Qbs is open source and if someone > > wants to take over and develop it further let us know as well. I’d also > > like to use this place to thank Christian and Jörg for all their great > > work on Qbs (and of course also anybody else who contributed to it). > > How can we leverage from the next half year to smoothly turn Qbs into a > community-owned OS project? Does anybody know a positive role-model for > this? > > I don't want to miss out on the productivity gains I've made with Qbs, but > on the other hand I have very little free time. However, I would > voluntarily > contribute to the documentation of Qbs. > > Richard > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chgans at gmail.com Tue Oct 30 10:55:33 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Tue, 30 Oct 2018 22:55:33 +1300 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: On Tue, 30 Oct 2018 at 22:50, Denis Shienkov wrote: > == R I P, QBS == Please stop these "RIP", you're cautioning a burial ceremony that is just pure speculation so far. "CMake will fail" (tm) [another burial ceremony that is just pure speculation so far] Chris From pierluigi.fiorini at gmail.com Tue Oct 30 11:06:21 2018 From: pierluigi.fiorini at gmail.com (Pier Luigi Fiorini) Date: Tue, 30 Oct 2018 11:06:21 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <20181030062939.85F46F36@centrum.cz> Message-ID: Il giorno mar 30 ott 2018 alle ore 09:59 Olivier Goffart ha scritto: > On 10/30/18 6:29 AM, resurrection at centrum.cz wrote: > > Honestly I feel very disappointed as well with this decision. I feel > similarly > > to others, Qbs is now being phased out so fast (half a year of > development, > > another half a year of maintanance after that it seems). So better get > to > > porting stuff to CMake right away. Having experience with CMake this is > gonna > > be very ugly... > > > > What I do not understand is why the decision was qmake + cmake in the > first > > place. Why not Qbs + CMake? Was not the qmake deemed unmaintainable? It > is > > perfectly understandable to tap into wide CMake user base but why > ditching Qbs > > and not qmake? I wouldn't expect people would mourn qmake... > > This is not about "qmake + cmake" vs. anything. > > Qbs did not disappear from one day to the other. > What Lars said, if I read the email properly, is that the Qt Company does > not > see a business value in developing it further. > But the project is open source and the code is there and anyone is free to > take > over if they are interested in it. > We all know that without company support, the project will stagnate. > And Qbs does not have to build Qt for you to use it. > No but it would have been a great indicator of confidence on the project and help its adoption because it would have been much more noticeable than QtCreator (not all Qt users and developers build QtCreator but a lot of them do build Qt). The main problem here is not that Qt will use CMake, the problem is that Qbs will no longer be maintained. Given that qmake is not suitable for large projects, Qbs will not be developed anymore we can expect only CMake support on QtCreator to improve, therefore a lot of us will need to migrate to CMake. -- https://liri.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From enmarantispam at gmail.com Tue Oct 30 11:17:25 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue, 30 Oct 2018 13:17:25 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <20181030062939.85F46F36@centrum.cz> Message-ID: I would like to point out that until very, and I mean *very* recently QBS' did not even have a bunch of tutorial pages, There was a (poorly documented) reference and that was it. If someone wanted to learn QBS and there was no one in their company already familiar with it, it was one very basic qmake porting tutorial and then the only source ppl had was asking on IRC. Like... what did you expect when all the time was spent developing it but largely ignoring documentaton that would let ppl actually use it with any kind of success? On Tue, Oct 30, 2018 at 1:07 PM Pier Luigi Fiorini < pierluigi.fiorini at gmail.com> wrote: > Il giorno mar 30 ott 2018 alle ore 09:59 Olivier Goffart < > olivier at woboq.com> ha scritto: > >> On 10/30/18 6:29 AM, resurrection at centrum.cz wrote: >> > Honestly I feel very disappointed as well with this decision. I feel >> similarly >> > to others, Qbs is now being phased out so fast (half a year of >> development, >> > another half a year of maintanance after that it seems). So better get >> to >> > porting stuff to CMake right away. Having experience with CMake this is >> gonna >> > be very ugly... >> > >> > What I do not understand is why the decision was qmake + cmake in the >> first >> > place. Why not Qbs + CMake? Was not the qmake deemed unmaintainable? It >> is >> > perfectly understandable to tap into wide CMake user base but why >> ditching Qbs >> > and not qmake? I wouldn't expect people would mourn qmake... >> >> This is not about "qmake + cmake" vs. anything. >> >> Qbs did not disappear from one day to the other. >> What Lars said, if I read the email properly, is that the Qt Company does >> not >> see a business value in developing it further. >> But the project is open source and the code is there and anyone is free >> to take >> over if they are interested in it. >> > > We all know that without company support, the project will stagnate. > > >> And Qbs does not have to build Qt for you to use it. >> > > No but it would have been a great indicator of confidence on the project > and help its adoption because it would have been much more noticeable than > QtCreator (not all Qt users and developers build QtCreator but a lot of > them do build Qt). > The main problem here is not that Qt will use CMake, the problem is that > Qbs will no longer be maintained. > Given that qmake is not suitable for large projects, Qbs will not be > developed anymore we can expect only CMake support on QtCreator to improve, > therefore a lot of us will need to migrate to CMake. > > -- > https://liri.io > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Uwe.Rathmann at tigertal.de Tue Oct 30 11:18:48 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Tue, 30 Oct 2018 10:18:48 +0000 (UTC) Subject: [Development] Build system for Qt 6 References: <20181030062939.85F46F36@centrum.cz> Message-ID: On Tue, 30 Oct 2018 09:59:28 +0100, Olivier Goffart wrote: > What Lars said, if I read the email properly, is that the Qt Company > does not see a business value in developing it further. Yes and this is relevant if it is relevant for the maintainers of Qbs. Do we have a statement from them so far ? > But the project is open source and the code is there and anyone is free > to take over if they are interested in it. In case a maintainer decides to step down the normal process would be to find a new one. Only if this is not possible further steps have to be taken. Using Qbs for building Qt has been discussed here and lead to a solid decision against it. Obviously then the Qt company decided not to work on this code anymore - so far so good. But deprecating Qbs as a tool for building user projects is absolutely not covered by this discussion and if there was a more related one I seem to have missed it. This all has a lot to do with the question if the Qt Company sees itself as being a member or the owner of the Qt project. If we really want to be a community project, then the process of inventing and deprecating modules has to become more independent. Uwe From enmarantispam at gmail.com Tue Oct 30 11:25:54 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue, 30 Oct 2018 13:25:54 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <20181030062939.85F46F36@centrum.cz> Message-ID: > Yes and this is relevant if it is relevant for the maintainers of Qbs. Do we have a statement from them so far ? We have a confirmation from Lars that QtCreator is dropping qbs support in a year. That basically reads "qbs dead as there will be no IDE supporting it left". On Tue, Oct 30, 2018 at 1:21 PM Uwe Rathmann wrote: > On Tue, 30 Oct 2018 09:59:28 +0100, Olivier Goffart wrote: > > > What Lars said, if I read the email properly, is that the Qt Company > > does not see a business value in developing it further. > > Yes and this is relevant if it is relevant for the maintainers of Qbs. Do > we have a statement from them so far ? > > > But the project is open source and the code is there and anyone is free > > to take over if they are interested in it. > > In case a maintainer decides to step down the normal process would be to > find a new one. Only if this is not possible further steps have to be > taken. > > Using Qbs for building Qt has been discussed here and lead to a solid > decision against it. Obviously then the Qt company decided not to work on > this code anymore - so far so good. > > But deprecating Qbs as a tool for building user projects is absolutely > not covered by this discussion and if there was a more related one I seem > to have missed it. > > This all has a lot to do with the question if the Qt Company sees itself > as being a member or the owner of the Qt project. If we really want to be > a community project, then the process of inventing and deprecating > modules has to become more independent. > > Uwe > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Tue Oct 30 11:27:10 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 30 Oct 2018 10:27:10 +0000 Subject: [Development] QUIP 12: Code of Conduct In-Reply-To: <20181029201853.GA2391@klara.mpi.htwm.de> References: <2459e491-0a1d-d0a1-7e54-8ce3e1127c79@qt.io> <1613934.u2FelxWX76@tjmaciei-mobl1> <9043feb7-dc9a-bbdc-d52f-19add7492825@qt.io>, <20181029201853.GA2391@klara.mpi.htwm.de> Message-ID: On Mon, Oct 29, 2018 at 02:25:20PM +0000, Ulf Hermann wrote: >> All the proposals for codes of conduct that I have seen so far mention >> banning only as a last resort and have several less drastic measures >> that should be applied before. André Pönitz (29 October 2018 21:18) came back with > That's exactly the way the Project has operated before, without the > suggested burocratic overhead and without giving some committee > super-powers ranking over all other mechanisms in the project. Which indeed means we currently have a process, at least where there is some form of moderation (the forum, the wiki) or admin group (IRC); and I would argue this mailing list effectively is moderated, since various well-established participants would step in and call someone out if their conduct was out of line. If we are satisfied with that process, then all we need is a CoC, to give folk clarity as to what conduct they can expect to be handled how sternly. The CoC might indeed explicitly say that the way it'll be "enforced" is by relevant admins acting reasonably - in which case it's probably best to spell out that we *do* expect our admins and moderators to act *within* the CoC *even* when dealing with infractions. > Sure, each time when action has to be taken on IRC or by mailing > list moderation, people taking that decision feel somewhat uneasy, > lest they be accused of censorship or similar. But that is *good*, > as it makes people exercise any extra powers very consciously. That's *mostly* good; but beware of the Dunning-Kruger effect. The sorts of folk who abuse authority are exactly the ones least likely to question their own use of it. So we do need to take care, in selecting who shall have Powers, to select those who show restraint precisely because they *do* question their own authority and the aptness of their use of it. If nothing else, it's a good idea to have some level of process, even if only informally among the admins and moderators, where one does not take certain actions (bans, blocks, &c.) without consulting with the other admins and moderators - "my dear peers, I'm considering banning that chap, for [reasons], but just want to sanity-check that I'm not over-reacting" - unless there is some life-threatening urgency involved (in which case I imagine we'll also be carefully retaining records, to hand over to Proper Authorities outside the project, as part of anticipated court proceedings). >> Also, the point of having a neutral third party decide on the issue, >> rather than people directly involved in the conflict should result in >> that third party deciding on the measurements to be taken, not any >> victims of harassment, harm, or whatever. So, to boil down Andre's point: to what extent are the existing moderators and admins not already a suitable neutral third party ? I trust we have several in each context, so that others can serve as neutral third party when someone's complaining against one of them. Eddy. From edward.welbourne at qt.io Tue Oct 30 11:36:47 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 30 Oct 2018 10:36:47 +0000 Subject: [Development] Serialising UI state in QML via QSettings and JSON: QByteArray vs QString In-Reply-To: References: , Message-ID: Edward Welbourne (Monday, 29 October 2018 7:31 PM) wrote >> I'm not sure where JSON got involved in that Mitch Curtis (30 October 2018 08:37) replied > What do you mean? It's in the title of the email; it's a popular > choice for storing data like this, so I want SplitView's serialisation > to be compatible with it. Perhaps I need to rephrase: to what extent is the choice of JSON, in the present discussion, necessary or incidental ? If what you're trying to do has to use JSON with QSettings, then it's necessary. If JSON just looked, at first sight, like it would solve your primary problem, then it's incidental and can be replaced by something compatible. Eddy. From abbapoh at gmail.com Tue Oct 30 11:42:12 2018 From: abbapoh at gmail.com (=?koi8-r?B?6dfBziDrz83J09PB0s/X?=) Date: Tue, 30 Oct 2018 11:42:12 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <20181030062939.85F46F36@centrum.cz> Message-ID: I guess, VS still will support QBS in case VS generator is working. Unfortunately, Xcode generator doesn't, I checked recently. Иван Комиссаров > 30 окт. 2018 г., в 11:25, NIkolai Marchenko написал(а): > > > Yes and this is relevant if it is relevant for the maintainers of Qbs. Do > we have a statement from them so far ? > > We have a confirmation from Lars that QtCreator is dropping qbs support in a year. > That basically reads "qbs dead as there will be no IDE supporting it left". > >> On Tue, Oct 30, 2018 at 1:21 PM Uwe Rathmann wrote: >> On Tue, 30 Oct 2018 09:59:28 +0100, Olivier Goffart wrote: >> >> > What Lars said, if I read the email properly, is that the Qt Company >> > does not see a business value in developing it further. >> >> Yes and this is relevant if it is relevant for the maintainers of Qbs. Do >> we have a statement from them so far ? >> >> > But the project is open source and the code is there and anyone is free >> > to take over if they are interested in it. >> >> In case a maintainer decides to step down the normal process would be to >> find a new one. Only if this is not possible further steps have to be >> taken. >> >> Using Qbs for building Qt has been discussed here and lead to a solid >> decision against it. Obviously then the Qt company decided not to work on >> this code anymore - so far so good. >> >> But deprecating Qbs as a tool for building user projects is absolutely >> not covered by this discussion and if there was a more related one I seem >> to have missed it. >> >> This all has a lot to do with the question if the Qt Company sees itself >> as being a member or the owner of the Qt project. If we really want to be >> a community project, then the process of inventing and deprecating >> modules has to become more independent. >> >> Uwe >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Tue Oct 30 11:42:13 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 30 Oct 2018 10:42:13 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: Hi Christian, > On 30 Oct 2018, at 05:00, Christian Gagneraud wrote: > > On Tue, 30 Oct 2018 at 01:17, Lars Knoll wrote: >> >> Hi all, > > Hi Lars, > > Playing the devil's advocate here. > > May I ask: Which democratic/meritocratic process was used to take > this decision? > I do understand that the QtC is the Qbs instigator/maintainer, so > nobody can blame you for pulling the plug off and adjusting resources > allocation. > > Who/when/where was the decision of switching to CMake taken? > Any trace record? A vote, a ballot, something? I havent's hear of any > "Qt Project" event/announcement recently. > So far i've seen some broad (but useful) un-authoritative requirements > from Thiago, > followed by a lengthy (endless) discussion, and suddenly your email > that seems to announce the result of the "election". > When did the election happened? > > So some claims that build systems are no "The Qt Company" business, > yet you're about to take the road of having to bend a dinosaur (CMake, > that's a personal opinion) to suit your modern requirements. > Are you planning to have Qt employees fix CMake? > > Then why spend energy/money to fix something that is broken by design? > (Again, that is a personal opinion, if needed to say) As I said in my email, I unfortunately don’t see a way how The Qt Company can push Qbs forward. It was a difficult decision because I very much like the ideas and the technology used in Qbs. From the perspective of a company, we have to justify investments we do, and they have to make sense not only from a perspective of being cool technology, but also how they can in the end generate business for us. In addition, there’s always the question, what we then can’t do (because the total money we can invest in R&D is limited). Looking at the fact, that we can’t earn money on a build system and that it would require quite a lot of funding to make it more than a niche product it doesn’t make sense to pursue it further. Instead we would rather use the money to improve Qt and Qt Creator. We had consensus amongst the maintainers that we want to move away from qmake, the two options being Qbs and CMake. Using CMake to build Qt is then a mostly pragmatic move. With it we don’t need to maintain the build tool ourselves, and we use a tool that already has wide support for most of what we need. This is then about minimising our work maintaining a system to build Qt itself. And the wip/cmake branch shows that this can be done without having ’to bend a dinosaur’. > > No conspiracy here, but i have a few more questions (not related, in > no particular order) > - Did Jake left the QtC due to your early decision to drop qbs? ( I > personally do think that the decision was taken long time ago) The decision to not continue to develop Qbs was done very recently. It doesn’t make sense to make a decision and then not take actions. Whatever the reasons Jake left, they have nothing to do with this. > - Did you drop Qbs due to it's "unsolvable" dependency on deprecated Qt Script? Huh? There’s no such thing as an ‘unsolvable’ dependency here. But of course any changes to a product involve work. More for some things, less for others. > - Any track record that Qbs was not fit for the job? (Please no "we > can't build Qt with it", as you cannot build Qt with anything but > qmake right now) No, of course one could have made it support building Qt. There were some missing items like the configuration system and some other things, all of those could of course have been implemented. Cheers, Lars From lars.knoll at qt.io Tue Oct 30 11:47:56 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 30 Oct 2018 10:47:56 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <20181030062939.85F46F36@centrum.cz> Message-ID: > On 30 Oct 2018, at 06:18, Uwe Rathmann wrote: > > On Tue, 30 Oct 2018 09:59:28 +0100, Olivier Goffart wrote: > >> What Lars said, if I read the email properly, is that the Qt Company >> does not see a business value in developing it further. > > Yes and this is relevant if it is relevant for the maintainers of Qbs. Do > we have a statement from them so far ? > >> But the project is open source and the code is there and anyone is free >> to take over if they are interested in it. > > In case a maintainer decides to step down the normal process would be to > find a new one. Only if this is not possible further steps have to be > taken. > > Using Qbs for building Qt has been discussed here and lead to a solid > decision against it. Obviously then the Qt company decided not to work on > this code anymore - so far so good. > > But deprecating Qbs as a tool for building user projects is absolutely > not covered by this discussion and if there was a more related one I seem > to have missed it. > > This all has a lot to do with the question if the Qt Company sees itself > as being a member or the owner of the Qt project. If we really want to be > a community project, then the process of inventing and deprecating > modules has to become more independent. I’d be happy if Qbs development continues, and there is a place for it on qt-project if people want to continue developing it. But this is a bit a different thing from The Qt Company saying that the company will support this for commercial customers, especially given the fact that Qbs never was part of Qt itself. Cheers, Lars From lars.knoll at qt.io Tue Oct 30 11:50:31 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 30 Oct 2018 10:50:31 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <20181030062939.85F46F36@centrum.cz> Message-ID: On 30 Oct 2018, at 06:25, NIkolai Marchenko > wrote: > Yes and this is relevant if it is relevant for the maintainers of Qbs. Do we have a statement from them so far ? We have a confirmation from Lars that QtCreator is dropping qbs support in a year. That basically reads "qbs dead as there will be no IDE supporting it left”. No, you have a confirmation that we’ll keep it there for at least another year. If we have a proper maintainer for the Qbs integration, I do not see a reason why it couldn’t stay in creator for longer. Cheers, Lars On Tue, Oct 30, 2018 at 1:21 PM Uwe Rathmann > wrote: On Tue, 30 Oct 2018 09:59:28 +0100, Olivier Goffart wrote: > What Lars said, if I read the email properly, is that the Qt Company > does not see a business value in developing it further. Yes and this is relevant if it is relevant for the maintainers of Qbs. Do we have a statement from them so far ? > But the project is open source and the code is there and anyone is free > to take over if they are interested in it. In case a maintainer decides to step down the normal process would be to find a new one. Only if this is not possible further steps have to be taken. Using Qbs for building Qt has been discussed here and lead to a solid decision against it. Obviously then the Qt company decided not to work on this code anymore - so far so good. But deprecating Qbs as a tool for building user projects is absolutely not covered by this discussion and if there was a more related one I seem to have missed it. This all has a lot to do with the question if the Qt Company sees itself as being a member or the owner of the Qt project. If we really want to be a community project, then the process of inventing and deprecating modules has to become more independent. Uwe _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladstelmahovsky at gmail.com Tue Oct 30 12:01:50 2018 From: vladstelmahovsky at gmail.com (Vlad Stelmahovsky) Date: Tue, 30 Oct 2018 12:01:50 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: <31921b2c-a68c-1467-b89c-e08869900669@gmail.com> while I really disappointed with this decision, I dont agree that Qt6 is dead because of its build system. we are using Qt not because of qmake Also, Qbs is open source, so its also not dead. br On 10/30/18 10:50 AM, Denis Shienkov wrote: > Hi all, my personal things: > > Welcome to the era of stagnation and dinosaurs. The new > "revolutioning" Qt6 will be released semi-dead. It will > be overgrowned with mold, moss and fungi in the form of > CMake. This will not be a new life, but it will be an > attempt to prolong the convulsions. > > A real new life could give the QBS, that pushed be a new > branch of the spiral of development. It would stimulate > be the QBS integration with others IDE and etc. > > PS: I don't know, what is it: or an "effective management" > or an "evil intent" or an  "CMake lobby", or "not enough > money". Perhaps the thesis that "Millions of flies cannot > be mistaken when they choose shit" works here. > > Anyway, RIP QBS, You were a great friend, I never forget you. > I drink Vodka and grieve about the innocently murdered projects > for the sake of conjuncture. > > == R I P, QBS == > > IMHO, :( > > вт, 30 окт. 2018 г. в 12:08, Richard Weickelt >: > > > > Qbs is something that has been developed almost exclusively by > The Qt > > Company. As such, TQtC had to also look at it from a business > perspective > > and how it fits into the larger picture of making Qt successful. > To make > > a long story short, while Qbs is pretty cool and interesting > technology, > > it doesn’t really help us expand the Qt ecosystem and usage. > > Qbs has made the development of multi-platform applications with > multiple > libraries a breeze for me. Even projects that contain firmware for > different > target architectures in addition to a Qt application are no > problem at all > with Qbs. Thanks to Qbs, I can focus on code and not on the build > system. I > achieve more in less time. > > I always thought that Qbs was a great example for using QML. > > > To make Qbs really successful would require a rather large > effort and > > investment in promoting it towards the larger C++ ecosystem as a new > > build tool. At the same time it has to be an open source product > to stand > > any chance in the market. Together this makes it challenging for > TQtC to > > see how to recover that investment. Thus this investment would > be at the > > expense of other things we’d like to do, like improving our IDE, > working > > on rearchitecting and cleaning up our core frameworks for Qt 6 > or the > > design tooling we are currently investing into. The Qt Company > believes > > that those other investments are more important for the future > of Qt than > > our choice of build tool. > > It seems that Qbs never got much traction within the Qt Company > either. > Outside the regular blog posts, I don't see any attempt to promote Qbs > anywhere. Correct me if I'm wrong. I may have noticed that Jake > Petroules > did his best to get the word out, but I guess that was his private > mission > rather than his official role in the Qt Company. What I can't > complain about > is the unprecedented dedication and professionalism of Christian, > Jörg and > Jake on this project. Also all support questions were answered in > lightning > speed. > > > As such, we were left with the question on whether we need Qbs > as the > > build system for Qt 6 or whether cmake (as the other > alternative) would > > be up to the task. > > [..] > > Given that we are confident we can build Qt 6 with cmake, I > believe that > > it makes most sense to follow down that route. In case you’re > interested, > > you can have a look at the cmake prototype code for qtbase on > Gerrit in > > the wip/cmake branch. Please also let us know if you’re > interested in > > helping with the effort of porting Qt’s build system over to cmake. > > > > We have been developing Qbs over the last years, and as such are > > committed to it for some more time. We are planning on another > feature > > release in the first quarter of next year and will support it in Qt > > Creator for at least another year. Qbs is open source and if someone > > wants to take over and develop it further let us know as well. > I’d also > > like to use this place to thank Christian and Jörg for all their > great > > work on Qbs  (and of course also anybody else who contributed to > it). > > How can we leverage from the next half year to smoothly turn Qbs > into a > community-owned OS project? Does anybody know a positive > role-model for this? > > I don't want to miss out on the productivity gains I've made with > Qbs, but > on the other hand I have very little free time. However, I would > voluntarily > contribute to the documentation of Qbs. > > Richard > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan.vatra at kdab.com Tue Oct 30 12:16:43 2018 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Tue, 30 Oct 2018 13:16:43 +0200 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: <2483414.fFGr5Wv9AV@dragon> Hi, DISCLAIMER: I was one of the biggest QBS supporters! QBS was a dream too good to be true, its main goals were: a) a simple sintax which anyone can use b) no extrenal dependeincies to configure/build & deploy your apps c) designed with tooling in mind: c.1) imagine a world where you can manage almost everything in your project from IDE but also from your text editor. c.2) back then, none of the existing build system could deliver enough information to IDEs to enable prefect code completion (e.g. include paths, defines, compiler flags, etc.) d) last but not least a clean and easily maintainable code base that can be used for the next decade(s). Now let's see what QBS achived from all of these goals: a) Checked, with minor things that we can leave with (the base.concat things I never undersood it). b) We can say checked. c.1) Nope, not really. Besides that you can add files, you can't manage no other things. Here CMake is better, because it exposes all its properties in a IDE friendly way. c.2) Incomplete! A while ago, I created a QBS plugin for KDevelop[1] and I found some problems, see how QBS developers treat them here: https:// bugreports.qt.io/browse/QBS-902 . That was the moment when I started to have doubts :). d) While c.1 and c.2 can be fixed with some effort, here we have bigger problems: - Instread to port QBS to QML JS in the first second when QtScript was deprecated, they fork it! I know that back then QML JS needed some love, but instead to collaborate with QML JS folks they decided keep using QtScript! IIRC a brave soul, port it to QML JS, but guess what, QBS devs reject it and kept using QtScript! - Even more, they found a few problem also in QML parser, and guess what, they forked also QML! To fix d) a large part of QBS must be reorganized/rewritten, so, IMHO this project is quite DEAD, because I don't believe the community will rewrite those parts. Looking at these facts, I think TQC decission is not that bad and if they want to start working on Qt6 soon, they had to choose a build system now, and sadly cmake was the only choice... Cheers, BogDan. [1] https://github.com/bog-dan-ro/kdevelop În ziua de marți, 30 octombrie 2018, la 11:00:18 EET, Christian Gagneraud a scris: > On Tue, 30 Oct 2018 at 01:17, Lars Knoll wrote: > > Hi all, > > Hi Lars, > > Playing the devil's advocate here. > > May I ask: Which democratic/meritocratic process was used to take > this decision? > I do understand that the QtC is the Qbs instigator/maintainer, so > nobody can blame you for pulling the plug off and adjusting resources > allocation. > > Who/when/where was the decision of switching to CMake taken? > Any trace record? A vote, a ballot, something? I havent's hear of any > "Qt Project" event/announcement recently. > So far i've seen some broad (but useful) un-authoritative requirements > from Thiago, > followed by a lengthy (endless) discussion, and suddenly your email > that seems to announce the result of the "election". > When did the election happened? > > So some claims that build systems are no "The Qt Company" business, > yet you're about to take the road of having to bend a dinosaur (CMake, > that's a personal opinion) to suit your modern requirements. > Are you planning to have Qt employees fix CMake? > > Then why spend energy/money to fix something that is broken by design? > (Again, that is a personal opinion, if needed to say) > > No conspiracy here, but i have a few more questions (not related, in > no particular order) > - Did Jake left the QtC due to your early decision to drop qbs? ( I > personally do think that the decision was taken long time ago) > - Did you drop Qbs due to it's "unsolvable" dependency on deprecated Qt > Script? - Any track record that Qbs was not fit for the job? (Please no "we > can't build Qt with it", as you cannot build Qt with anything but > qmake right now) > > Sincerely, > Chris From chgans at gmail.com Tue Oct 30 12:23:48 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Wed, 31 Oct 2018 00:23:48 +1300 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: > > On 30 Oct 2018, at 05:00, Christian Gagneraud wrote: > > - Any track record that Qbs was not fit for the job? (Please no "we > > can't build Qt with it", as you cannot build Qt with anything but > > qmake right now) > > No, of course one could have made it support building Qt. There were some missing items like the configuration system and some other things, all of those could of course have been implemented. How CMake will solve the 'configuration' problem. Will CMake allow us to build for, say, QNX, GreenHill, VxWorks, and the likes? I doubt! Everyone is bragging about open source (me first), but the Qt market is medical, automotive and avionics/space industry, isn't it? How will CMake cope with that? CMake is not even aware that they are other OS behind WIndows and Linux Desktop.... Just Sayin'. Chris From mitch.curtis at qt.io Tue Oct 30 12:29:31 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Tue, 30 Oct 2018 11:29:31 +0000 Subject: [Development] Serialising UI state in QML via QSettings and JSON: QByteArray vs QString In-Reply-To: References: , Message-ID: > -----Original Message----- > From: Edward Welbourne > Sent: Tuesday, 30 October 2018 11:37 AM > To: Mitch Curtis > Cc: Qt development mailing list > Subject: Re: [Development] Serialising UI state in QML via QSettings and > JSON: QByteArray vs QString > > Edward Welbourne (Monday, 29 October 2018 7:31 PM) wrote > >> I'm not sure where JSON got involved in that > > Mitch Curtis (30 October 2018 08:37) replied > > What do you mean? It's in the title of the email; it's a popular > > choice for storing data like this, so I want SplitView's serialisation > > to be compatible with it. > > Perhaps I need to rephrase: to what extent is the choice of JSON, in the > present discussion, necessary or incidental ? If what you're trying to do has > to use JSON with QSettings, then it's necessary. If JSON just looked, at first > sight, like it would solve your primary problem, then it's incidental and can be > replaced by something compatible. > > Eddy. I want users to be able to call SplitView's saveState() function and store the result in a JSON file. To do that, it needs to be able be stored in a QVariant because QJsonObject isn't exposed to QML. The next issue for users would be the lack of ability to convert that QVariant into a QJsonObject. By the way, QCborValue and friends is working quite well so far. :) From jeanmichael.celerier at gmail.com Tue Oct 30 12:32:41 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Tue, 30 Oct 2018 12:32:41 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: > Will CMake allow us to build for, say, QNX, GreenHill, VxWorks, and the likes? uhh... yeah? CMake has supported Green Hills for years. >CMake is not even aware that they are other OS behind WIndows and Linux Desktop.... sorry, that's FUD. CMake has built-in support for Android, macOS, UWP apps and works just fine on BSDs and other niche OS such as Haiku (full list here : https://github.com/Kitware/CMake/tree/master/Modules/Platform). Hell, it's the build system for at least two existing alternative OSes: ReactOS (https://github.com/reactos/reactos) and IncludeOS ( https://github.com/hioa-cs/IncludeOS). iOS is curerntly best supported (imho) through https://github.com/ruslo/polly which is a set of toolchains not unlike qmake's mkspecs. ------- Jean-Michaël Celerier http://www.jcelerier.name On Tue, Oct 30, 2018 at 12:24 PM Christian Gagneraud wrote: > > > On 30 Oct 2018, at 05:00, Christian Gagneraud > wrote: > > > - Any track record that Qbs was not fit for the job? (Please no "we > > > can't build Qt with it", as you cannot build Qt with anything but > > > qmake right now) > > > > No, of course one could have made it support building Qt. There were > some missing items like the configuration system and some other things, all > of those could of course have been implemented. > > How CMake will solve the 'configuration' problem. Will CMake allow us > to build for, say, QNX, GreenHill, VxWorks, and the likes? I doubt! > Everyone is bragging about open source (me first), but the Qt market > is medical, automotive and avionics/space industry, isn't it? How will > CMake cope with that? > CMake is not even aware that they are other OS behind WIndows and > Linux Desktop.... > > Just Sayin'. > Chris > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abbapoh at gmail.com Tue Oct 30 12:35:20 2018 From: abbapoh at gmail.com (=?koi8-r?B?6dfBziDrz83J09PB0s/X?=) Date: Tue, 30 Oct 2018 12:35:20 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: It is aware about Mac OS! Doesn't help actually, last time I tried to build kde apps on mac, I failed Иван Комиссаров 30 окт. 2018 г., в 12:23, Christian Gagneraud написал(а): >>> On 30 Oct 2018, at 05:00, Christian Gagneraud wrote: >>> - Any track record that Qbs was not fit for the job? (Please no "we >>> can't build Qt with it", as you cannot build Qt with anything but >>> qmake right now) >> >> No, of course one could have made it support building Qt. There were some missing items like the configuration system and some other things, all of those could of course have been implemented. > > How CMake will solve the 'configuration' problem. Will CMake allow us > to build for, say, QNX, GreenHill, VxWorks, and the likes? I doubt! > Everyone is bragging about open source (me first), but the Qt market > is medical, automotive and avionics/space industry, isn't it? How will > CMake cope with that? > CMake is not even aware that they are other OS behind WIndows and > Linux Desktop.... > > Just Sayin'. > Chris > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Jedrzej.Nowacki at qt.io Tue Oct 30 12:38:40 2018 From: Jedrzej.Nowacki at qt.io (Jedrzej Nowacki) Date: Tue, 30 Oct 2018 11:38:40 +0000 Subject: [Development] Metatype system in Qt6 In-Reply-To: <3d810856-fe12-7dea-6b6b-d7aba2876a7c@woboq.com> References: <2756315.1D9YIM6Clu@snoll> <3d810856-fe12-7dea-6b6b-d7aba2876a7c@woboq.com> Message-ID: <1626141.SNMCpQdRWm@snoll> Dnia poniedziałek, 29 października 2018 18:46:18 CET Olivier Goffart pisze: > On 10/29/18 5:39 PM, Jedrzej Nowacki wrote: > > Hi everyone! > > > > While main heat on the mailing list is taken by topic how to encode > > that we > > > > are nice, friendly and respectful to each other, I would like to show some > > side project that I had. It is a proposal for base of metatype system for > > Qt6. You can look and comment at it here: > > https://github.com/nierob/qmetatype. It is quite fresh and it was rather > > a storage for functionality ideas. I haven't tried to compare performance > > of it to the current system, but for sure it has more flexibility and I > > believe, that conceptually it could serve us during Qt6. Anyway before > > spending too much time on it I would like to get some early feedback and > > questions. > > The discussion in that other thread are not finished, so please wait until > there is consensus before being nice! Well I prefer publish it now and work in the open. I do not expect everyone jumping to the topic , dropping everything else, but at least some people can look at the code :-) There is no rush, for me it is an achieved milestone. Now the harder work slowly may happen. > But thanks for caring about the QMetaType system. Thanks for looking at the code! > I had a short look. I think it would be usefull if you already used names > closer to what they are supposed to be. Namespace N, P, are not so nice > names. N is next, P is private, kind of my personal standard. Action point for me: - updated P to QtPrivate - see how many name clashes I will get after removing N. > The idea of using a single function with operation is quite a good idea I > like it. As long as the function takes the typeid as a parameter. > Indeed, I'm thinking about dynamic types that would come from language > bindings: in this situation, while it is easy to allocate memory on the > heap, it is not easy to create a new function pointer for every dynamic > type that we would register. Let's postpone that discussion to a moment that we agree on the extensions. > Regarding the extension, i don't know if it is such a good idea, because you > never know what you can rely on. > say you have a QVariant with some type that comes from some part of your > code, how do you know if you can print it with qDebug, or convert it to > string, how do you register that? > IMHO, there should not be extensions! All operation that we want to make > available for a type should be always available. Using SFINAE to find out if > it is available. Extensions in that respect do not change anything, because it is about error handling. How to inform a user that a type is not qdebug stream-able or can not be converted to QString. In the current and the data driven approach you would need to check if the right function pointer is null or not and on top of this the error handling still would need to happen as the call itself could fail. With the proposed solution you have only one point in which you handle potential errors, just after the metatype call. So let's return to QVariant concern that you expressed. I believe that if you plan to use a feature you need to ensure that you can. So I would propose QVariant constructor to look more or less like qVariantFromValue, it would do the "registration" it needs. It is in sync with QObject registering own properties types. SFINAE would be used in extensions, as I showed in https://github.com/nierob/ qmetatype/blob/master/extensions/streams.h, still error handling is missing there. Actually I think it is wrong layer for detection, creating dummy handlers is wrong. Action points for me: - show in a better way that extensions can be added lazily - improve error handling in metatype call - highlight more common set of operations that would be used if qTypeId() is called - move stream SFINAE detection a bit higher in the code stack > So what are the operation we want on a QMetaType: > > - for QVariant, and the queued connections: copy / destruction. Ideally in > place. So we also need the size/alignement to be able to allocate the memory > > - for qDebug, we need the QDebug operator << > > - for QDataStream, we need the operator << and >>, and an unique identifier > that stay the same. Currently, this is the type id for builtin types, and > the name for custom type. I suggest we use the name, if we want to keep > compatibility with old steam, we will need to keep a mapping from old type > id, to new name. I'm pretty sure that you are aware that the list is far from being complete, so I will not neat pick on this, but how you make sure that every future use case would satisfied? Hiding functionality behind a function and extensible data struct allow _us_ to extend it if _we_ believe that costs are worth the gain, but it doesn't solve problem for 3rdparty code. We do see the problem even in our modules that needs to keep a sibling mapping from typeid to some functions, in particular dbus and qml(?). > As for the name, we can indeed find a way to extract it from parsing it from > __PRETTY_FUNC__ as you do. It would work on every compiler we support i > guess, but we need spcial code for that as it is not really standard. Yes, it is compiler specific, but some version of the trick would work on all supported compilers, I think. Even if not we could fallback to typeid() and require RTTI on these potentially few weaker compilers, so my feeling is that it is safe to use it. > In Qt5, we also need the name for the string-based connection syntax. > However, I believe we can do that without relying on the name > "as-seen-by-moc", if the moc generated code always register the types. > (this is already almost the case) Why almost? Is it that because of forward declared types? > - What about QSequentialIterable / QAssociativeIterable? We also need > something there. Nothing really, currently it works through conversions. We could keep the way or really extract a new API that allows to do same thing. It is slightly orthogonal, unless I miss something. Action point for me: - prototype conversions > In the design document you say: > > The whole registry is kept behind a mutex and it is very central, the > > mutex > > usage actually shows on profilers. > > This used to be the case before Qt 5.7, but since then, QReadWriteMutex was > greatly optimized, does it still show in the profiler? Hmm true, I do not know. The list was created from the top of my head. Action point for me: - remove the point > You will need that anyway, because relying on a static variable in a > function template does not work on MSVC as far as i know. (Last time i > tried was a long time ago, and they had different address and value in > different libraries) That's why we will probably need to initialize it with > a name lookup. Ugh, that is an ugly problem. This https://github.com/nierob/qmetatype/blob/ master/metatype_impl.h#L80 one really requires the unification of variables. You are right we can workaround it with a global registry and name lookup, but... oh. > It is probably still a good idea to register builtin type at compile time, > since we want to save in registering time. There are some data structures > out there with compile time hash table that can be extended at runtime. Yes, in addition we will need to have QMetaType::Type mapping anyway to keep SC. Action point for me: - prototype the mapping > So the early feedback i can give on your code is that it is a bit more > complicated than necessary with the extension. and i think it can be > simplified. Because you are skipping one of the features that I would like to have. To be discussed ;-) Thank you! Jędrek From cristian.adam at gmail.com Tue Oct 30 12:42:35 2018 From: cristian.adam at gmail.com (Cristian Adam) Date: Tue, 30 Oct 2018 12:42:35 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: On Tue, Oct 30, 2018, 12:24 Christian Gagneraud wrote: > > > On 30 Oct 2018, at 05:00, Christian Gagneraud > wrote: > > > - Any track record that Qbs was not fit for the job? (Please no "we > > > can't build Qt with it", as you cannot build Qt with anything but > > > qmake right now) > > > > No, of course one could have made it support building Qt. There were > some missing items like the configuration system and some other things, all > of those could of course have been implemented. > > How CMake will solve the 'configuration' problem. Will CMake allow us > to build for, say, QNX, GreenHill, VxWorks, and the likes? I doubt! > Everyone is bragging about open source (me first), but the Qt market > is medical, automotive and avionics/space industry, isn't it? How will > CMake cope with that? > CMake is not even aware that they are other OS behind WIndows and > Linux Desktop.... > CMake is used in Automotive. Here is a link to the blog of one of the QNX's Eclipse CDT contributors, and there you can see how hard it is to write a CMake toolchain file for QNX: https://cdtdoug.ca/2017/10/06/qnx-cmake-toolchain-file.html Cheers, Cristian. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Tue Oct 30 13:29:35 2018 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 30 Oct 2018 13:29:35 +0100 Subject: [Development] Metatype system in Qt6 In-Reply-To: <1626141.SNMCpQdRWm@snoll> References: <2756315.1D9YIM6Clu@snoll> <3d810856-fe12-7dea-6b6b-d7aba2876a7c@woboq.com> <1626141.SNMCpQdRWm@snoll> Message-ID: <621b8325-250c-8bfb-3776-106210b8246a@woboq.com> Hi, On 10/30/18 12:38 PM, Jedrzej Nowacki wrote: [...] > Extensions in that respect do not change anything, because it is about error > handling. How to inform a user that a type is not qdebug stream-able Not really important. I just want to do qDebug() << my_variant; and have some useful information if possible. This is just for printf-style debugging. I don't want to add a line before such as: qRegisterDebugOperator(); // maybe my_variant contains MyType so i need to register it. I expect that if something goes into the QVariant, it has everything. > or can not be converted to QString. {QMetaType/QVariant}::canConvert, but let's talk about conversion later. > In the current and the data driven approach you > would need to check if the right function pointer is null or not and on top of > this the error handling still would need to happen as the call itself could > fail. With the proposed solution you have only one point in which you handle > potential errors, just after the metatype call. I don't understand why, internally, handling a null function pointer (or check the return code of a metacall function) is a problem. Also i do not see how the proposed extension system solve this. Please elaborate. > So let's return to QVariant concern that you expressed. I believe that if you > plan to use a feature you need to ensure that you can. So I would propose > QVariant constructor to look more or less like qVariantFromValue, it would do > the "registration" it needs. It is in sync with QObject registering own > properties types. Right, exactly! So QVariant would call qMetaTypeId() which would take care that the type is registered, with all features. [...] >> So what are the operation we want on a QMetaType: >> >> - for QVariant, and the queued connections: copy / destruction. Ideally in >> place. So we also need the size/alignement to be able to allocate the memory >> >> - for qDebug, we need the QDebug operator << >> >> - for QDataStream, we need the operator << and >>, and an unique identifier >> that stay the same. Currently, this is the type id for builtin types, and >> the name for custom type. I suggest we use the name, if we want to keep >> compatibility with old steam, we will need to keep a mapping from old type >> id, to new name. > I'm pretty sure that you are aware that the list is far from being complete, Yes. I might have forgot a couple of things. Some flags, registering the QMetaObject, conversion function, indeed. Speaking of conversion. I think you agree that this huge conversion martix to try to convert from and to anything is a bad design we should review. I've heard you in the past claiming that you want to remove any conversion. I think we probably should just enable conversion to/from some basic primitive type: string and numbers. I'm not sure this is usefull to let QVariant have the ability to convert from a QImage to a QPixmap. > so I will not neat pick on this, but how you make sure that every future use > case would satisfied? Say we decide, in Qt 6.4, to add the std::iostream operators while this was no planed before: we just add them. I don't see the problem. We need to be carefull about binary compatibility and types registered in older application, but that is not a big issue. We can also add whatever in Qt 5.x lifetime. We added some data to the QMetatype within Qt 5.x lifetime. This is not a problem. > Hiding functionality behind a function and extensible > data struct allow _us_ to extend it if _we_ believe that costs are worth the > gain, but it doesn't solve problem for 3rdparty code. We do see the problem > even in our modules that needs to keep a sibling mapping from typeid to some > functions, in particular dbus and qml(?). Here you make a good case. If I understand correctly, you don't want dbus and qml to have themself a global: QHash typeRegistery; // guarded by typeMutex In this respect, there is indeed value for extensions. As long as the basic stuff are not extensions it is fine. (I would hope that neither Qml nor dbus need extensions though) [...] >> In Qt5, we also need the name for the string-based connection syntax. >> However, I believe we can do that without relying on the name >> "as-seen-by-moc", if the moc generated code always register the types. >> (this is already almost the case) > Why almost? Is it that because of forward declared types? Because it only work for type that moc can determine to be automatically registrable. Ideally, all types should be registerable. But moc has a conservative aproch here, doing it to eager can have source incompatibilities issue moc-ng [https://github.com/woboq/moc-ng] already registers all types that can be registered. And I guess moc should do the same. verdigris [https://github.com/woboq/verdigris] also register all types. We have the problem with pointer to forward declared class. That can cause ODR violation and is indeed a problem. >> You will need that anyway, because relying on a static variable in a >> function template does not work on MSVC as far as i know. (Last time i >> tried was a long time ago, and they had different address and value in >> different libraries) That's why we will probably need to initialize it with >> a name lookup. > Ugh, that is an ugly problem. This https://github.com/nierob/qmetatype/blob/ > master/metatype_impl.h#L80 one really requires the unification of variables. > You are right we can workaround it with a global registry and name lookup, > but... oh. I know, ... Previous work: https://bugreports.qt.io/browse/QTBUG-19137 https://codereview.qt-project.org/2106 Yeah.. that's old. Too bad that did not go in Qt5 -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From mitch.curtis at qt.io Tue Oct 30 14:13:54 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Tue, 30 Oct 2018 13:13:54 +0000 Subject: [Development] Serialising UI state in QML via QSettings and JSON: QByteArray vs QString In-Reply-To: References: , Message-ID: > -----Original Message----- > From: Development project.org> On Behalf Of Mitch Curtis > Sent: Tuesday, 30 October 2018 12:30 PM > To: Edward Welbourne > Cc: Qt development mailing list > Subject: Re: [Development] Serialising UI state in QML via QSettings and > JSON: QByteArray vs QString > > > -----Original Message----- > > From: Edward Welbourne > > Sent: Tuesday, 30 October 2018 11:37 AM > > To: Mitch Curtis > > Cc: Qt development mailing list > > Subject: Re: [Development] Serialising UI state in QML via QSettings > > and > > JSON: QByteArray vs QString > > > > Edward Welbourne (Monday, 29 October 2018 7:31 PM) wrote > > >> I'm not sure where JSON got involved in that > > > > Mitch Curtis (30 October 2018 08:37) replied > > > What do you mean? It's in the title of the email; it's a popular > > > choice for storing data like this, so I want SplitView's > > > serialisation to be compatible with it. > > > > Perhaps I need to rephrase: to what extent is the choice of JSON, in > > the present discussion, necessary or incidental ? If what you're > > trying to do has to use JSON with QSettings, then it's necessary. If > > JSON just looked, at first sight, like it would solve your primary > > problem, then it's incidental and can be replaced by something compatible. > > > > Eddy. > > I want users to be able to call SplitView's saveState() function and store the > result in a JSON file. To do that, it needs to be able be stored in a QVariant > because QJsonObject isn't exposed to QML. The next issue for users would > be the lack of ability to convert that QVariant into a QJsonObject. > > By the way, QCborValue and friends is working quite well so far. :) I ran into an issue. An approach that uses QCborArray/Map/Value to serialise SplitView's state into a byte array still runs into the same problem when it comes to JSON files: https://doc-snapshots.qt.io/qt5-5.12/qcborvalue.html#toJsonValue This table says that byte arrays will be "converted to a lossless encoding like Base64url, but the distinction between strings and byte arrays is lost". So even if I were to document that QCborValue is used to save the state (which I don't really want to do), someone wanting to serialise their UI state to a JSON file would need to use QCbor* API to do so, and at that point the type information that identifies the data as a byte array is lost anyway. Since QCborValue also uses the Base64 string approach and it what is what I was planning on doing if no other solution came up, I think I will just go ahead and return a Base64 QString from QQuickSplitView::saveState() instead of a QVariant containing a QByteArray. I will use the CBOR stuff to serialise it though, as it's much nicer than using QDataStream. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Uwe.Rathmann at tigertal.de Tue Oct 30 14:20:55 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Tue, 30 Oct 2018 13:20:55 +0000 (UTC) Subject: [Development] Metatype system in Qt6 References: <2756315.1D9YIM6Clu@snoll> <3d810856-fe12-7dea-6b6b-d7aba2876a7c@woboq.com> Message-ID: On Mon, 29 Oct 2018 18:46:18 +0100, Olivier Goffart wrote: > In Qt5, we also need the name for the string-based connection syntax. I'm not sure if I'm ontopic for the Metatype system with my comment, so please excuse me if I'm hijacking this thread for a moment. I have this code: https://github.com/uwerat/qskinny/blob/master/src/common/QskMetaFunction.h https://github.com/uwerat/qskinny/blob/master/src/common/ QskMetaInvokable.h This code is for situations, where registering callbacks ( slots ) is needed, but without having a signal or a sender, that is a QObject. F.e like what you have with QTimer::singleShot. Our most important use case is a local bus system, that connects events coming from a system using Sun RPC with slots or property values. As we have several 100 pages each having lots of controls we don't want to create dummy sender Objects only to be able to call a slot and I ended up with diving into template programming myself. Would it be possible to make all this template based stuff for setting up callbacks more independent from being used with signals in Qt6 ? ciao, Uwe From jpnurmi at gmail.com Tue Oct 30 14:48:45 2018 From: jpnurmi at gmail.com (J-P Nurmi) Date: Tue, 30 Oct 2018 14:48:45 +0100 Subject: [Development] Serialising UI state in QML via QSettings and JSON: QByteArray vs QString In-Reply-To: References: Message-ID: On Mon, Oct 29, 2018 at 5:42 PM Mitch Curtis wrote: > I thought that I could get around this by using Qt.atob() and Qt.btoa() in QML to convert the byte array into a Base64 QString, but it turns out that those functions expect a string: > > http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/qml/qml/v8/qqmlbuiltinfunctions.cpp?h=5.12&id=475c74a9926efcd968572563e678988e53804603#n996 Hi Mitch, So Qt.atob() and Qt.btoa() are not doing what they claim to do? Would it be feasible to fix them? -- J-P Nurmi From mitch.curtis at qt.io Tue Oct 30 15:04:02 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Tue, 30 Oct 2018 14:04:02 +0000 Subject: [Development] Serialising UI state in QML via QSettings and JSON: QByteArray vs QString In-Reply-To: References: Message-ID: > -----Original Message----- > From: J-P Nurmi > Sent: Tuesday, 30 October 2018 2:49 PM > To: Mitch Curtis > Cc: development at qt-project.org > Subject: Re: [Development] Serialising UI state in QML via QSettings and > JSON: QByteArray vs QString > > On Mon, Oct 29, 2018 at 5:42 PM Mitch Curtis wrote: > > I thought that I could get around this by using Qt.atob() and Qt.btoa() in > QML to convert the byte array into a Base64 QString, but it turns out that > those functions expect a string: > > > > http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/qml/qml/v8/qqmlbu > > > iltinfunctions.cpp?h=5.12&id=475c74a9926efcd968572563e678988e53804603# > > n996 > > Hi Mitch, Hey. :) > So Qt.atob() and Qt.btoa() are not doing what they claim to do? Would it be > feasible to fix them? Their documentation doesn't claim that they operate on a specific type, so I'm not sure it's a matter of not doing what they claim to do. Whether or not they could be extended to work with byte arrays is a question I don't have the answer to, though presumably it would involve modifying QV4::Value and who knows what else in the guts of QML. Unfortunately it wouldn't help the use case I'm trying to support though, because there is still the problem of Qt's JSON implementation not supporting byte arrays. What do you think about the proposed solution of saveState() returning a Base64 QString? > -- > J-P Nurmi From mitch.curtis at qt.io Tue Oct 30 15:05:27 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Tue, 30 Oct 2018 14:05:27 +0000 Subject: [Development] Serialising UI state in QML via QSettings and JSON: QByteArray vs QString In-Reply-To: References: Message-ID: > -----Original Message----- > From: Development project.org> On Behalf Of Mitch Curtis > Sent: Tuesday, 30 October 2018 3:04 PM > To: J-P Nurmi > Cc: development at qt-project.org > Subject: Re: [Development] Serialising UI state in QML via QSettings and > JSON: QByteArray vs QString > > > -----Original Message----- > > From: J-P Nurmi > > Sent: Tuesday, 30 October 2018 2:49 PM > > To: Mitch Curtis > > Cc: development at qt-project.org > > Subject: Re: [Development] Serialising UI state in QML via QSettings > > and > > JSON: QByteArray vs QString > > > > On Mon, Oct 29, 2018 at 5:42 PM Mitch Curtis wrote: > > > I thought that I could get around this by using Qt.atob() and > > > Qt.btoa() in > > QML to convert the byte array into a Base64 QString, but it turns out > > that those functions expect a string: > > > > > > http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/qml/qml/v8/qqml > > > bu > > > > > > iltinfunctions.cpp?h=5.12&id=475c74a9926efcd968572563e678988e53804603# > > > n996 > > > > Hi Mitch, > > Hey. :) > > > So Qt.atob() and Qt.btoa() are not doing what they claim to do? Would > > it be feasible to fix them? > > Their documentation doesn't claim that they operate on a specific type, so > I'm not sure it's a matter of not doing what they claim to do. Correcting myself here; the docs say "string": "ASCII to binary - this function decodes the base64 encoded data string and returns it." - http://doc.qt.io/qt-5/qml-qtqml-qt.html#atob-method > Whether or not they could be extended to work with byte arrays is a > question I don't have the answer to, though presumably it would involve > modifying QV4::Value and who knows what else in the guts of QML. > > Unfortunately it wouldn't help the use case I'm trying to support though, > because there is still the problem of Qt's JSON implementation not > supporting byte arrays. > > What do you think about the proposed solution of saveState() returning a > Base64 QString? > > > -- > > J-P Nurmi > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From cristian.adam at gmail.com Tue Oct 30 15:33:04 2018 From: cristian.adam at gmail.com (Cristian Adam) Date: Tue, 30 Oct 2018 15:33:04 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: On Tue, Oct 30, 2018 at 12:42 PM Cristian Adam wrote: > On Tue, Oct 30, 2018, 12:24 Christian Gagneraud wrote: > >> > > On 30 Oct 2018, at 05:00, Christian Gagneraud >> wrote: >> > > - Any track record that Qbs was not fit for the job? (Please no "we >> > > can't build Qt with it", as you cannot build Qt with anything but >> > > qmake right now) >> > >> > No, of course one could have made it support building Qt. There were >> some missing items like the configuration system and some other things, all >> of those could of course have been implemented. >> >> How CMake will solve the 'configuration' problem. Will CMake allow us >> to build for, say, QNX, GreenHill, VxWorks, and the likes? I doubt! >> Everyone is bragging about open source (me first), but the Qt market >> is medical, automotive and avionics/space industry, isn't it? How will >> CMake cope with that? >> CMake is not even aware that they are other OS behind WIndows and >> Linux Desktop.... >> > > CMake is used in Automotive. > > Here is a link to the blog of one of the QNX's Eclipse CDT contributors, > and there you can see how hard it is to write a CMake toolchain file for > QNX: https://cdtdoug.ca/2017/10/06/qnx-cmake-toolchain-file.html > > Cheers, > Cristian. > And here is the link with the nightly builds that run on the CMake code base: https://open.cdash.org/index.php?project=CMake&date=2018-10-29#!/%23Nightly_Expected There are quite some platform combinations there. QNX is not there because of licensing I suppose. Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpnurmi at gmail.com Tue Oct 30 15:52:13 2018 From: jpnurmi at gmail.com (J-P Nurmi) Date: Tue, 30 Oct 2018 15:52:13 +0100 Subject: [Development] Serialising UI state in QML via QSettings and JSON: QByteArray vs QString In-Reply-To: References: Message-ID: On Tue, Oct 30, 2018 at 3:04 PM Mitch Curtis wrote: > Their documentation doesn't claim that they operate on a specific type, so I'm not sure it's a matter of not doing what they claim to do. They do promise to handle binary data, though. Representing binary data with null-terminated strings makes them useless. The sole purpose of base64 is to encode binary data to text that can be represented as a string. > Whether or not they could be extended to work with byte arrays is a question I don't have the answer to, though presumably it would involve modifying QV4::Value and who knows what else in the guts of QML. The QML engine gained better QByteArray support recently (5.10?): http://doc.qt.io/qt-5/qtqml-cppintegration-data.html#qbytearray-to-javascript-arraybuffer > Unfortunately it wouldn't help the use case I'm trying to support though, because there is still the problem of Qt's JSON implementation not supporting byte arrays. Pass the state as a base64 string. Where does it turn to a byte array if Qt.btoa() returns a string? > What do you think about the proposed solution of saveState() returning a Base64 QString? -1 :) -- J-P Nurmi From enmarantispam at gmail.com Tue Oct 30 16:33:03 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue, 30 Oct 2018 18:33:03 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: > Thus this investment would be at the expense of other things we’d like to do, like improving our IDE, working on rearchitecting and cleaning up our core frameworks for Qt 6 or the design tooling we are currently investing into. The Qt Company believes that those other investments are more important for the future of Qt than our choice of build tool. I don't understand. Will it not be a return on the investment when people use Qt "because their build tool is the best around" ? Project files are at the root of every project. There are all sorts of good IDEs around but ppl mostly are forced to use CMAKE which no one seems to like. QBS might have been that crucial difference going for qt. Much more important than any IDE echancment. On Tue, Oct 30, 2018 at 5:33 PM Cristian Adam wrote: > On Tue, Oct 30, 2018 at 12:42 PM Cristian Adam > wrote: > >> On Tue, Oct 30, 2018, 12:24 Christian Gagneraud wrote: >> >>> > > On 30 Oct 2018, at 05:00, Christian Gagneraud >>> wrote: >>> > > - Any track record that Qbs was not fit for the job? (Please no "we >>> > > can't build Qt with it", as you cannot build Qt with anything but >>> > > qmake right now) >>> > >>> > No, of course one could have made it support building Qt. There were >>> some missing items like the configuration system and some other things, all >>> of those could of course have been implemented. >>> >>> How CMake will solve the 'configuration' problem. Will CMake allow us >>> to build for, say, QNX, GreenHill, VxWorks, and the likes? I doubt! >>> Everyone is bragging about open source (me first), but the Qt market >>> is medical, automotive and avionics/space industry, isn't it? How will >>> CMake cope with that? >>> CMake is not even aware that they are other OS behind WIndows and >>> Linux Desktop.... >>> >> >> CMake is used in Automotive. >> >> Here is a link to the blog of one of the QNX's Eclipse CDT contributors, >> and there you can see how hard it is to write a CMake toolchain file for >> QNX: https://cdtdoug.ca/2017/10/06/qnx-cmake-toolchain-file.html >> >> Cheers, >> Cristian. >> > > And here is the link with the nightly builds that run on the CMake code > base: > > https://open.cdash.org/index.php?project=CMake&date=2018-10-29#!/%23Nightly_Expected > > There are quite some platform combinations there. QNX is not there because > of licensing I suppose. > > Cheers, > Cristian. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Oct 30 17:10:27 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Oct 2018 09:10:27 -0700 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: <1797586.pj9EAoSRyV@tjmaciei-mobl1> On Tuesday, 30 October 2018 02:47:55 PDT NIkolai Marchenko wrote: > Actually, what is considered moderate complexity? I have a project at work > that has been running for a few years, has 4 people working on it and has a > few thousand commits. My email from July has some objective parameters. Please reread it. > It has a couple dozen libraries, is integrated with gRPC and has code > generated with protobuf on build via a custom QBS module. Is this > considered moderate complexity? Getting there. There are a couple of things missing, but the important ones are there. Is it packaged in a Linux distribution? My requirements also included continuously packaged for 2 years in at least 3 Linux distributions, at the time of the Qt switch to the particular buildsystem. See that email for more information. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Oct 30 17:16:29 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Oct 2018 09:16:29 -0700 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: <9818490.DnMGyfIHUB@tjmaciei-mobl1> On Tuesday, 30 October 2018 02:00:18 PDT Christian Gagneraud wrote: > May I ask: Which democratic/meritocratic process was used to take > this decision? There are two decisions we're discussing here: 1) Qt Company stopping its support for qbs 2) Qt's switch to a different buildsystem (specifically, CMake) > I do understand that the QtC is the Qbs instigator/maintainer, so > nobody can blame you for pulling the plug off and adjusting resources > allocation. That's #1. That's the company's choice and does not need community involvement. The community does not have to agree either and can continue developing Qbs if it wants to. > Who/when/where was the decision of switching to CMake taken? That's #2. That decision HAS NOT been taken. What you see is Lars saying they've done their due diligence to see if they were shooting themselves in the foot if the choice was CMake, if they had to pull the plug on Qbs. However, de facto we only had two choices: Qbs and CMake. With one out of the running, that only leaves one, which will likely win by default. Unless someone steps up and does extra work on something else, making it viable. I've been hearing great things about Meson and their maintainers did contact me after the July email asking if we were considering it. I answered: sure, so long as someone does come along and do the work. > - Did Jake left the QtC due to your early decision to drop qbs? ( I > personally do think that the decision was taken long time ago) He did not. He left months before the decision because he had an offer from a different company that he wanted to take. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Oct 30 17:22:00 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Oct 2018 09:22:00 -0700 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: <7272212.sfBfW8vFQp@tjmaciei-mobl1> On Tuesday, 30 October 2018 02:26:33 PDT Christian Gagneraud wrote: > https://lists.qt-project.org/mailman/listinfo/qbs gives me: > Secure Connection Failed The lists.qt-project.org HTTPS server is misconfigured (has been for a week or so) and is replying with non-encrypted HTTP on port 443. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Oct 30 17:24:48 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Oct 2018 09:24:48 -0700 Subject: [Development] Serialising UI state in QML via QSettings and JSON: QByteArray vs QString In-Reply-To: References: Message-ID: <6976211.KmtkCps84j@tjmaciei-mobl1> On Tuesday, 30 October 2018 06:13:54 PDT Mitch Curtis wrote: > Since QCborValue also uses the Base64 string approach and it what is what I > was planning on doing if no other solution came up, I think I will just go > ahead and return a Base64 QString from QQuickSplitView::saveState() instead > of a QVariant containing a QByteArray. I will use the CBOR stuff to > serialise it though, as it's much nicer than using QDataStream. Sounds like a good plan! -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Oswald.Buddenhagen at qt.io Tue Oct 30 17:40:57 2018 From: Oswald.Buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 30 Oct 2018 16:40:57 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: <20181030164054.GC9915@troll08> On Mon, Oct 29, 2018 at 12:17:04PM +0000, Lars Knoll wrote: > while Qbs is pretty cool and interesting technology, it doesn’t really > help us expand the Qt ecosystem and usage. > you actually don't know that. wide adoption outside the qt ecosystem would create mindshare for the qt project & company. > To make Qbs really successful would require > a rather large effort > [generously assuming that this part is supposed to be read separately] > and investment in promoting it towards the larger C++ ecosystem as a > new build tool. > nonsense. all the promotion qbs would need is being used to build qt. > Together this makes it challenging for TQtC to see how to recover that > investment. > i would venture the assertion that the decision makers at tqtc just don't give a shit. because other companies manage to make a living off (mostly) open-source build tools, both with consulting and with enterprise add-ons. on top of that there are long-term savings to be made from increased productivity (which several posters to this thread have confirmed or implied). that alone won't offset the cost vs. using cmake (it would vs. developing and using qmake), but it's not negligible. On Tue, Oct 30, 2018 at 10:42:13AM +0000, Lars Knoll wrote: > it would require quite a lot of funding to make it more than a niche > product > nonsense. qbs is already a very generic and powerful tool. there isn't anything that needs to be done to make it attractive for non-qt use. domain-specific non-qt functionality is exactly the kind of thing the community would contribute - that's actually what the majority of outside contributions already have been about. > we were actually surprised on how far we got with cmake in a rather > limited period of time. > that should read "the people who volunteered for the task were surprised". > the wip/cmake branch shows that this can be done without having ’to > bend a dinosaur’. > uhm, really? "bending a dinosaur" is an euphemism in my view - i'd call it an effin' disease. the anticipation of exactly *that* is why we started qbs in the first place. > On Tue, Oct 30, 2018 at 10:00:18PM +1300, Christian Gagneraud wrote: > > - Did Jake left the QtC due to your early decision to drop qbs? ( I > > personally do think that the decision was taken long time ago) > > The decision to not continue to develop Qbs was done very recently. It > doesn’t make sense to make a decision and then not take actions. > Whatever the reasons Jake left, they have nothing to do with this. > actually, christian is spot-on, ironically for exactly the reason you cite yourself. the decision to go forward with qbs was repeatedly made internally, but never followed up by actions (in form of staffing the project adequately to make it ready for qt in a finite timeframe). jake had joined the company *because of qbs*, yet tqtc never assigned him to that task - except where he managed to squeeze it into consulting jobs, he was contributing to qbs in his spare time despite working for tqtc. it shouldn't surpise that at some point he said "fuck that" and headed for greener pastures. From mwoehlke.floss at gmail.com Tue Oct 30 17:42:26 2018 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 30 Oct 2018 12:42:26 -0400 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: <7d427e78-e6c7-ae6b-e582-bb314400a51c@gmail.com> On 30/10/2018 07.23, Christian Gagneraud wrote: > CMake is not even aware that they are other OS behind WIndows and > Linux Desktop.... Have you looked at CMake's dashboards? Maybe you are confusing "supported platforms" with "platforms for which pre-built binaries are provided"? Support, much less awareness, is definitely not limited to Windows and Linux. > Will CMake allow us to build for, say, QNX, GreenHill, VxWorks, and > the likes? Platform support is generally contingent on someone doing the work to get it working, and someone supplying dashboard builds. The latter should not be difficult for TQtC. Probably the former will not be difficult either, since presumably someone had those platforms working with QMake... Assuming they don't already work. BTW, that is for *native* support, i.e. running CMake on those platforms. Cross compiling is generally easier. -- Matthew (This should always go without saying when I'm using this e-mail address, but opinions expressed herein do not necessarily reflect those of my employer.) From mwoehlke.floss at gmail.com Tue Oct 30 17:49:49 2018 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 30 Oct 2018 12:49:49 -0400 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181030164054.GC9915@troll08> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <20181030164054.GC9915@troll08> Message-ID: On 30/10/2018 12.40, Oswald Buddenhagen wrote: > all the promotion qbs would need is being used to build qt. If that's the case, please name a few projects that are using bjam or boost.build. -- Matthew From Oswald.Buddenhagen at qt.io Tue Oct 30 17:52:18 2018 From: Oswald.Buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 30 Oct 2018 16:52:18 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: <1797586.pj9EAoSRyV@tjmaciei-mobl1> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1797586.pj9EAoSRyV@tjmaciei-mobl1> Message-ID: <20181030165215.GA26349@troll08> On Tue, Oct 30, 2018 at 09:10:27AM -0700, Thiago Macieira wrote: > Is it packaged in a Linux distribution? My requirements also included > continuously packaged for 2 years in at least 3 Linux distributions, > at the time of the Qt switch to the particular buildsystem. > it's been packaged for much longer and by more distros already, because it's part of qt creator for quite a while. i don't know whether all of them ship it as separate packages already, but the official messaging from us was that they *should*. From Oswald.Buddenhagen at qt.io Tue Oct 30 18:11:20 2018 From: Oswald.Buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 30 Oct 2018 17:11:20 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: <2483414.fFGr5Wv9AV@dragon> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2483414.fFGr5Wv9AV@dragon> Message-ID: <20181030171118.GD9915@troll08> On Tue, Oct 30, 2018 at 01:16:43PM +0200, Bogdan Vatra wrote: > c.2) back then, none of the existing build system could deliver enough > information to IDEs to enable prefect code completion (e.g. include > paths, defines, compiler flags, etc.) > ... > c.2) Incomplete! A while ago, I created a QBS plugin for KDevelop[1] > and I found some problems, see how QBS developers treat them here: > https://bugreports.qt.io/browse/QBS-902 . That was the moment when I > started to have doubts :). > for all i can tell that's a rather poor bug report with little followup from you. that's where i start to have doubts whether you actually mean it. ;) > d) last but not least a clean and easily maintainable code base that can be > used for the next decade(s). > ... > - Instread to port QBS to QML JS in the first second when QtScript was > deprecated, they fork it! I know that back then QML JS needed some love, but > instead to collaborate with QML JS folks they decided keep using QtScript! > IIRC a brave soul, port it to QML JS, but guess what, QBS devs reject it and > kept using QtScript! > - Even more, they found a few problem also in QML parser, and guess what, > they forked also QML! > both these items get a huge "so what?" in response. because they have no practical impact whatsoever. > To fix d) a large part of QBS must be reorganized/rewritten, > i see no actual evidence of that. From enmarantispam at gmail.com Tue Oct 30 18:14:29 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue, 30 Oct 2018 20:14:29 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181030171118.GD9915@troll08> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2483414.fFGr5Wv9AV@dragon> <20181030171118.GD9915@troll08> Message-ID: For anyone interested in QBS survival, let's fill the sheet with QBS ecosystem. Maybe if we show TQtC that people are actually using it they will reconsider. Post your projects (and ones you know of) here: https://docs.google.com/spreadsheets/d/1CwXx2F1zuATYY3GGOTkFgDB9jwMPghf6az_RVOnskfk/edit#gid=0 On Tue, Oct 30, 2018 at 8:11 PM Oswald Buddenhagen wrote: > On Tue, Oct 30, 2018 at 01:16:43PM +0200, Bogdan Vatra wrote: > > c.2) back then, none of the existing build system could deliver enough > > information to IDEs to enable prefect code completion (e.g. include > > paths, defines, compiler flags, etc.) > > ... > > c.2) Incomplete! A while ago, I created a QBS plugin for KDevelop[1] > > and I found some problems, see how QBS developers treat them here: > > https://bugreports.qt.io/browse/QBS-902 . That was the moment when I > > started to have doubts :). > > > for all i can tell that's a rather poor bug report with little followup > from you. that's where i start to have doubts whether you actually mean > it. ;) > > > d) last but not least a clean and easily maintainable code base that can > be > > used for the next decade(s). > > ... > > - Instread to port QBS to QML JS in the first second when QtScript was > > deprecated, they fork it! I know that back then QML JS needed some love, > but > > instead to collaborate with QML JS folks they decided keep using > QtScript! > > IIRC a brave soul, port it to QML JS, but guess what, QBS devs reject it > and > > kept using QtScript! > > - Even more, they found a few problem also in QML parser, and guess > what, > > they forked also QML! > > > both these items get a huge "so what?" in response. because they have no > practical impact whatsoever. > > > To fix d) a large part of QBS must be reorganized/rewritten, > > > i see no actual evidence of that. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Oswald.Buddenhagen at qt.io Tue Oct 30 18:17:54 2018 From: Oswald.Buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 30 Oct 2018 17:17:54 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: <20181030171752.GE9915@troll08> On Tue, Oct 30, 2018 at 10:41:17AM +0100, Jean-Michaël Celerier wrote: > I'd like to point you to a mailing list message of Brad King from a > few months ago about alternative languages for CMake [...] > So, why not just go and propose the declarative QBS syntax as a > front-end for CMake? > or, you know, just adding the remaining missing bits to qbs, which doesn't have all the historical baggage of cmake? it's much easier to make qbs generate (and even read) cmake interface files than to re-architect cmake to make it, well, sane. From perezmeyer at gmail.com Tue Oct 30 18:18:05 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Tue, 30 Oct 2018 14:18:05 -0300 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181030165215.GA26349@troll08> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1797586.pj9EAoSRyV@tjmaciei-mobl1> <20181030165215.GA26349@troll08> Message-ID: <2248934.K6aZsiT3RL@tonks> El martes, 30 de octubre de 2018 13:52:18 -03 Oswald Buddenhagen escribió: > On Tue, Oct 30, 2018 at 09:10:27AM -0700, Thiago Macieira wrote: > > Is it packaged in a Linux distribution? My requirements also included > > continuously packaged for 2 years in at least 3 Linux distributions, > > at the time of the Qt switch to the particular buildsystem. > > it's been packaged for much longer and by more distros already, because > it's part of qt creator for quite a while. i don't know whether all of > them ship it as separate packages already, but the official messaging > from us was that they *should*. The first Debian upload was: qbs (1.2.2+dfsg-1) unstable; urgency=medium * Initial release (closes: #745095). -- Dmitry Shachnev Sat, 26 Jul 2014 23:28:44 +0400 As of today, a little more than 4 years, it has only two users (reverse dependencies): qt creator and dewall. Considering yesterday's announce and the fact that qt creator ships a bundled copy the only package stopping us from removing qbs from the archive is dewall, so I don't think it will stay in the archive for much longer. -- The box said 'Requires Windows 95 or better'. So I installed Linux. Anonymous Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From mwoehlke.floss at gmail.com Tue Oct 30 18:18:29 2018 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 30 Oct 2018 13:18:29 -0400 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181030092102.E3EE3ACC@centrum.cz> References: <20181030092102.E3EE3ACC@centrum.cz> Message-ID: <4f019784-286b-7621-0b39-325b149cdc4b@gmail.com> On 30/10/2018 04.21, resurrection at centrum.cz wrote: > Christian Gagneraud wrote: >> On Tue, 30 Oct 2018 at 18:29, wrote: >>> set(var1 "Hello") >>> set(var2 "Hello") >>> >>> if(var1 EQUAL var2) >>>     message("They are equal") >>> endif() >>> >>> Guess what, it prints NOTHING despite docs explicitly saying this >>> should work. Nothig will help, STREQUAL, MATCHES, dereferencing >>> the arguments, whatever.>> >> You want >> if (var1 STREQUAL var2) and this works as expected (and documented). >   > No it does not. Have you tried it? $ cat test.cmake set(var1 "Hello") set(var2 "Hello") if(var1 STREQUAL var2) message("They are equal") endif() $ cmake -P test.cmake They are equal > As I mentioned it does not work. And even if you somehow managed to > make it work it would break the moment someone would define the > variable "Hello" elsewhere in the script. $ cat test2.cmake set(Hello good bye) set(var1 "Hello") set(var2 "Hello") if(var1 STREQUAL var2) message("They are equal") endif() $ cmake -P test2.cmake They are equal As written, the variables will only be expanded once. But, even if you wrote: if(${var1} STREQUAL ${var2}) ...which will expand to: if("good;bye" STREQUAL "good;bye") ...they will still be equal. (And I don't see your point, because if you wrote it like that, you *wanted* it to be able to expand the way it did.) > The fact we are discussing the very fundamental programming feature - > control flow - that just does not work as expected (or documented) is > the main problem with CMake. That's a strong claim that lacks substantiation. p.s. Please use '>' to quote like the rest of the world. -- Matthew (This should always go without saying when I'm using this e-mail address, but opinions expressed herein do not necessarily reflect those of my employer.) From kshegunov at gmail.com Tue Oct 30 18:26:15 2018 From: kshegunov at gmail.com (Konstantin Shegunov) Date: Tue, 30 Oct 2018 19:26:15 +0200 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181030164054.GC9915@troll08> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <20181030164054.GC9915@troll08> Message-ID: On Tue, Oct 30, 2018 at 6:41 PM Oswald Buddenhagen wrote: > On Mon, Oct 29, 2018 at 12:17:04PM +0000, Lars Knoll wrote: > > and investment in promoting it towards the larger C++ ecosystem as a > > new build tool. > > > nonsense. > all the promotion qbs would need is being used to build qt. > Context: I don't really have a stake in this argument - I'm a qmake user that doesn't *much* care about the build system, but I'll throw my 2 cents in. For me cmake is good because many projects are already using it, meaning that there's not a new technology to learn for many developers. Also it's powerful, even to the point of being dangerous (I've seen quite the abominations). On the minus side - it's rather complicated and the syntax is abysmal. Argument: >From my point of view qbs is doomed as long as qmake's alive. Either kill qmake and force the developers using Qt (or developing Qt) to use qbs, with all its quirks, or live with the fact that people don't want to spend the time learning a new technology if they don't have to. That's leaving the pure enthusiasm about something cool aside. Not forcing the issue, in my opinion, is the reason for the inevitable demise of qbs. And that's exactly in line with the situation about makefiles: everybody's still using them underneath the build tools, and pretty much everybody is hating them, but at the end of day they work and there's little incentive to switch; known is *safe* but ultimately hinders change. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierluigi.fiorini at gmail.com Tue Oct 30 18:31:54 2018 From: pierluigi.fiorini at gmail.com (Pier Luigi Fiorini) Date: Tue, 30 Oct 2018 18:31:54 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181030165215.GA26349@troll08> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1797586.pj9EAoSRyV@tjmaciei-mobl1> <20181030165215.GA26349@troll08> Message-ID: Il giorno mar 30 ott 2018 alle ore 17:52 Oswald Buddenhagen < Oswald.Buddenhagen at qt.io> ha scritto: > On Tue, Oct 30, 2018 at 09:10:27AM -0700, Thiago Macieira wrote: > > Is it packaged in a Linux distribution? My requirements also included > > continuously packaged for 2 years in at least 3 Linux distributions, > > at the time of the Qt switch to the particular buildsystem. > > > it's been packaged for much longer and by more distros already, because > it's part of qt creator for quite a while. i don't know whether all of > them ship it as separate packages already, but the official messaging > from us was that they *should*. > > Distros started packaging it separately for some time now. Before that, as you point out, it was packaged inside QtCreator. Debian: https://packages.debian.org/sid/qbs Fedora: https://apps.fedoraproject.org/packages/qbs Arch Linux: https://www.archlinux.org/packages/extra/x86_64/qbs/ OpenSuSE: https://software.opensuse.org/package/qbs?search_term=qbs -- https://liri.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwoehlke.floss at gmail.com Tue Oct 30 18:38:42 2018 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 30 Oct 2018 13:38:42 -0400 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <20181030164054.GC9915@troll08> Message-ID: <59bbab15-e9ee-b894-f4c0-239125a6dfd8@gmail.com> On 30/10/2018 13.26, Konstantin Shegunov wrote: > [CMake is] powerful, even to the point of being dangerous (I've seen > quite the abominations). It's know to be Turing-complete. 'Nuff said ;-). -- Matthew From enmarantispam at gmail.com Tue Oct 30 18:38:57 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue, 30 Oct 2018 20:38:57 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1797586.pj9EAoSRyV@tjmaciei-mobl1> <20181030165215.GA26349@troll08> Message-ID: > From my point of view qbs is doomed as long as qmake's alive. I would much rather this abomination died instead. I've switched to qbs when I got way too annoyed by how qmake does things and I've never been happier. On Tue, Oct 30, 2018 at 8:32 PM Pier Luigi Fiorini < pierluigi.fiorini at gmail.com> wrote: > Il giorno mar 30 ott 2018 alle ore 17:52 Oswald Buddenhagen < > Oswald.Buddenhagen at qt.io> ha scritto: > >> On Tue, Oct 30, 2018 at 09:10:27AM -0700, Thiago Macieira wrote: >> > Is it packaged in a Linux distribution? My requirements also included >> > continuously packaged for 2 years in at least 3 Linux distributions, >> > at the time of the Qt switch to the particular buildsystem. >> > >> it's been packaged for much longer and by more distros already, because >> it's part of qt creator for quite a while. i don't know whether all of >> them ship it as separate packages already, but the official messaging >> from us was that they *should*. >> >> > Distros started packaging it separately for some time now. > Before that, as you point out, it was packaged inside QtCreator. > > Debian: https://packages.debian.org/sid/qbs > Fedora: https://apps.fedoraproject.org/packages/qbs > Arch Linux: https://www.archlinux.org/packages/extra/x86_64/qbs/ > OpenSuSE: https://software.opensuse.org/package/qbs?search_term=qbs > > -- > https://liri.io > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwoehlke.floss at gmail.com Tue Oct 30 18:46:49 2018 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 30 Oct 2018 13:46:49 -0400 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181030171752.GE9915@troll08> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <20181030171752.GE9915@troll08> Message-ID: On 30/10/2018 13.17, Oswald Buddenhagen wrote: > it's much easier to make qbs generate **and even read** cmake > interface files than to re-architect cmake to make it, well, sane. (Emphasis added.) No, really, it isn't. A CMake interface file is Turing-complete and can do anything that CMake can do. In order to actually implement the ability to read CMake interface files (without corner cases), you basically have to *be* CMake. If you assume that you will only have to deal with some subset, you will be subject to breakage at any time. I would rather see CMake learn to read and output something more portable, e.g. CPS¹. (¹ https://mwoehlke.github.io/cps/) -- Matthew From Oswald.Buddenhagen at qt.io Tue Oct 30 19:25:03 2018 From: Oswald.Buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 30 Oct 2018 18:25:03 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <20181030171752.GE9915@troll08> Message-ID: <20181030182501.GF9915@troll08> On Tue, Oct 30, 2018 at 01:46:49PM -0400, Matthew Woehlke wrote: > On 30/10/2018 13.17, Oswald Buddenhagen wrote: > > it's much easier to make qbs generate **and even read** cmake > > interface files than to re-architect cmake to make it, well, sane. > (Emphasis added.) > > No, really, it isn't. > it is, despite the below. > A CMake interface file is Turing-complete and can do anything that > CMake can do. > yes, and when i looked a few days ago into the code cmake auto-generates, my jaw dropped. this is total insanity. > In order to actually implement the ability to read CMake interface > files (without corner cases), you basically have to *be* CMake. > in the most extreme case one could actually make a qbs plugin that links against the relevant cmake code. > If you assume that you will only have to deal with some subset, you > will be subject to breakage at any time. > yes, but that's not such a big deal, because most projects just use the auto-exports, and keeping up with changes to that isn't an extraordinarily challenging task. and manually covering the remaining 1% of packages that fail isn't a huge deal, either, esp. once the qbs community grows. and the whole thing would be only a "bridge technology" anyway. ^^ > I would rather see CMake learn to read and output something more > portable, e.g. CPS¹. > from a quick glance, this isn't all that bad, and in fact reflects the strongly declarative concepts i'm envisaging for qbs' interface files. From abbapoh at gmail.com Tue Oct 30 19:26:14 2018 From: abbapoh at gmail.com (=?utf-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Tue, 30 Oct 2018 19:26:14 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: <2248934.K6aZsiT3RL@tonks> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1797586.pj9EAoSRyV@tjmaciei-mobl1> <20181030165215.GA26349@troll08> <2248934.K6aZsiT3RL@tonks> Message-ID: <3C3D9ABC-68A1-4DDD-9B26-0BBB9DA421BB@gmail.com> Wow, hold on for a minute. I’ve been using a qbs package as a standalone leaf package (sudo aptitude install qbs) to build my projects. Also, self-built QBS package was commercially used to create several Debian packages back in 2013. > 30 окт. 2018 г., в 18:18, Lisandro Damián Nicanor Pérez Meyer написал(а): > > El martes, 30 de octubre de 2018 13:52:18 -03 Oswald Buddenhagen escribió: >> On Tue, Oct 30, 2018 at 09:10:27AM -0700, Thiago Macieira wrote: >>> Is it packaged in a Linux distribution? My requirements also included >>> continuously packaged for 2 years in at least 3 Linux distributions, >>> at the time of the Qt switch to the particular buildsystem. >> >> it's been packaged for much longer and by more distros already, because >> it's part of qt creator for quite a while. i don't know whether all of >> them ship it as separate packages already, but the official messaging >> from us was that they *should*. > > The first Debian upload was: > > qbs (1.2.2+dfsg-1) unstable; urgency=medium > > * Initial release (closes: #745095). > > -- Dmitry Shachnev Sat, 26 Jul 2014 23:28:44 +0400 > > As of today, a little more than 4 years, it has only two users (reverse > dependencies): qt creator and dewall. > > Considering yesterday's announce and the fact that qt creator ships a bundled > copy the only package stopping us from removing qbs from the archive is > dewall, so I don't think it will stay in the archive for much longer. > > > -- > The box said 'Requires Windows 95 or better'. So I installed Linux. > Anonymous > > Lisandro Damián Nicanor Pérez Meyer > http://perezmeyer.com.ar/ > http://perezmeyer.blogspot.com/ > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From edward.welbourne at qt.io Tue Oct 30 19:30:41 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 30 Oct 2018 18:30:41 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1797586.pj9EAoSRyV@tjmaciei-mobl1> <20181030165215.GA26349@troll08> , Message-ID: On Tue, Oct 30, 2018 at 8:32 PM Pier Luigi Fiorini wrote: >> From my point of view qbs is doomed as long as qmake's alive. NIkolai Marchenko (30 October 2018 18:38) replied: > I would much rather this abomination died instead. You are not alone. Unfortunately, the project has depended on it for several years, with the result that we have a support commitment that we can't simply abandon, much as we (especially those involved in supporting it) would like to. We have to make a graceful transition to something else first. The questions then are: what ? and: how soon can we get to the point where we can put qmake's death on our road-maps ? > I've switched to qbs when I got way too annoyed by how qmake does > things and I've never been happier. It's clear that QBS has great potential. Unfortunately, the corporation that initially supported its development does not see a way to monetise it, so is no longer willing to fund its development. It is available as open source code that others can develop and maintain, but it's only going to make it if others are willing to do most of the work. In some sense, the history of mixed signals - TQtC continued development but did little marketing and neglected important things like documentation - is a symptom of it being an experiment. Until management had a full understanding of where this lead, they let development explore the possibility that a better build system is worth investing in. Eventually they saw enough to make their decision and decided to bail. Some of us may not be persuaded that decision was for the best; but I'm not used to writing business plans, much less evaluating their viability, so I'm not going to try to tell them that their decision harms the interests of their share-holders, which is the only kind of argument I can expect the officers of a publicly-traded corporation to care about. Meanwhile, the Qt project gets to chose its build system. If we have a groundswell of support from outside TQtC that takes over development of QBS and makes it capable of serving as that build system, I think quite a lot of us shall be very happy to see it. Otherwise, CMake is the only candidate with a road-map to deliver tolerably soon, so there we go. Painful as its syntax is (I've begun reviewing the work for it), it's there, someone else is supporting it, and the expected time to the final demise of qmake does look shorter than our other options. Prove that wrong by volunteering to work on QBS, or come to terms with the non-ideal path we've landed on, Eddy. From mwoehlke.floss at gmail.com Tue Oct 30 19:47:43 2018 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 30 Oct 2018 14:47:43 -0400 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1797586.pj9EAoSRyV@tjmaciei-mobl1> <20181030165215.GA26349@troll08> Message-ID: <0ebb5af9-8688-e4d8-1491-e987641c2e87@gmail.com> On 30/10/2018 14.30, Edward Welbourne wrote: > Painful as [CMake's] syntax is (I've begun reviewing the work for it), it's > there, someone else is supporting it, and the expected time to the final > demise of qmake does look shorter than our other options. FWIW, I don't think anyone is praising CMake's syntax. The problem is finding a *viable* (and that includes *backwards-compatible*) plan to do something about it. If anyone can figure that out, I suspect CMake would be, ah, "highly receptive" :-). (I happen to think CMake is *overly* vilified, but I'm not going to claim it's free of warts, either.) -- Matthew From thiago.macieira at intel.com Tue Oct 30 20:01:59 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Oct 2018 12:01:59 -0700 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181030165215.GA26349@troll08> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1797586.pj9EAoSRyV@tjmaciei-mobl1> <20181030165215.GA26349@troll08> Message-ID: <1887510.eIDIQQHIpi@tjmaciei-mobl1> On Tuesday, 30 October 2018 09:52:18 PDT Oswald Buddenhagen wrote: > On Tue, Oct 30, 2018 at 09:10:27AM -0700, Thiago Macieira wrote: > > Is it packaged in a Linux distribution? My requirements also included > > continuously packaged for 2 years in at least 3 Linux distributions, > > at the time of the Qt switch to the particular buildsystem. > > it's been packaged for much longer and by more distros already, because > it's part of qt creator for quite a while. i don't know whether all of > them ship it as separate packages already, but the official messaging > from us was that they *should*. The requirement was not of the tool to be packaged. It was of one similar-complexity package *using* the buildsystem to be packaged for 2 years. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Oct 30 20:09:30 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Oct 2018 12:09:30 -0700 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <20181030164054.GC9915@troll08> Message-ID: <2905671.pIe2p5T7Nj@tjmaciei-mobl1> On Tuesday, 30 October 2018 10:26:15 PDT Konstantin Shegunov wrote: > From my point of view qbs is doomed as long as qmake's alive. Either kill > qmake and force the developers using Qt (or developing Qt) to use qbs That's not going to happen any more than our breaking source compatibility in a major way. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From enmarantispam at gmail.com Tue Oct 30 20:11:38 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue, 30 Oct 2018 22:11:38 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: <2905671.pIe2p5T7Nj@tjmaciei-mobl1> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <20181030164054.GC9915@troll08> <2905671.pIe2p5T7Nj@tjmaciei-mobl1> Message-ID: > That's not going to happen any more than our breaking source compatibility in a major way. You are breaking source compatibility in a major way with Qt6 ... ;) On Tue, Oct 30, 2018 at 10:09 PM Thiago Macieira wrote: > On Tuesday, 30 October 2018 10:26:15 PDT Konstantin Shegunov wrote: > > From my point of view qbs is doomed as long as qmake's alive. Either kill > > qmake and force the developers using Qt (or developing Qt) to use qbs > > That's not going to happen any more than our breaking source compatibility > in > a major way. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at weickelt.de Tue Oct 30 20:18:57 2018 From: richard at weickelt.de (Richard Weickelt) Date: Tue, 30 Oct 2018 20:18:57 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2483414.fFGr5Wv9AV@dragon> <20181030171118.GD9915@troll08> Message-ID: <403e4229-6ec7-e13b-1372-907c937eabc3@weickelt.de> On 30.10.2018 18:14, NIkolai Marchenko wrote: > For anyone interested in QBS survival, let's fill the sheet with QBS ecosystem. > Maybe if we show TQtC that people are actually using it they will reconsider. > > Post your projects  (and ones you know of) here: > > https://docs.google.com/spreadsheets/d/1CwXx2F1zuATYY3GGOTkFgDB9jwMPghf6az_RVOnskfk/edit#gid=0 FWIW: Typing "filetype:qbs site:github.com" in google gives me 622 results. Narrowing the search down by "Project filetype:qbs site:github.com" gives me 271 results. I don't know how to filter out duplicates nor forks of Qbs and QtCreator. I also don't know enough about search engines to see whether the user base of Qbs is growing or declining. From thiago.macieira at intel.com Tue Oct 30 20:19:27 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Oct 2018 12:19:27 -0700 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2905671.pIe2p5T7Nj@tjmaciei-mobl1> Message-ID: <3474294.Wz9aCAfvH3@tjmaciei-mobl1> On Tuesday, 30 October 2018 12:11:38 PDT NIkolai Marchenko wrote: > > That's not going to happen any more than our breaking source > > compatibility in > a major way. > > You are breaking source compatibility in a major way with Qt6 ... ;) No, we will break source compatibility in a minor way. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Oswald.Buddenhagen at qt.io Tue Oct 30 20:21:37 2018 From: Oswald.Buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 30 Oct 2018 19:21:37 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: <0ebb5af9-8688-e4d8-1491-e987641c2e87@gmail.com> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1797586.pj9EAoSRyV@tjmaciei-mobl1> <20181030165215.GA26349@troll08> <0ebb5af9-8688-e4d8-1491-e987641c2e87@gmail.com> Message-ID: <20181030192134.GG9915@troll08> On Tue, Oct 30, 2018 at 02:47:43PM -0400, Matthew Woehlke wrote: > On 30/10/2018 14.30, Edward Welbourne wrote: > > Painful as [CMake's] syntax is (I've begun reviewing the work for > > it), it's there, someone else is supporting it, and the expected > > time to the final demise of qmake does look shorter than our other > > options. > > FWIW, I don't think anyone is praising CMake's syntax. The problem is > finding a *viable* (and that includes *backwards-compatible*) plan to > do something about it. > > If anyone can figure that out, I suspect CMake would be, ah, "highly > receptive" :-). > as i already said to bill (@kitware) in person at the desktop summit in 2011, there is absolutely nothing they can do to make cmake sane without it ceasing to be cmake (and thus losing its ecosystem advantage). now, 7 years later, i can't help but observe that the evidence supports my assertion: while there have been various incremental improvemments (i'll happily admit that a reasonably simple "leaf" project file doesn't look outright atrocious any more), the horrors one faces beyond the basic stuff just aren't going away. and to be clear, it isn't *just* the syntax (though the fact that there is literally just one syntactical top-level construct - the "function call" with a free-form list of arguments - to express a touring-complete language *really* doesn't help), but also the higher-level project structure and how the language interacts with the backend. From enmarantispam at gmail.com Tue Oct 30 20:21:25 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue, 30 Oct 2018 22:21:25 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: <3474294.Wz9aCAfvH3@tjmaciei-mobl1> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2905671.pIe2p5T7Nj@tjmaciei-mobl1> <3474294.Wz9aCAfvH3@tjmaciei-mobl1> Message-ID: > No, we will break source compatibility in a minor way. I am not aware of what was the end result of QList discussion, but didn't you want to deprecate/majorly change that at some point? That alone would be rather huge. On Tue, Oct 30, 2018 at 10:19 PM Thiago Macieira wrote: > On Tuesday, 30 October 2018 12:11:38 PDT NIkolai Marchenko wrote: > > > That's not going to happen any more than our breaking source > > > > compatibility in > > a major way. > > > > You are breaking source compatibility in a major way with Qt6 ... ;) > > No, we will break source compatibility in a minor way. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.treat at qt.io Tue Oct 30 20:24:26 2018 From: adam.treat at qt.io (Adam Treat) Date: Tue, 30 Oct 2018 19:24:26 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: <3474294.Wz9aCAfvH3@tjmaciei-mobl1> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2905671.pIe2p5T7Nj@tjmaciei-mobl1> <3474294.Wz9aCAfvH3@tjmaciei-mobl1> Message-ID: <5de5f554-a843-277e-c8c8-fb3080eab45a@qt.io> Lars gave a keynote saying pretty much the same. Simply is not true that we are planning major source compatible breakage for Qt6 so let's stop saying that. On 10/30/2018 03:19 PM, Thiago Macieira wrote: > On Tuesday, 30 October 2018 12:11:38 PDT NIkolai Marchenko wrote: >> > That's not going to happen any more than our breaking source >> >> compatibility in >> a major way. >> >> You are breaking source compatibility in a major way with Qt6 ... ;) > No, we will break source compatibility in a minor way. > From Oswald.Buddenhagen at qt.io Tue Oct 30 20:29:46 2018 From: Oswald.Buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 30 Oct 2018 19:29:46 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: <1887510.eIDIQQHIpi@tjmaciei-mobl1> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1797586.pj9EAoSRyV@tjmaciei-mobl1> <20181030165215.GA26349@troll08> <1887510.eIDIQQHIpi@tjmaciei-mobl1> Message-ID: <20181030192944.GH9915@troll08> On Tue, Oct 30, 2018 at 12:01:59PM -0700, Thiago Macieira wrote: > The requirement was not of the tool to be packaged. > > It was of one similar-complexity package *using* the buildsystem to be > packaged for 2 years. > err, right. but quite frankly, i call foul on that one and some other items in your list. you had some frustrations as a packager, but that's just part of the job, and doesn't authorize you to impose requirements that make it basically impossible to employ qt as a bootstrapping device for a qbs ecosystem. From perezmeyer at gmail.com Tue Oct 30 20:31:58 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Tue, 30 Oct 2018 16:31:58 -0300 Subject: [Development] Build system for Qt 6 In-Reply-To: <3C3D9ABC-68A1-4DDD-9B26-0BBB9DA421BB@gmail.com> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2248934.K6aZsiT3RL@tonks> <3C3D9ABC-68A1-4DDD-9B26-0BBB9DA421BB@gmail.com> Message-ID: <5625546.9tlZlvl9sN@tonks> El martes, 30 de octubre de 2018 15:26:14 -03 Иван Комиссаров escribió: > Wow, hold on for a minute. > I’ve been using a qbs package as a standalone leaf package (sudo aptitude > install qbs) to build my projects. Also, self-built QBS package was > commercially used to create several Debian packages back in 2013. I can't count what's not in Debian proper. But the fact that in 4 years there is just one package in Debian's archive using qbs says a lot. Of course anyone can jump in to help maintain qbs and keep it in the archive. -- http://www.tiraecol.net/modules/comic/comic.php?content_id=162 Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From enmarantispam at gmail.com Tue Oct 30 20:49:44 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue, 30 Oct 2018 22:49:44 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: <5625546.9tlZlvl9sN@tonks> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2248934.K6aZsiT3RL@tonks> <3C3D9ABC-68A1-4DDD-9B26-0BBB9DA421BB@gmail.com> <5625546.9tlZlvl9sN@tonks> Message-ID: > But the fact that in 4 years there is just one package in Debian's archive using qbs says a lot. Unfortunately all it says is that QBS developers _really_ didn't care to advertise/document their system. it's no wonder there are no projects when the only thing you have to work off of is a bunch module references. I am not so annoyed at the decision to drop qbs as I am annoyed at the fact that it failed because it never was given a fair chance and just as things seemed to begin to improve(i.e. finally tutorial pages) they decide to drop it. Of course now those pages become irrelevant as no one will want to jump onto a dying system regardless of if it has documentation or not. On Tue, Oct 30, 2018 at 10:32 PM Lisandro Damián Nicanor Pérez Meyer < perezmeyer at gmail.com> wrote: > El martes, 30 de octubre de 2018 15:26:14 -03 Иван Комиссаров escribió: > > Wow, hold on for a minute. > > I’ve been using a qbs package as a standalone leaf package (sudo aptitude > > install qbs) to build my projects. Also, self-built QBS package was > > commercially used to create several Debian packages back in 2013. > > I can't count what's not in Debian proper. But the fact that in 4 years > there > is just one package in Debian's archive using qbs says a lot. > > Of course anyone can jump in to help maintain qbs and keep it in the > archive. > > -- > http://www.tiraecol.net/modules/comic/comic.php?content_id=162 > > Lisandro Damián Nicanor Pérez Meyer > http://perezmeyer.com.ar/ > http://perezmeyer.blogspot.com/ > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Oct 30 20:53:48 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Oct 2018 12:53:48 -0700 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181030192944.GH9915@troll08> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1887510.eIDIQQHIpi@tjmaciei-mobl1> <20181030192944.GH9915@troll08> Message-ID: <7072220.eW4KKezGqE@tjmaciei-mobl1> On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote: > On Tue, Oct 30, 2018 at 12:01:59PM -0700, Thiago Macieira wrote: > > The requirement was not of the tool to be packaged. > > > > It was of one similar-complexity package *using* the buildsystem to be > > packaged for 2 years. > > err, right. > > but quite frankly, i call foul on that one and some other items in your > list. you had some frustrations as a packager, but that's just part of > the job, and doesn't authorize you to impose requirements that make it > basically impossible to employ qt as a bootstrapping device for a qbs > ecosystem. The whole point was "let Qt not be the guinea pig". Show me that the tool can achieve what Qt needs for it to achieve and has enough of a track record of a community to ask for help. The requirements I outlined were about making that requirement more objective. The Qt community can of course disagree with me. The only enforcement I have is on myself: I said I will not work on Qt if it switches to a different build system until it meet my requirements. The 2-year-track record is included in that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Oct 30 20:54:52 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Oct 2018 12:54:52 -0700 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <3474294.Wz9aCAfvH3@tjmaciei-mobl1> Message-ID: <3043046.MMqQvb55Sv@tjmaciei-mobl1> On Tuesday, 30 October 2018 12:21:25 PDT NIkolai Marchenko wrote: > > No, we will break source compatibility in a minor way. > > I am not aware of what was the end result of QList discussion, but didn't > you want to deprecate/majorly change that at some point? > That alone would be rather huge. No, it wouldn't, because we'll provide a mostly or entirely source-compatible replacement. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andy.shaw at qt.io Tue Oct 30 21:46:40 2018 From: andy.shaw at qt.io (Andy Shaw) Date: Tue, 30 Oct 2018 20:46:40 +0000 Subject: [Development] HTTPS on lists.qt-project.org was Re: Build system for Qt 6 Message-ID: Just as a FYI, I have reported this on internally so hopefully this will get fixed shortly. Andy Development på vegne av Thiago Macieira skrev følgende den 30.10.2018, 17:22: On Tuesday, 30 October 2018 02:26:33 PDT Christian Gagneraud wrote: > https://lists.qt-project.org/mailman/listinfo/qbs gives me: > Secure Connection Failed The lists.qt-project.org HTTPS server is misconfigured (has been for a week or so) and is replying with non-encrypted HTTP on port 443. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Oswald.Buddenhagen at qt.io Tue Oct 30 21:47:00 2018 From: Oswald.Buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 30 Oct 2018 20:47:00 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: <7072220.eW4KKezGqE@tjmaciei-mobl1> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1887510.eIDIQQHIpi@tjmaciei-mobl1> <20181030192944.GH9915@troll08> <7072220.eW4KKezGqE@tjmaciei-mobl1> Message-ID: <20181030204658.GA6506@ugly> On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote: > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote: > > doesn't authorize you to impose requirements that make it basically > > impossible to employ qt as a bootstrapping device for a qbs > > ecosystem. > > The whole point was "let Qt not be the guinea pig". > you're essentially presuming that qbs is developed by a potentially incompetent external entity. > Show me that the tool can achieve what Qt needs for it to achieve > qtbase//wip/qbs2 speaks for itself. > and has enough of a track record of a community to ask for help. > it has enough "community" and intrinsic quality to get things going. asking for more is completely unreasonable before the community from which the tool originates shows committment by *relying* on it. and as the current situation shows, everyone who didn't trust the story was *right*. From kshegunov at gmail.com Tue Oct 30 21:48:30 2018 From: kshegunov at gmail.com (Konstantin Shegunov) Date: Tue, 30 Oct 2018 22:48:30 +0200 Subject: [Development] Build system for Qt 6 In-Reply-To: <2905671.pIe2p5T7Nj@tjmaciei-mobl1> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <20181030164054.GC9915@troll08> <2905671.pIe2p5T7Nj@tjmaciei-mobl1> Message-ID: On Tue, Oct 30, 2018 at 9:09 PM Thiago Macieira wrote: > On Tuesday, 30 October 2018 10:26:15 PDT Konstantin Shegunov wrote: > > From my point of view qbs is doomed as long as qmake's alive. Either kill > > qmake and force the developers using Qt (or developing Qt) to use qbs > > That's not going to happen any more than our breaking source compatibility > in > a major way. > Fair enough. As a consequence qbs gets rather limited exposure, thus it's not a priority for development. To make matters worse smaller user base means smaller amount of bugreports/fixes. Less fixes in turn leads to buggier/quirkier system leading to fewer people using it. And the circle is complete - unfortunate, but somewhat expected. -------------- next part -------------- An HTML attachment was scrubbed... URL: From enmarantispam at gmail.com Tue Oct 30 21:56:45 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue, 30 Oct 2018 23:56:45 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <20181030164054.GC9915@troll08> <2905671.pIe2p5T7Nj@tjmaciei-mobl1> Message-ID: > and has enough of a track record of a community to ask for help. You quite literally have the system's developer in house. Why do you even need to rely on the community so much? I'd understand if qbs was an external tool, but that's not the case. On Tue, Oct 30, 2018 at 11:49 PM Konstantin Shegunov wrote: > > > On Tue, Oct 30, 2018 at 9:09 PM Thiago Macieira > wrote: > >> On Tuesday, 30 October 2018 10:26:15 PDT Konstantin Shegunov wrote: >> > From my point of view qbs is doomed as long as qmake's alive. Either >> kill >> > qmake and force the developers using Qt (or developing Qt) to use qbs >> >> That's not going to happen any more than our breaking source >> compatibility in >> a major way. >> > > Fair enough. As a consequence qbs gets rather limited exposure, thus it's > not a priority for development. > To make matters worse smaller user base means smaller amount of > bugreports/fixes. Less fixes in turn leads to buggier/quirkier system > leading to fewer people using it. And the circle is complete - unfortunate, > but somewhat expected. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwoehlke.floss at gmail.com Tue Oct 30 22:06:44 2018 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 30 Oct 2018 17:06:44 -0400 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181030182501.GF9915@troll08> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <20181030171752.GE9915@troll08> <20181030182501.GF9915@troll08> Message-ID: <6d692097-14fc-95bc-c323-32af6f635197@gmail.com> On 30/10/2018 14.25, Oswald Buddenhagen wrote: > On Tue, Oct 30, 2018 at 01:46:49PM -0400, Matthew Woehlke wrote: >> In order to actually implement the ability to read CMake interface >> files (without corner cases), you basically have to *be* CMake. >> If you assume that you will only have to deal with some subset, you >> will be subject to breakage at any time. > > yes, but [...] the whole thing would be only a "bridge technology" > anyway. So why not jump straight to a better way of exchanging package information, and teach CMake to speak that? If you can produce such a system (which is exactly what CPS tries to do), I think CMake would be receptive. Why bother with an interim solution? (BTW, I'm hoping there will be some discussion along these lines at WG21 next week... At least there were two papers in the most recent mailing along these lines.) >> I would rather see CMake learn to read and output something more >> portable, e.g. CPS¹. > > from a quick glance, this isn't all that bad, and in fact reflects the > strongly declarative concepts i'm envisaging for qbs' interface files. Thanks :-). I've tried to make it plausible and address both likely edge cases and some issues that CMake currently does not handle well, while keeping it reasonably simple. It's mostly lacking implementation, and I haven't had the time/ability to do a lot more than write up the schema. Help would be much appreciated! -- Matthew From thiago.macieira at intel.com Tue Oct 30 22:07:16 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Oct 2018 14:07:16 -0700 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181030204658.GA6506@ugly> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <7072220.eW4KKezGqE@tjmaciei-mobl1> <20181030204658.GA6506@ugly> Message-ID: <1653559.CV2QjtXsQV@tjmaciei-mobl1> On Tuesday, 30 October 2018 13:47:00 PDT Oswald Buddenhagen wrote: > On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote: > > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote: > > > doesn't authorize you to impose requirements that make it basically > > > impossible to employ qt as a bootstrapping device for a qbs > > > ecosystem. > > > > The whole point was "let Qt not be the guinea pig". > > you're essentially presuming that qbs is developed by a potentially > incompetent external entity. No. However, I am asking for proof. > > Show me that the tool can achieve what Qt needs for it to achieve > > qtbase//wip/qbs2 speaks for itself. That's the guinea pig. I am asking for proof by seeing someone else adopt it. The tool is now several years old, it ought to have attracted *someone*. And even if it hasn't, there are a couple of years left until we switch for Qt. The community supporting this tool can find other projects of moderate complexity to work with and support. > > and has enough of a track record of a community to ask for help. > > it has enough "community" and intrinsic quality to get things going. I'm not disputing it has quality. But it lacks a specific community I called for: packagers. Tell me, has anyone tried to build that branch in the Boot2Qt context? > asking for more is completely unreasonable before the community from > which the tool originates shows committment by *relying* on it. and as > the current situation shows, everyone who didn't trust the story was > *right*. I disagree and I find it completely reasonable to ask. That's why I did so. And yes, they were right: if qbs is created for Qt alone, then they shouldn't rely on it. Hence the request to show that it can be used by others and that there's at least a modest community behind it. There has been enough time to get more adoption and there's still time left. So get someone else to adopt it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jeanmichael.celerier at gmail.com Tue Oct 30 22:14:27 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Tue, 30 Oct 2018 22:14:27 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: <1653559.CV2QjtXsQV@tjmaciei-mobl1> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <7072220.eW4KKezGqE@tjmaciei-mobl1> <20181030204658.GA6506@ugly> <1653559.CV2QjtXsQV@tjmaciei-mobl1> Message-ID: OpenFrameworks, a fairly used creative coding framework has been using QBS for a few years. My experience with it in that context has been quite negative - a year ago it would break on every new QBS release, so you had to use an exact QBS version if you wanted to use OFX (exhibit A: https://forum.openframeworks.cc/t/qtcreator-v4-3-1-qbs-problem/27214), so multiple people I know have ended up porting OF to use CMake instead : https://github.com/ofnode/of which frankly worked better and with less breakage. As always, mileage may vary. ------- Jean-Michaël Celerier http://www.jcelerier.name On Tue, Oct 30, 2018 at 10:07 PM Thiago Macieira wrote: > On Tuesday, 30 October 2018 13:47:00 PDT Oswald Buddenhagen wrote: > > On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote: > > > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote: > > > > doesn't authorize you to impose requirements that make it basically > > > > impossible to employ qt as a bootstrapping device for a qbs > > > > ecosystem. > > > > > > The whole point was "let Qt not be the guinea pig". > > > > you're essentially presuming that qbs is developed by a potentially > > incompetent external entity. > > No. However, I am asking for proof. > > > > Show me that the tool can achieve what Qt needs for it to achieve > > > > qtbase//wip/qbs2 speaks for itself. > > That's the guinea pig. I am asking for proof by seeing someone else adopt > it. > The tool is now several years old, it ought to have attracted *someone*. > > And even if it hasn't, there are a couple of years left until we switch > for > Qt. The community supporting this tool can find other projects of moderate > complexity to work with and support. > > > > and has enough of a track record of a community to ask for help. > > > > it has enough "community" and intrinsic quality to get things going. > > I'm not disputing it has quality. But it lacks a specific community I > called > for: packagers. > > Tell me, has anyone tried to build that branch in the Boot2Qt context? > > > asking for more is completely unreasonable before the community from > > which the tool originates shows committment by *relying* on it. and as > > the current situation shows, everyone who didn't trust the story was > > *right*. > > I disagree and I find it completely reasonable to ask. That's why I did so. > > And yes, they were right: if qbs is created for Qt alone, then they > shouldn't > rely on it. Hence the request to show that it can be used by others and > that > there's at least a modest community behind it. > > There has been enough time to get more adoption and there's still time > left. > So get someone else to adopt it. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From enmarantispam at gmail.com Tue Oct 30 22:15:46 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Wed, 31 Oct 2018 00:15:46 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: <1653559.CV2QjtXsQV@tjmaciei-mobl1> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <7072220.eW4KKezGqE@tjmaciei-mobl1> <20181030204658.GA6506@ugly> <1653559.CV2QjtXsQV@tjmaciei-mobl1> Message-ID: > I'm not disputing it has quality. But it lacks a specific community I called for: packagers. Maybe, but then, you've spent quite some time developing the system ,what's stopping you from reaching out to suitable projects that involve packaging to help them set up their project with QBS? Instead of stating your desire to pull the plug and basically discouraging such a community from ever appearing. On Wed, Oct 31, 2018 at 12:07 AM Thiago Macieira wrote: > On Tuesday, 30 October 2018 13:47:00 PDT Oswald Buddenhagen wrote: > > On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote: > > > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote: > > > > doesn't authorize you to impose requirements that make it basically > > > > impossible to employ qt as a bootstrapping device for a qbs > > > > ecosystem. > > > > > > The whole point was "let Qt not be the guinea pig". > > > > you're essentially presuming that qbs is developed by a potentially > > incompetent external entity. > > No. However, I am asking for proof. > > > > Show me that the tool can achieve what Qt needs for it to achieve > > > > qtbase//wip/qbs2 speaks for itself. > > That's the guinea pig. I am asking for proof by seeing someone else adopt > it. > The tool is now several years old, it ought to have attracted *someone*. > > And even if it hasn't, there are a couple of years left until we switch > for > Qt. The community supporting this tool can find other projects of moderate > complexity to work with and support. > > > > and has enough of a track record of a community to ask for help. > > > > it has enough "community" and intrinsic quality to get things going. > > I'm not disputing it has quality. But it lacks a specific community I > called > for: packagers. > > Tell me, has anyone tried to build that branch in the Boot2Qt context? > > > asking for more is completely unreasonable before the community from > > which the tool originates shows committment by *relying* on it. and as > > the current situation shows, everyone who didn't trust the story was > > *right*. > > I disagree and I find it completely reasonable to ask. That's why I did so. > > And yes, they were right: if qbs is created for Qt alone, then they > shouldn't > rely on it. Hence the request to show that it can be used by others and > that > there's at least a modest community behind it. > > There has been enough time to get more adoption and there's still time > left. > So get someone else to adopt it. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abbapoh at gmail.com Tue Oct 30 22:25:10 2018 From: abbapoh at gmail.com (=?utf-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Tue, 30 Oct 2018 22:25:10 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <7072220.eW4KKezGqE@tjmaciei-mobl1> <20181030204658.GA6506@ugly> <1653559.CV2QjtXsQV@tjmaciei-mobl1> Message-ID: Huh? Looks like they are supporting every build system alive https://github.com/openframeworks/openFrameworks/tree/patch-release/libs/openFrameworksCompiled/project > 30 окт. 2018 г., в 22:14, Jean-Michaël Celerier написал(а): > > OpenFrameworks, a fairly used creative coding framework has been using QBS for a few years. My experience with it in that context has been quite negative - a year ago it would break on every new QBS release, so you had to use an exact QBS version if you wanted to use OFX (exhibit A: https://forum.openframeworks.cc/t/qtcreator-v4-3-1-qbs-problem/27214 ), so multiple people I know have ended up porting OF to use CMake instead : https://github.com/ofnode/of which frankly worked better and with less breakage. As always, mileage may vary. > > > ------- > Jean-Michaël Celerier > http://www.jcelerier.name > > On Tue, Oct 30, 2018 at 10:07 PM Thiago Macieira > wrote: > On Tuesday, 30 October 2018 13:47:00 PDT Oswald Buddenhagen wrote: > > On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote: > > > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote: > > > > doesn't authorize you to impose requirements that make it basically > > > > impossible to employ qt as a bootstrapping device for a qbs > > > > ecosystem. > > > > > > The whole point was "let Qt not be the guinea pig". > > > > you're essentially presuming that qbs is developed by a potentially > > incompetent external entity. > > No. However, I am asking for proof. > > > > Show me that the tool can achieve what Qt needs for it to achieve > > > > qtbase//wip/qbs2 speaks for itself. > > That's the guinea pig. I am asking for proof by seeing someone else adopt it. > The tool is now several years old, it ought to have attracted *someone*. > > And even if it hasn't, there are a couple of years left until we switch for > Qt. The community supporting this tool can find other projects of moderate > complexity to work with and support. > > > > and has enough of a track record of a community to ask for help. > > > > it has enough "community" and intrinsic quality to get things going. > > I'm not disputing it has quality. But it lacks a specific community I called > for: packagers. > > Tell me, has anyone tried to build that branch in the Boot2Qt context? > > > asking for more is completely unreasonable before the community from > > which the tool originates shows committment by *relying* on it. and as > > the current situation shows, everyone who didn't trust the story was > > *right*. > > I disagree and I find it completely reasonable to ask. That's why I did so. > > And yes, they were right: if qbs is created for Qt alone, then they shouldn't > rely on it. Hence the request to show that it can be used by others and that > there's at least a modest community behind it. > > There has been enough time to get more adoption and there's still time left. > So get someone else to adopt it. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Oct 30 22:27:05 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Oct 2018 14:27:05 -0700 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: <2217724.thNANPicTR@tjmaciei-mobl1> On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote: > > and has enough of a track record of a community to ask for help. > > You quite literally have the system's developer in house. > Why do you even need to rely on the community so much? > I'd understand if qbs was an external tool, but that's not the case. Because it's a sign of maturity. If the only people who can solve any problem are the handful of people who work for the company that developed it, we have a serious Bus Factor problem. And guess what? It's exactly what's happening right now. Ossi and several others are right that qbs was never given a proper chance. It hasn't. The only thing I'm criticising is that its proper chance involves Qt being the guinea pig. Find someone else instead and grow your community. Get track record for building, cross-compiling, working with weird set ups, containerised build environments, build farms, etc. Don't ask Qt to switch to it until you've done that work. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Oct 30 22:32:28 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Oct 2018 14:32:28 -0700 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1653559.CV2QjtXsQV@tjmaciei-mobl1> Message-ID: <5448738.fRFqIuEJyf@tjmaciei-mobl1> On Tuesday, 30 October 2018 14:15:46 PDT NIkolai Marchenko wrote: > Maybe, but then, you've spent quite some time developing the system ,what's > stopping you from reaching out to suitable projects that involve packaging > to help them set up their project with QBS? > Instead of stating your desire to pull the plug and basically discouraging > such a community from ever appearing. I'm assuming that the "you" in that question is The Qt Company, not me specifically. I don't know why they didn't. But if you meant me, I'm not qualified to do it myself, but I *did* ask the developers to do that. My email from July was that call for action: among other things, get involved with the packager community and show that your tool works for their usecases without major side-effects. Looks like The Qt Company analysed how much effort that would be and decided that it wasn't worth the investment. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From enmarantispam at gmail.com Tue Oct 30 22:33:41 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Wed, 31 Oct 2018 00:33:41 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: <2217724.thNANPicTR@tjmaciei-mobl1> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2217724.thNANPicTR@tjmaciei-mobl1> Message-ID: > Don't ask Qt to switch to it until you've done that work. Tbh, we wouldn't if this post hasn't almost stated that you are pulling the plug. As I saw it: qbs folks have finally started doing the correct thiing (that is - tutorials) and what you are speaking of had a chance to happen. But as of right now no amount of tutorials will change the fact that reluctance to swtich to a new system will become reluctance to change to a _stillborn_ system. By pulling the plug Lars ensures that qbs has not had a chance and _will not have_ that chance. Oh, and also, maybe we need a separate post about this issue: "Should QBS stay?" Or something like that so that it's visible on it's own and more people jump into the discussion. So far we have quite a few projects in the spreadsheet I created. I wonder how many more will be added. On Wed, Oct 31, 2018 at 12:27 AM Thiago Macieira wrote: > On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote: > > > and has enough of a track record of a community to ask for help. > > > > You quite literally have the system's developer in house. > > Why do you even need to rely on the community so much? > > I'd understand if qbs was an external tool, but that's not the case. > > Because it's a sign of maturity. If the only people who can solve any > problem > are the handful of people who work for the company that developed it, we > have > a serious Bus Factor problem. And guess what? It's exactly what's > happening > right now. > > Ossi and several others are right that qbs was never given a proper > chance. It > hasn't. > > The only thing I'm criticising is that its proper chance involves Qt being > the > guinea pig. Find someone else instead and grow your community. Get track > record for building, cross-compiling, working with weird set ups, > containerised build environments, build farms, etc. Don't ask Qt to switch > to > it until you've done that work. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeanmichael.celerier at gmail.com Tue Oct 30 22:36:52 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean-Micha=c3=abl_Celerier?=) Date: Tue, 30 Oct 2018 22:36:52 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <7072220.eW4KKezGqE@tjmaciei-mobl1> <20181030204658.GA6506@ugly> <1653559.CV2QjtXsQV@tjmaciei-mobl1> Message-ID: Yes, it's a big requirement for a lot of people using OFX that they be able to use also Xcode and / or Visual Studio. But QBS was at some point (not sure if still the case) the main one. On 30/10/2018 22:25, Иван Комиссаров wrote: > Huh? Looks like they are supporting every build system alive > https://github.com/openframeworks/openFrameworks/tree/patch-release/libs/openFrameworksCompiled/project > >> 30 окт. 2018 г., в 22:14, Jean-Michaël Celerier >> > > написал(а): >> >> OpenFrameworks, a fairly used creative coding framework has been >> using QBS for a few years. My experience with it in that context has >> been quite negative - a year ago it would break on every new QBS >> release, so you had to use an exact QBS version if you wanted to use >> OFX (exhibit A: >> https://forum.openframeworks.cc/t/qtcreator-v4-3-1-qbs-problem/27214), >> so multiple people I know have ended up porting OF to use CMake >> instead : https://github.com/ofnode/of which frankly worked better >> and with less breakage. As always, mileage may vary. >> >> >> ------- >> Jean-Michaël Celerier >> http://www.jcelerier.name >> >> >> On Tue, Oct 30, 2018 at 10:07 PM Thiago Macieira >> > wrote: >> >> On Tuesday, 30 October 2018 13:47:00 PDT Oswald Buddenhagen wrote: >> > On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote: >> > > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen >> wrote: >> > > > doesn't authorize you to impose requirements that make it >> basically >> > > > impossible to employ qt as a bootstrapping device for a qbs >> > > > ecosystem. >> > > >> > > The whole point was "let Qt not be the guinea pig". >> > >> > you're essentially presuming that qbs is developed by a potentially >> > incompetent external entity. >> >> No. However, I am asking for proof. >> >> > > Show me that the tool can achieve what Qt needs for it to achieve >> > >> > qtbase//wip/qbs2 speaks for itself. >> >> That's the guinea pig. I am asking for proof by seeing someone >> else adopt it. >> The tool is now several years old, it ought to have attracted >> *someone*. >> >> And even if it hasn't, there are a couple of years left until we >> switch for >> Qt. The community supporting this tool can find other projects of >> moderate >> complexity to work with and support. >> >> > > and has enough of a track record of a community to ask for help. >> > >> > it has enough "community" and intrinsic quality to get things >> going. >> >> I'm not disputing it has quality. But it lacks a specific >> community I called >> for: packagers. >> >> Tell me, has anyone tried to build that branch in the Boot2Qt >> context? >> >> > asking for more is completely unreasonable before the community >> from >> > which the tool originates shows committment by *relying* on it. >> and as >> > the current situation shows, everyone who didn't trust the >> story was >> > *right*. >> >> I disagree and I find it completely reasonable to ask. That's why >> I did so. >> >> And yes, they were right: if qbs is created for Qt alone, then >> they shouldn't >> rely on it. Hence the request to show that it can be used by >> others and that >> there's at least a modest community behind it. >> >> There has been enough time to get more adoption and there's still >> time left. >> So get someone else to adopt it. >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >>   Software Architect - Intel Open Source Technology Center >> >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Oct 30 22:44:03 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Oct 2018 14:44:03 -0700 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2217724.thNANPicTR@tjmaciei-mobl1> Message-ID: <1833828.G43E4eZFvL@tjmaciei-mobl1> On Tuesday, 30 October 2018 14:33:41 PDT NIkolai Marchenko wrote: > Tbh, we wouldn't if this post hasn't almost stated that you are pulling the > plug. > As I saw it: qbs folks have finally started doing the correct thiing (that > is - tutorials) and what you are speaking of had a chance to happen. > But as of right now no amount of tutorials will change the fact that > reluctance to swtich to a new system will become reluctance to change to a > _stillborn_ system. Then reverse that with action. It's an open source project and people can contribute to it, inside the Qt Project governance even. TQtC employees can contribute in their free time too, maybe even in Creative Fridays if they still have that. It only appears TQtC decided not to invest direct money. By the way, tmake was also opensourced when Trolltech decided to stop using it. http://tmake.sourceforge.net/ [We changed the "tmake" markers in the source to "qmake" in Jan 2012 - see 78a4c46842975f23cd0d9518eca8b341abbda0b5] > Oh, and also, maybe we need a separate post about this issue: "Should QBS > stay?" Sure, go ahead and gather your contributors. I still think qbs was/is a great idea. It's only lacking maturity. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From chgans at gmail.com Tue Oct 30 22:44:43 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Wed, 31 Oct 2018 10:44:43 +1300 Subject: [Development] Build system for Qt 6 In-Reply-To: <2217724.thNANPicTR@tjmaciei-mobl1> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2217724.thNANPicTR@tjmaciei-mobl1> Message-ID: On Wed, 31 Oct 2018 at 10:27, Thiago Macieira wrote: > On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote: > The only thing I'm criticising is that its proper chance involves Qt being the > guinea pig. Find someone else instead and grow your community. Get track > record for building, cross-compiling, working with weird set ups, > containerised build environments, build farms, etc. Don't ask Qt to switch to > it until you've done that work. !?! What make you think qbs cannot be used in such environments?That all very basic stuff to me. - cross-compiling: Qbs support *out of the box* all "standard" OS *and* "standard" toolchains. - working with weird set ups: what does that even mean? That a very vague statement. - containerised build: any build system can run in a container, that's orthogonal. - build farms: Against what is the problem with build farm, i don't get it. - etc: again, can you elaborate? that's very vague. I've used Qbs to build a Desktop SW for Windows + MacOS + Linux, all producing platform specific installers. It was a breeze. I've used it to build a 1.5 million SLOC SW, with complex build matrix. The only reason we dropped it, was because of lack of integration: QtCreator is the only IDE that knows Qbs, as i reported on Qbs mailing long time ago, Qbs won't take off without XCode, Visual Stidio, Visual Code, Eclipse, ... integration. And, so far, we failed at switching to CMake, the build matrix is too complex. Chris From enmarantispam at gmail.com Tue Oct 30 22:44:55 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Wed, 31 Oct 2018 00:44:55 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <7072220.eW4KKezGqE@tjmaciei-mobl1> <20181030204658.GA6506@ugly> <1653559.CV2QjtXsQV@tjmaciei-mobl1> Message-ID: Tbh, as I see it: qbs is mostly usable now. The only thing it needs to stay afloat from now on and have a chance is promise of support for it + qt6 in qt creator. Is that really that hard to do? On Wed, Oct 31, 2018 at 12:37 AM Jean-Michaël Celerier < jeanmichael.celerier at gmail.com> wrote: > Yes, it's a big requirement for a lot of people using OFX that they be > able to use also Xcode and / or Visual Studio. But QBS was at some point > (not sure if still the case) the main one. > On 30/10/2018 22:25, Иван Комиссаров wrote: > > Huh? Looks like they are supporting every build system alive > https://github.com/openframeworks/openFrameworks/tree/patch-release/libs/openFrameworksCompiled/project > > 30 окт. 2018 г., в 22:14, Jean-Michaël Celerier < > jeanmichael.celerier at gmail.com> написал(а): > > OpenFrameworks, a fairly used creative coding framework has been using QBS > for a few years. My experience with it in that context has been quite > negative - a year ago it would break on every new QBS release, so you had > to use an exact QBS version if you wanted to use OFX (exhibit A: > https://forum.openframeworks.cc/t/qtcreator-v4-3-1-qbs-problem/27214), so > multiple people I know have ended up porting OF to use CMake instead : > https://github.com/ofnode/of which frankly worked better and with less > breakage. As always, mileage may vary. > > > ------- > Jean-Michaël Celerier > http://www.jcelerier.name > > > On Tue, Oct 30, 2018 at 10:07 PM Thiago Macieira < > thiago.macieira at intel.com> wrote: > >> On Tuesday, 30 October 2018 13:47:00 PDT Oswald Buddenhagen wrote: >> > On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote: >> > > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote: >> > > > doesn't authorize you to impose requirements that make it basically >> > > > impossible to employ qt as a bootstrapping device for a qbs >> > > > ecosystem. >> > > >> > > The whole point was "let Qt not be the guinea pig". >> > >> > you're essentially presuming that qbs is developed by a potentially >> > incompetent external entity. >> >> No. However, I am asking for proof. >> >> > > Show me that the tool can achieve what Qt needs for it to achieve >> > >> > qtbase//wip/qbs2 speaks for itself. >> >> That's the guinea pig. I am asking for proof by seeing someone else adopt >> it. >> The tool is now several years old, it ought to have attracted *someone*. >> >> And even if it hasn't, there are a couple of years left until we switch >> for >> Qt. The community supporting this tool can find other projects of >> moderate >> complexity to work with and support. >> >> > > and has enough of a track record of a community to ask for help. >> > >> > it has enough "community" and intrinsic quality to get things going. >> >> I'm not disputing it has quality. But it lacks a specific community I >> called >> for: packagers. >> >> Tell me, has anyone tried to build that branch in the Boot2Qt context? >> >> > asking for more is completely unreasonable before the community from >> > which the tool originates shows committment by *relying* on it. and as >> > the current situation shows, everyone who didn't trust the story was >> > *right*. >> >> I disagree and I find it completely reasonable to ask. That's why I did >> so. >> >> And yes, they were right: if qbs is created for Qt alone, then they >> shouldn't >> rely on it. Hence the request to show that it can be used by others and >> that >> there's at least a modest community behind it. >> >> There has been enough time to get more adoption and there's still time >> left. >> So get someone else to adopt it. >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Oswald.Buddenhagen at qt.io Tue Oct 30 22:51:01 2018 From: Oswald.Buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 30 Oct 2018 21:51:01 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: <6d692097-14fc-95bc-c323-32af6f635197@gmail.com> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <20181030171752.GE9915@troll08> <20181030182501.GF9915@troll08> <6d692097-14fc-95bc-c323-32af6f635197@gmail.com> Message-ID: <20181030215059.GA11838@ugly> On Tue, Oct 30, 2018 at 05:06:44PM -0400, Matthew Woehlke wrote: > On 30/10/2018 14.25, Oswald Buddenhagen wrote: > > On Tue, Oct 30, 2018 at 01:46:49PM -0400, Matthew Woehlke wrote: > >> In order to actually implement the ability to read CMake interface > >> files (without corner cases), you basically have to *be* CMake. > >> If you assume that you will only have to deal with some subset, you > >> will be subject to breakage at any time. > > > > yes, but [...] the whole thing would be only a "bridge technology" > > anyway. > > So why not jump straight to a better way of exchanging package > information, and teach CMake to speak that? If you can produce such a > system (which is exactly what CPS tries to do), I think CMake would be > receptive. Why bother with an interim solution? > i would be all for it. not sure the message "would you mind accepting that patch? it's just a bit more maintenance work for you, and it would make it easier for everyone else to break your quasi-monopoly and ultimately make your tool obsolete ..." would be *that* easy to sell, though. :D > >> I would rather see CMake learn to read and output something more > >> portable, e.g. CPS¹. > > > > from a quick glance, this isn't all that bad, and in fact reflects the > > strongly declarative concepts i'm envisaging for qbs' interface files. > > Thanks :-). I've tried to make it plausible and address both likely edge > cases and some issues that CMake currently does not handle well, while > keeping it reasonably simple. It's mostly lacking implementation, and I > haven't had the time/ability to do a lot more than write up the schema. > Help would be much appreciated! > for starters just some food for thought: QBS-995 should be implementable on top of it. if you want to go full monty, QBS-942 is your target. one thing i noticed is that you multiplex build variants and other stuff into a single file. this is not helpful for packaging. after much thinking about the matter, i concluded that the interface files should correspond to "atomic linkable entities", which essentially means actual libraries - not one interface to describe all build variants, and not one interface to describe each architecture variant within a multi-arch library. any aggregation of (however) related interfaces should happen on the consumer side (in as far as necessary at all). this is actually closely related to QBS-995. From enmarantispam at gmail.com Tue Oct 30 22:54:07 2018 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Wed, 31 Oct 2018 00:54:07 +0300 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <7072220.eW4KKezGqE@tjmaciei-mobl1> <20181030204658.GA6506@ugly> <1653559.CV2QjtXsQV@tjmaciei-mobl1> Message-ID: Even the initial support for Qt6 will already make community based efforts more likely since they will at least have something to work with. But if QBS support in QtCreator is dropped as Qt6 releases there is little to no chance of anyone picking it up as he task might just be too large. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chgans at gmail.com Tue Oct 30 22:57:01 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Wed, 31 Oct 2018 10:57:01 +1300 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: Hi Lars, On Tue, 30 Oct 2018 at 23:42, Lars Knoll wrote: > > On 30 Oct 2018, at 05:00, Christian Gagneraud wrote: > > On Tue, 30 Oct 2018 at 01:17, Lars Knoll wrote: > > Then why spend energy/money to fix something that is broken by design? > > (Again, that is a personal opinion, if needed to say) > > As I said in my email, I unfortunately don’t see a way how The Qt Company can push Qbs forward. It was a difficult decision because I very much like the ideas and the technology used in Qbs. > > From the perspective of a company, we have to justify investments we do, and they have to make sense not only from a perspective of being cool technology, but also how they can in the end generate business for us. In addition, there’s always the question, what we then can’t do (because the total money we can invest in R&D is limited). > > Looking at the fact, that we can’t earn money on a build system and that it would require quite a lot of funding to make it more than a niche product it doesn’t make sense to pursue it further. Instead we would rather use the money to improve Qt and Qt Creator. This doesn't add up, why did you develop and still develop and maintain 'coin' then? You're not making money with it. It's costing you (a lot?) and is a critical part of your QA infra. > > - Did Jake left the QtC due to your early decision to drop qbs? ( I > > personally do think that the decision was taken long time ago) > > The decision to not continue to develop Qbs was done very recently. It doesn’t make sense to make a decision and then not take actions. Whatever the reasons Jake left, they have nothing to do with this. I believe you. Thanks, Chris From thiago.macieira at intel.com Tue Oct 30 23:08:32 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Oct 2018 15:08:32 -0700 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2217724.thNANPicTR@tjmaciei-mobl1> Message-ID: <2785213.8PD2uIGTjk@tjmaciei-mobl1> On Tuesday, 30 October 2018 14:44:43 PDT Christian Gagneraud wrote: > On Wed, 31 Oct 2018 at 10:27, Thiago Macieira wrote: > > On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote: > > The only thing I'm criticising is that its proper chance involves Qt being > > the guinea pig. Find someone else instead and grow your community. Get > > track record for building, cross-compiling, working with weird set ups, > > containerised build environments, build farms, etc. Don't ask Qt to switch > > to it until you've done that work. > > !?! > What make you think qbs cannot be used in such environments?That all I didn't say it can't. I'm saying I want proof that it can, by having other projects adopt the solution and there being track record of it. > very basic stuff to me. > - cross-compiling: Qbs support *out of the box* all "standard" OS > *and* "standard" toolchains. > - working with weird set ups: what does that even mean? That a very > vague statement. See the July email for more details. > - containerised build: any build system can run in a container, that's > orthogonal. Until you run into trouble. Example of what I literally had a problem with in the last 30 minutes: Maven. [ERROR] Failed to execute goal on project hadoop-auth: Could not resolve dependencies for project org.apache.hadoop:hadoop-auth:jar:2.8.5: Failed to collect dependencies at com.nimbusds:nimbus-jose-jwt:jar:4.41.1: Failed to read artifact descriptor for com.nimbusds:nimbus-jose-jwt:jar:4.41.1: Could not transfer artifact com.nimbusds:nimbus-jose-jwt:pom:4.41.1 from/to apache.snapshots.https (https://repository.apache.org/content/repositories/ snapshots): repository.apache.org: No address associated with hostname -> [Help 1] Who do I turn to for help? A quick set of Google queries did not result in an answer on how to properly populate the dependencies for this thing (Apache Hadoop) . > - build farms: Against what is the problem with build farm, i don't get it. There's no problem until there's a problem. Can you point me to something that uses qbs to build getting built in a Linux distribution's build farm? I'd like to know that it's been properly tested. It's small things like libraries ending up in /usr/lib64 instead of /usr/lib. Some build systems do that automatically for you; with some others you can get it wrong. And here's the buildsystem that failed to install libraries in the right place this morning: CMake. > - etc: again, can you elaborate? that's very vague. I did, three months ago. > I've used Qbs to build a Desktop SW for Windows + MacOS + Linux, all > producing platform specific installers. > It was a breeze. > I've used it to build a 1.5 million SLOC SW, with complex build > matrix. Great. That's good track record. Now get 3 Linux distributions to package it. > The only reason we dropped it, was because of lack of > integration: > QtCreator is the only IDE that knows Qbs, as i reported on Qbs mailing > long time ago, Qbs won't take off without XCode, Visual Stidio, Visual > Code, Eclipse, ... integration. > And, so far, we failed at switching to CMake, the build matrix is too > complex. I didn't call for IDE support in my email. Tobias, in a reply to it, did. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Oct 30 23:11:19 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Oct 2018 15:11:19 -0700 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> Message-ID: <5668949.DP5fSAXzsh@tjmaciei-mobl1> On Tuesday, 30 October 2018 14:57:01 PDT Christian Gagneraud wrote: > > Looking at the fact, that we can’t earn money on a build system and that > > it would require quite a lot of funding to make it more than a niche > > product it doesn’t make sense to pursue it further. Instead we would > > rather use the money to improve Qt and Qt Creator. > This doesn't add up, why did you develop and still develop and > maintain 'coin' then? > You're not making money with it. It's costing you (a lot?) and is a > critical part of your QA infra. I think the answer is simple: none of the alternatives worked. COIN is not the first CI system we've had, it's actually the third. I don't remember a discussion on the benefits and drawbacks of similar solutions (like Jenkins) at the time COIN was adopted. There may have been an analysis done inside TQtC I am not aware of (mostly because I'm not interested in). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Oct 31 05:16:41 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Oct 2018 21:16:41 -0700 Subject: [Development] CI machines out of disk space Message-ID: <6219171.anQ2oEyD7U@tjmaciei-mobl1> https://testresults.qt.io/logs/qt/qtbase/ 4d1c701336289c6c70c86b1bdea0324214a5687a/ LinuxUbuntu_18_04x86_64LinuxQEMUarmv7GCCqtci-linux-Ubuntu-18.04-x86_64- ea77a2DeveloperBuild_DisableTests/2a48a3b7dcb9652b1532a3ad14de7580b5b9b1ee/ build_1542285435/log.txt.gz agent:2018/10/31 03:51:26 build.go:193: {standard input}: Assembler messages: agent:2018/10/31 03:51:26 build.go:193: {standard input}: Fatal error: can't write 76 bytes to section .text of .obj/qgraphicssceneindex.o because: 'No space left on device' -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From apoenitz at t-online.de Wed Oct 31 06:59:57 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Wed, 31 Oct 2018 06:59:57 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: <1833828.G43E4eZFvL@tjmaciei-mobl1> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2217724.thNANPicTR@tjmaciei-mobl1> <1833828.G43E4eZFvL@tjmaciei-mobl1> Message-ID: <20181031055957.GA24580@klara.mpi.htwm.de> On Tue, Oct 30, 2018 at 02:44:03PM -0700, Thiago Macieira wrote: > On Tuesday, 30 October 2018 14:33:41 PDT NIkolai Marchenko wrote: > > Tbh, we wouldn't if this post hasn't almost stated that you are pulling the > > plug. > > As I saw it: qbs folks have finally started doing the correct thiing (that > > is - tutorials) and what you are speaking of had a chance to happen. > > But as of right now no amount of tutorials will change the fact that > > reluctance to swtich to a new system will become reluctance to change to a > > _stillborn_ system. > > Then reverse that with action. It's an open source project and people can > contribute to it, inside the Qt Project governance even. TQtC employees can > contribute in their free time too, maybe even in Creative Fridays if they > still have that. > > [...] > > > Oh, and also, maybe we need a separate post about this issue: "Should QBS > > stay?" > > Sure, go ahead and gather your contributors. I still think qbs was/is a great > idea. It's only lacking maturity. Ok. Let me bite. In <2217724.thNANPicTR at tjmaciei-mobl1> you stated "Ossi and several others are right that qbs was never given a proper chance. It hasn't" Above you stated that contributions to QBS could even happen inside the Qt Project. Active part of "giving [some piece of software] a chance" is promoting it on some webpage. Where would a QBS-promoting webpage be located? qt-project.org ? Oops. Andre' From bogdan.vatra at kdab.com Wed Oct 31 06:38:44 2018 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Wed, 31 Oct 2018 07:38:44 +0200 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181030171118.GD9915@troll08> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2483414.fFGr5Wv9AV@dragon> <20181030171118.GD9915@troll08> Message-ID: <3174200.alS1aoj13T@dragon> Hi, În ziua de marți, 30 octombrie 2018, la 19:11:20 EET, Oswald Buddenhagen a scris: > On Tue, Oct 30, 2018 at 01:16:43PM +0200, Bogdan Vatra wrote: > > c.2) back then, none of the existing build system could deliver enough > > information to IDEs to enable prefect code completion (e.g. include > > paths, defines, compiler flags, etc.) > > ... > > c.2) Incomplete! A while ago, I created a QBS plugin for KDevelop[1] > > and I found some problems, see how QBS developers treat them here: > > https://bugreports.qt.io/browse/QBS-902 . That was the moment when I > > started to have doubts :). > > for all i can tell that's a rather poor bug report with little followup > from you. that's where i start to have doubts whether you actually mean > it. ;) > You must be kidding! What do you want me to do more? Write some love poems? > > > d) last but not least a clean and easily maintainable code base that can > > be > > used for the next decade(s). > > ... > > > > - Instread to port QBS to QML JS in the first second when QtScript was > > > > deprecated, they fork it! I know that back then QML JS needed some love, > > but instead to collaborate with QML JS folks they decided keep using > > QtScript! IIRC a brave soul, port it to QML JS, but guess what, QBS devs > > reject it and kept using QtScript! > > > > - Even more, they found a few problem also in QML parser, and guess what, > > > > they forked also QML! > > both these items get a huge "so what?" in response. because they have no > practical impact whatsoever. "So what?" Qt 6 will use cmake instead of qbs? They have a big impact when it's comming to maintainanace. Instead to focus on qbs code, you have to focus also on QtScript and on QML parser... > > > To fix d) a large part of QBS must be reorganized/rewritten, > > i see no actual evidence of that. Well, Qt 6 using cmake instead of qbs is the best *indirect* evidence ;-). Anyway, as long as Lars & Tuukka announced that qbs is dead, personally I think in this moment the whole discussion is futile. Because of that decission, in this moment TQC imagine is not very good, imagine how it will look if in a week or two you'll announce that you ditch cmake or qmake and embrace QBS again, that will be a PR nightmare and I don't see it coming :). Cheers, BogDan. From Uwe.Rathmann at tigertal.de Wed Oct 31 07:35:50 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Wed, 31 Oct 2018 06:35:50 +0000 (UTC) Subject: [Development] Build system for Qt 6 References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2905671.pIe2p5T7Nj@tjmaciei-mobl1> <3474294.Wz9aCAfvH3@tjmaciei-mobl1> <5de5f554-a843-277e-c8c8-fb3080eab45a@qt.io> Message-ID: On Tue, 30 Oct 2018 19:24:26 +0000, Adam Treat wrote: > Lars gave a keynote saying pretty much the same. Simply is not true that > we are planning major source compatible breakage for Qt6 so let's stop > saying that. When will the already deprecated QQuickControls 1 module going to be finally removed - isn't it Qt6 ? QC1 user interfaces for embedded have to be migrated to QC 2, while user interfaces for the desktop have to be reimplemented from scratch with Qt/ Widgets in C++. To me this absolutely justifies to insist on the term "major". Uwe From tony.sarajarvi at qt.io Wed Oct 31 08:10:47 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Wed, 31 Oct 2018 07:10:47 +0000 Subject: [Development] CI machines out of disk space In-Reply-To: <6219171.anQ2oEyD7U@tjmaciei-mobl1> References: <6219171.anQ2oEyD7U@tjmaciei-mobl1> Message-ID: Yeah, we were already wondering about that. Before the builds starts, it has 160 GB of free disk space. Could the build really eat up all that? We've had kernel crashing on the host side of the VM, and that has caused the VM to put its disks on read-only mode. That has then created errors that can't write on disk. That's different error message though. Just wondering if the error message this time is wrong, but from the same reason... -Tony -----Original Message----- From: Development On Behalf Of Thiago Macieira Sent: keskiviikko 31. lokakuuta 2018 6.17 To: development at qt-project.org Subject: [Development] CI machines out of disk space https://testresults.qt.io/logs/qt/qtbase/ 4d1c701336289c6c70c86b1bdea0324214a5687a/ LinuxUbuntu_18_04x86_64LinuxQEMUarmv7GCCqtci-linux-Ubuntu-18.04-x86_64- ea77a2DeveloperBuild_DisableTests/2a48a3b7dcb9652b1532a3ad14de7580b5b9b1ee/ build_1542285435/log.txt.gz agent:2018/10/31 03:51:26 build.go:193: {standard input}: Assembler messages: agent:2018/10/31 03:51:26 build.go:193: {standard input}: Fatal error: can't write 76 bytes to section .text of .obj/qgraphicssceneindex.o because: 'No space left on device' -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From mitch.curtis at qt.io Wed Oct 31 08:25:18 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Wed, 31 Oct 2018 07:25:18 +0000 Subject: [Development] Serialising UI state in QML via QSettings and JSON: QByteArray vs QString In-Reply-To: References: Message-ID: > -----Original Message----- > From: J-P Nurmi > Sent: Tuesday, 30 October 2018 3:52 PM > To: Mitch Curtis > Cc: development at qt-project.org > Subject: Re: [Development] Serialising UI state in QML via QSettings and > JSON: QByteArray vs QString > > On Tue, Oct 30, 2018 at 3:04 PM Mitch Curtis wrote: > > Their documentation doesn't claim that they operate on a specific type, so > I'm not sure it's a matter of not doing what they claim to do. > > They do promise to handle binary data, though. Representing binary data > with null-terminated strings makes them useless. The sole purpose of base64 > is to encode binary data to text that can be represented as a string. > > > Whether or not they could be extended to work with byte arrays is a > question I don't have the answer to, though presumably it would involve > modifying QV4::Value and who knows what else in the guts of QML. > > The QML engine gained better QByteArray support recently (5.10?): > http://doc.qt.io/qt-5/qtqml-cppintegration-data.html#qbytearray-to- > javascript-arraybuffer > > > Unfortunately it wouldn't help the use case I'm trying to support though, > because there is still the problem of Qt's JSON implementation not > supporting byte arrays. > > Pass the state as a base64 string. Where does it turn to a byte array if > Qt.btoa() returns a string? As of the previous patch set, saveState() returned a QByteArray, so the user starts off with a byte array. If I somehow manage to make Qt.atob() and Qt.btoa() accept and return a byte array (it wouldn't make sense to accept a byte array and return a string), this prevents writing such state to JSON due to its lack of support for byte arrays. The only way to serialise SplitView's state to JSON if we changed these functions to use byte arrays would be to go through each value in the QVariantMap that is exposed to QML for it to set the UI state (QJsonObject can't be exposed to QML) and check if it's a byte array and then convert it to a Base64 string. That seems very hacky for users. > > What do you think about the proposed solution of saveState() returning a > Base64 QString? > > -1 :) Can you explain why? It's a negligible difference in binary vs text for the amount of data we're talking about. > -- > J-P Nurmi From adam.treat at qt.io Wed Oct 31 08:33:56 2018 From: adam.treat at qt.io (Adam Treat) Date: Wed, 31 Oct 2018 07:33:56 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2905671.pIe2p5T7Nj@tjmaciei-mobl1> <3474294.Wz9aCAfvH3@tjmaciei-mobl1> <5de5f554-a843-277e-c8c8-fb3080eab45a@qt.io>, Message-ID: See: “deprecated” ________________________________ From: Development on behalf of Uwe Rathmann Sent: Wednesday, October 31, 2018 2:35:50 AM To: development at qt-project.org Subject: Re: [Development] Build system for Qt 6 On Tue, 30 Oct 2018 19:24:26 +0000, Adam Treat wrote: > Lars gave a keynote saying pretty much the same. Simply is not true that > we are planning major source compatible breakage for Qt6 so let's stop > saying that. When will the already deprecated QQuickControls 1 module going to be finally removed - isn't it Qt6 ? QC1 user interfaces for embedded have to be migrated to QC 2, while user interfaces for the desktop have to be reimplemented from scratch with Qt/ Widgets in C++. To me this absolutely justifies to insist on the term "major". Uwe _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From chgans at gmail.com Wed Oct 31 08:42:52 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Wed, 31 Oct 2018 20:42:52 +1300 Subject: [Development] Build system for Qt 6 In-Reply-To: <2785213.8PD2uIGTjk@tjmaciei-mobl1> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2217724.thNANPicTR@tjmaciei-mobl1> <2785213.8PD2uIGTjk@tjmaciei-mobl1> Message-ID: On Wed, 31 Oct 2018 at 11:08, Thiago Macieira wrote: > On Tuesday, 30 October 2018 14:44:43 PDT Christian Gagneraud wrote: > > On Wed, 31 Oct 2018 at 10:27, Thiago Macieira > wrote: > > > On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote: > > > The only thing I'm criticising is that its proper chance involves Qt being > > > the guinea pig. Find someone else instead and grow your community. Get > > > track record for building, cross-compiling, working with weird set ups, > > > containerised build environments, build farms, etc. Don't ask Qt to switch > > > to it until you've done that work. > > > > !?! > > What make you think qbs cannot be used in such environments?That all > > I didn't say it can't. I'm saying I want proof that it can, by having other > projects adopt the solution and there being track record of it. > > > very basic stuff to me. > > - cross-compiling: Qbs support *out of the box* all "standard" OS > > *and* "standard" toolchains. > > - working with weird set ups: what does that even mean? That a very > > vague statement. > > See the July email for more details. > > > - containerised build: any build system can run in a container, that's > > orthogonal. > > Until you run into trouble. Example of what I literally had a problem with in > the last 30 minutes: Maven. > > [ERROR] Failed to execute goal on project hadoop-auth: Could not resolve > dependencies for project org.apache.hadoop:hadoop-auth:jar:2.8.5: Failed to > collect dependencies at com.nimbusds:nimbus-jose-jwt:jar:4.41.1: Failed to > read artifact descriptor for com.nimbusds:nimbus-jose-jwt:jar:4.41.1: Could > not transfer artifact com.nimbusds:nimbus-jose-jwt:pom:4.41.1 from/to > apache.snapshots.https (https://repository.apache.org/content/repositories/ > snapshots): repository.apache.org: No address associated with hostname -> > [Help 1] > > Who do I turn to for help? A quick set of Google queries did not result in an > answer on how to properly populate the dependencies for this thing (Apache > Hadoop) . Your problem has nothing to do with containers, unplug the network cable of your computer, and you'll have the same issue on your host. But that's an interesting 'issue', one that even contradict some of your requirements, like containerised, build farm, supported by Linux distro, ... I'm pretty sure that the build system used by Apache Hadoop meet all your requirements, yet in your particular use case, it fails ... So your long list of requirement cannot even bring the guarantees you're seeking. I'm not trying to say that your requirements are bad or useless, i'm just saying that in themselves, they don't even bring any guarantees, that's all. > > - build farms: Against what is the problem with build farm, i don't get it. > > There's no problem until there's a problem. Can you point me to something that > uses qbs to build getting built in a Linux distribution's build farm? I'd like > to know that it's been properly tested. > > It's small things like libraries ending up in /usr/lib64 instead of /usr/lib. > Some build systems do that automatically for you; with some others you can get > it wrong. And here's the buildsystem that failed to install libraries in the > right place this morning: CMake. Packagers have to deal with that all the time, and people doing cross-compilation have to deal with even worse things every day. Even if you use the perfect tool, the author of the build recipe can still screw it up. Given who's behind Qbs, I have high expectation for Qbs to do 'the right thing'. Chris > > - etc: again, can you elaborate? that's very vague. > > I did, three months ago. > > > I've used Qbs to build a Desktop SW for Windows + MacOS + Linux, all > > producing platform specific installers. > > It was a breeze. > > I've used it to build a 1.5 million SLOC SW, with complex build > > matrix. > > Great. That's good track record. Now get 3 Linux distributions to package it. > > > The only reason we dropped it, was because of lack of > > integration: > > QtCreator is the only IDE that knows Qbs, as i reported on Qbs mailing > > long time ago, Qbs won't take off without XCode, Visual Stidio, Visual > > Code, Eclipse, ... integration. > > And, so far, we failed at switching to CMake, the build matrix is too > > complex. > > I didn't call for IDE support in my email. Tobias, in a reply to it, did. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From giuseppe.dangelo at kdab.com Wed Oct 31 10:06:58 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Wed, 31 Oct 2018 10:06:58 +0100 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <4acb56ff-d382-01b5-346f-5c40b6b003ed@iseg-hv.de> References: <2935486.kRNsAma0Ab@tjmaciei-mobl1> <4acb56ff-d382-01b5-346f-5c40b6b003ed@iseg-hv.de> Message-ID: Il 29/10/18 13:00, André Hartmann ha scritto: > Looking athttps://docs.kdab.com/analysis/qtcreator/clazy.html gives > currently 223 potential detaching containers within range-based for, and > qtbase alone has 46 (https://docs.kdab.com/analysis/qt5/clazy.html). > > Even if there may be some false positives, who is going to check and fix > them all? If we don't manage to use the range-based for correctly (for > Qt-containers), why should we force the user to port away from foreach? Well, noone is forcing you to change those usages right now; updating old practices is something which is naturally part of maintaining a code base. And, yes, *we* get this stuff wrong all the time (... QList anyone?). Luckily we now have something like clazy now, so we can prevent such mistakes from happening in the first place. My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From Oswald.Buddenhagen at qt.io Wed Oct 31 10:12:53 2018 From: Oswald.Buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 31 Oct 2018 09:12:53 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: <1653559.CV2QjtXsQV@tjmaciei-mobl1> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <7072220.eW4KKezGqE@tjmaciei-mobl1> <20181030204658.GA6506@ugly> <1653559.CV2QjtXsQV@tjmaciei-mobl1> Message-ID: <20181031091251.GA21774@ugly> On Tue, Oct 30, 2018 at 02:07:16PM -0700, Thiago Macieira wrote: > On Tuesday, 30 October 2018 13:47:00 PDT Oswald Buddenhagen wrote: > > On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote: > > > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote: > > > > doesn't authorize you to impose requirements that make it basically > > > > impossible to employ qt as a bootstrapping device for a qbs > > > > ecosystem. > > > > > > The whole point was "let Qt not be the guinea pig". > > > > you're essentially presuming that qbs is developed by a potentially > > incompetent external entity. > > No. However, I am asking for proof. > you may obtain it yourself when you distrust your own community so much. > > > Show me that the tool can achieve what Qt needs for it to achieve > > > > qtbase//wip/qbs2 speaks for itself. > > That's the guinea pig. I am asking for proof by seeing someone else > adopt it. > you aren't asking for "achievements", but for a perfect guarantee of unproblematic deployment. that's quite frankly absurd. > The tool is now several years old, it ought to have attracted > *someone*. > almost everyone who even looked at it did the right thing: distrust the entity behind it, because it's not showing committment. this is the message we have been hearing again and again, most of all from within the company. > And even if it hasn't, there are a couple of years left until we > switch for Qt. The community supporting this tool can find other > projects of moderate complexity to work with and support. > that's nonsense. the decision is happening *now* (in as far as it isn't a done deal already). the cmake port is getting all the instant committment and push from lars that he never managed to give to qbs. there isn't going to be a time after cmake. > > > and has enough of a track record of a community to ask for help. > > > > it has enough "community" and intrinsic quality to get things going. > > I'm not disputing it has quality. But it lacks a specific community I > called for: packagers. > that community has always managed, and it sure would with qbs (in as far as it didn't already). it's not rocket science. > Tell me, has anyone tried to build that branch in the Boot2Qt context? > that seems unlikely. our QA is constantly overloaded, and certainly doesn't want to priorize something that clearly isn't taken seriously by parts of the company, most of all management. however, that *would* change if there was an *actual* decision in favor of qbs. > > asking for more is completely unreasonable before the community from > > which the tool originates shows committment by *relying* on it. > > I disagree and I find it completely reasonable to ask. That's why I > did so. > that attitude is totally selfish and remarkably disrespectful towards parts of your own community. it clearly shows that you don't consider qbs part of our own dog food. > And yes, they were right: if qbs is created for Qt alone, then they > shouldn't rely on it. Hence the request to show that it can be used by > others and that there's at least a modest community behind it. > this thread has show beyond a reasonable doubt that there *is* a "modest" community behind it. From Christian.Kandeler at qt.io Wed Oct 31 10:47:07 2018 From: Christian.Kandeler at qt.io (Christian Kandeler) Date: Wed, 31 Oct 2018 09:47:07 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2217724.thNANPicTR@tjmaciei-mobl1> Message-ID: <20181031104705.35483ba0@ckandeler-archlinux> On Wed, 31 Oct 2018 10:44:43 +1300 Christian Gagneraud wrote: > On Wed, 31 Oct 2018 at 10:27, Thiago Macieira wrote: > > On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote: > > The only thing I'm criticising is that its proper chance involves Qt being the > > guinea pig. Find someone else instead and grow your community. Get track > > record for building, cross-compiling, working with weird set ups, > > containerised build environments, build farms, etc. Don't ask Qt to switch to > > it until you've done that work. > > !?! > What make you think qbs cannot be used in such environments?That all > very basic stuff to me. > - cross-compiling: Qbs support *out of the box* all "standard" OS > *and* "standard" toolchains. > - working with weird set ups: what does that even mean? That a very > vague statement. > - containerised build: any build system can run in a container, that's > orthogonal. > - build farms: Against what is the problem with build farm, i don't get it. > - etc: again, can you elaborate? that's very vague. > > I've used Qbs to build a Desktop SW for Windows + MacOS + Linux, all > producing platform specific installers. > It was a breeze. > I've used it to build a 1.5 million SLOC SW, with complex build > matrix. The only reason we dropped it, was because of lack of > integration: > QtCreator is the only IDE that knows Qbs, as i reported on Qbs mailing > long time ago, Qbs won't take off without XCode, Visual Stidio, Visual > Code, Eclipse, ... integration. > And, so far, we failed at switching to CMake, the build matrix is too complex. So what *are* you using now? Just curious. Christian From giuseppe.dangelo at kdab.com Wed Oct 31 10:47:56 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Wed, 31 Oct 2018 10:47:56 +0100 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: <2935486.kRNsAma0Ab@tjmaciei-mobl1> Message-ID: Il 29/10/18 12:43, Olivier Goffart ha scritto: > Deprecating means you will force user to port all their codebase away from it, > which is a huge work. If the rationale is just that they will save a couple of > atomic operations, i do not think it is worth it. > > Deprecating it only for non-shared container seems more logical, since we then > warn only when there is actually a problem. > > And for the Qt shared container case, using foreach is less typing, but also > less error prone. (do i have to use qAsConst? or make a copy? or even return a > const object which even lead to more problems) Not really, my main argument is teachability. I want to stop teaching foreach to Qt users (which are also C++ users; why do we keep forgetting that there's a C++ world out there that doesn't use Qt?), and tell them that * foreach is supposed to be used only on Qt containers, not STL / Boost ones * actually, only on _certain_ Qt containers, * but if you use it on a "wrong" container it still works, no warnings or anything, just a tremendous price hit, * why? because it's unconditionally doing a copy, which is cheap only for the certain containers in Qt, * and because of this copy it can't do mutating iteration, so you need to learn ranged-based for *anyhow*, * but thanks to this copy it is perfectly safe to modify the original container, because it's copied anyhow (and you can rely on it) (and documentation was encouraging this) (and Qt's OWN SOURCE CODE had places that relied on that) --- Well, no. :( I want to teach users: * if you have a container and you want to do mutating iteration, use for (auto &element : container) * if you have a container and you want to do non-mutating iteration, use for (const auto &c = container; const auto &element : c) And that's it; this is a pure C++ solution that works for any container (Qt, STL, Boost, ...), does never take any copy (you're iterating on the original), it is const-correct (can't accidentally modify the container through the element in a non-mutating iteration, can't accidentally modify a const container), never detaches a Qt container unless you need to anyhow (mutating iteration), and in general it is not safe to modify the container's structure from within the loop's body so don't do it. My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From private at bernhard-lindner.de Wed Oct 31 11:02:04 2018 From: private at bernhard-lindner.de (Bernhard Lindner) Date: Wed, 31 Oct 2018 11:02:04 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: <1653559.CV2QjtXsQV@tjmaciei-mobl1> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <7072220.eW4KKezGqE@tjmaciei-mobl1> <20181030204658.GA6506@ugly> <1653559.CV2QjtXsQV@tjmaciei-mobl1> Message-ID: Hi! > No. However, I am asking for proof. Maybe I worked for the wrong companies all the time. But whenever we wanted to have proof that some tool or library actually meets our requirements, it never was sufficient to *ask* for proof. We needed to test it by *ourselfs* in a feasibility project. And normally *none* of the candidates completely met all of our requirements so we chose the tool with the least flaws, the best potential and (most important!) with the most dedicated maintenance/support crew. And of course some trust was part of the decision. Thiago, did this startegy of yours (simply asking for an all-inclusive proof and guarantee) ever work before? -- Regards Bernhard From robin.burchell at crimson.no Wed Oct 31 11:16:18 2018 From: robin.burchell at crimson.no (Robin Burchell) Date: Wed, 31 Oct 2018 11:16:18 +0100 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181030164054.GC9915@troll08> References: <20181030164054.GC9915@troll08> Message-ID: <1540980978.3872805.1560727336.1140E12B@webmail.messagingengine.com> On Tue, Oct 30, 2018, at 5:40 PM, Oswald Buddenhagen wrote: > on top of that there are long-term savings to be made from increased > productivity (which several posters to this thread have confirmed or > implied). that alone won't offset the cost vs. using cmake (it would vs. > developing and using qmake), but it's not negligible. Speaking specifically about things _other than Qt_ (this does not really apply to Qt - though perhaps it does a little): I can't really judge any of these savings as I never really had the opportunity to try qbs (and this is coming from me - someone who deliberately tries to experiment with almost every new, strange thing there is out there). I think that qbs's worst enemy was that the "competition" of everything else in the space was good _enough_ (yep, even qmake, warts and all). Build systems, from the perspective of the people using them to build other things, are not a tangible part of the deliverable product you make money off of. They are a tool that _enable_ you to produce such a product. Any effort that goes into changing that tooling takes effort away from other areas that more directly make money - and that effort requires justification. From my personal experience, I have never had a compelling answer for "why should we port to qbs" to give that justification. "Why should we port to a tool that very few other people are using that doesn't provide clearly night-and-day amazing benefits when what is available today is better known and works well enough"? Indeed, I'll let you know if I ever figure out an answer to that one. This isn't meant to say that any one tool is perfect - of course, they're not. But they're good enough most of the time. From philwave at gmail.com Wed Oct 31 11:17:43 2018 From: philwave at gmail.com (Philippe) Date: Wed, 31 Oct 2018 11:17:43 +0100 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: References: Message-ID: <20181031111742.7AFF.6F0322A@gmail.com> Good post, but: >> * if you have a container and you want to do non-mutating iteration, use >> for (const auto &c = container; const auto &element : c) This is enough: for (auto &element : std::as_const(container)) and for the rvalue reference case: for (const auto &c = container; auto &element : c) Philippe On Wed, 31 Oct 2018 10:47:56 +0100 Giuseppe D'Angelo via Development wrote: > Il 29/10/18 12:43, Olivier Goffart ha scritto: > > Deprecating means you will force user to port all their codebase away from it, > > which is a huge work. If the rationale is just that they will save a couple of > > atomic operations, i do not think it is worth it. > > > > Deprecating it only for non-shared container seems more logical, since we then > > warn only when there is actually a problem. > > > > And for the Qt shared container case, using foreach is less typing, but also > > less error prone. (do i have to use qAsConst? or make a copy? or even return a > > const object which even lead to more problems) > > > Not really, my main argument is teachability. I want to stop teaching foreach to Qt users (which are also C++ users; why do we keep forgetting that there's a C++ world out there that doesn't use Qt?), and tell them that > > * foreach is supposed to be used only on Qt containers, not STL / Boost ones > * actually, only on _certain_ Qt containers, > * but if you use it on a "wrong" container it still works, no warnings or anything, just a tremendous price hit, > * why? because it's unconditionally doing a copy, which is cheap only for the certain containers in Qt, > * and because of this copy it can't do mutating iteration, so you need to learn ranged-based for *anyhow*, > * but thanks to this copy it is perfectly safe to modify the original container, because it's copied anyhow (and you can rely on it) (and documentation was encouraging this) (and Qt's OWN SOURCE CODE had places that relied on that) --- > > Well, no. :( > > > I want to teach users: > > * if you have a container and you want to do mutating iteration, use > > for (auto &element : container) > > > * if you have a container and you want to do non-mutating iteration, use > > for (const auto &c = container; const auto &element : c) > > > And that's it; this is a pure C++ solution that works for any container (Qt, STL, Boost, ...), does never take any copy (you're iterating on the original), it is const-correct (can't accidentally modify the container through the element in a non-mutating iteration, can't accidentally modify a const container), never detaches a Qt container unless you need to anyhow (mutating iteration), and in general it is not safe to modify the container's structure from within the loop's body so don't do it. > > My 2 c, > > -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > From abbapoh at gmail.com Wed Oct 31 11:19:46 2018 From: abbapoh at gmail.com (=?koi8-r?B?6dfBziDrz83J09PB0s/X?=) Date: Wed, 31 Oct 2018 11:19:46 +0100 Subject: [Development] Qt6 source changes Message-ID: <55CC6C02-355A-47E5-9935-9A124D8ACCA0@gmail.com> Hello, Thiago wrote in the "buildsystem thread" that Qt 6 will be source compatible with Qt5. As long as I fully support source-compatibility with both hands, I would like to ask several questions about possible source-breaking changes. 1) QAbstractItemModel. I want to introduce change that adds QModelIndex parameter to headerData(). For now, QHeaderView ignores the rootIndex() property which prevents creating models with sub tables in each index (only tree models are supported now). The example - you need to display a struct (or, protobuf message) as a table. Each struct can have sub structs (or, arrays of structs) so the tree is not enough to display it. I wrote a working prototype back in 2015 which required subclassing QAIM and copying the whole QHeaderView into the project. In this case source compatibility can be saved by having 2 virtual headerData methods, the one without modelIndex market deprecated. 2) QVariantList/QList and friends. I would like to to see most of QList usages in Qt eliminated in favor of QVector. I won't repeat Marc's arguments against QList. Instead, I want to ask the other thing - is breaking user code that uses "QList list = someQtApiFunc();" is forbidden too? If Assumption that QVector is API-compatible with QList (which is not true, I suppose, but can be mostly fixed) that should not be a big deal to replace the usages of a QList with "auto list = someQtApiFunc();". Qt should really evolve and stucking with QList for the next 10 years is a bad idea IMO. Иван Комиссаров From jani.heikkinen at qt.io Wed Oct 31 11:26:32 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 31 Oct 2018 10:26:32 +0000 Subject: [Development] Maintainers, your action needed: Qt 5.12.0 changes files Message-ID: Hi, Initial ones here: https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.12.0%22,n,z Maintainers, please do needed modifications now and make sure changes will be approved as soon as possible br, Jani Heikkinen Release Manager From chgans at gmail.com Wed Oct 31 11:26:40 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Wed, 31 Oct 2018 23:26:40 +1300 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181031104705.35483ba0@ckandeler-archlinux> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2217724.thNANPicTR@tjmaciei-mobl1> <20181031104705.35483ba0@ckandeler-archlinux> Message-ID: On Wed, 31 Oct 2018 at 22:47, Christian Kandeler wrote: > > On Wed, 31 Oct 2018 10:44:43 +1300 > Christian Gagneraud wrote: > > > On Wed, 31 Oct 2018 at 10:27, Thiago Macieira wrote: > > > On Tuesday, 30 October 2018 13:56:45 PDT NIkolai Marchenko wrote: > > > The only thing I'm criticising is that its proper chance involves Qt being the > > > guinea pig. Find someone else instead and grow your community. Get track > > > record for building, cross-compiling, working with weird set ups, > > > containerised build environments, build farms, etc. Don't ask Qt to switch to > > > it until you've done that work. > > > > !?! > > What make you think qbs cannot be used in such environments?That all > > very basic stuff to me. > > - cross-compiling: Qbs support *out of the box* all "standard" OS > > *and* "standard" toolchains. > > - working with weird set ups: what does that even mean? That a very > > vague statement. > > - containerised build: any build system can run in a container, that's > > orthogonal. > > - build farms: Against what is the problem with build farm, i don't get it. > > - etc: again, can you elaborate? that's very vague. > > > > I've used Qbs to build a Desktop SW for Windows + MacOS + Linux, all > > producing platform specific installers. > > It was a breeze. > > I've used it to build a 1.5 million SLOC SW, with complex build > > matrix. The only reason we dropped it, was because of lack of > > integration: > > QtCreator is the only IDE that knows Qbs, as i reported on Qbs mailing > > long time ago, Qbs won't take off without XCode, Visual Stidio, Visual > > Code, Eclipse, ... integration. > > And, so far, we failed at switching to CMake, the build matrix is too complex. > > So what *are* you using now? Just curious. Drum roll..... vcxproj + python + qmake! This is close to a 'hand crafted' build system, it is dirty, fragile, but "it works" (tm). The middle man, python, is where we have full freedom to do the dirty tweaking job. We even have python code that "fix" the generated Makefiles, when needed. Absolutely nobody likes this solution, it is heinous, but it is the only one that fulfill all our requirements. With enough energy, i'm sure this whole thing could be switched to Qbs, CMake or even qmake. But I do believe that Qbs would be the cleanest solution. Now, of these 3 build systems, CMake is the only one that is supported by Visual Studio (I was told), and although i do not use it, this is the most common IDE here. We do hundreds of builds per days, for ca. 15 different build configurations, and we do that in containers, in a build farm. We're even experimenting with Windows native containers, and off-loading our local build farm in the cloud. We build the whole custom embedded Linux OS as well, a bunch of in-house shell scripts that have to deal with at least the most common build systems. We have tera-bytes of artifacts every day. We generate firmwares for at least 50 commercial products, every day. Yes it's not an easy job, and CMake vs qmake vs Qbs doesn't influence the number of issue we have to face. Hence my criticism toward Thiago's requirements and arguments. I don't buy a single line of what he said in this thread. Last but not least, everyone maintaining a Embedded Linux Distro have to maintain a set of patches to work around buggy source package build system, and this includes Qt, see for example: https://github.com/meta-qt5/meta-qt5/tree/master/recipes-qt/qt5/qtbase See as well debian/patches in, eg http://http.debian.net/debian/pool/main/q/qtbase-opensource-src/qtbase-opensource-src_5.3.2+dfsg-4+deb8u2.debian.tar.xz Whatever the build system you use, your users will have to work it around and deal with it. Chris From giuseppe.dangelo at kdab.com Wed Oct 31 11:35:32 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Wed, 31 Oct 2018 11:35:32 +0100 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <20181031111742.7AFF.6F0322A@gmail.com> References: <20181031111742.7AFF.6F0322A@gmail.com> Message-ID: <41f44d86-861a-ea69-d0a1-fcd1f636146c@kdab.com> Il 31/10/18 11:17, Philippe ha scritto: > and for the rvalue reference case: > > for (const auto &c = container; auto &element : c) Why not using this one for *both* lvalues and rvalues? Once more, one fewer thing to teach. Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From maximilian.hrabowski at clausmark.com Wed Oct 31 12:32:11 2018 From: maximilian.hrabowski at clausmark.com (Maximilian Hrabowski) Date: Wed, 31 Oct 2018 11:32:11 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: <3174200.alS1aoj13T@dragon> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <2483414.fFGr5Wv9AV@dragon> <20181030171118.GD9915@troll08> <3174200.alS1aoj13T@dragon> Message-ID: <8815BCF8-2671-4922-BEC1-6C7005043212@clausmark.com> On 31. Oct 2018, at 06:38, Bogdan Vatra via Development > wrote: Hi, În ziua de marți, 30 octombrie 2018, la 19:11:20 EET, Oswald Buddenhagen a scris: On Tue, Oct 30, 2018 at 01:16:43PM +0200, Bogdan Vatra wrote: c.2) back then, none of the existing build system could deliver enough information to IDEs to enable prefect code completion (e.g. include paths, defines, compiler flags, etc.) ... c.2) Incomplete! A while ago, I created a QBS plugin for KDevelop[1] and I found some problems, see how QBS developers treat them here: https://bugreports.qt.io/browse/QBS-902 . That was the moment when I started to have doubts :). for all i can tell that's a rather poor bug report with little followup from you. that's where i start to have doubts whether you actually mean it. ;) You must be kidding! What do you want me to do more? Write some love poems? This kind of reaction on https://bugreports.qt.io/browse/QBS-902 is the normal experience i encounter when submitting Qt-Bugs, so IMHO this is not related to the importance of qbs as a project but best practise. Cheers, Maximilian -------------- next part -------------- An HTML attachment was scrubbed... URL: From kollix at aon.at Wed Oct 31 12:40:50 2018 From: kollix at aon.at (Martin Koller) Date: Wed, 31 Oct 2018 12:40:50 +0100 Subject: [Development] who generates gui/text/qcssparser.cpp Message-ID: <3445728.Ka22BYXq7U@lapi> In this file I find: // auto generated. DO NOT EDIT. class QCssScanner_Generated Who/what generates this file ? I'm looking for the syntax definition for the attribute matching since the docs only talk about attr=value and attr~=value but in the code I find others: enum ValueMatchType { NoMatch, MatchEqual, MatchIncludes, MatchDashMatch, MatchBeginsWith, MatchEndsWith, MatchContains }; and I wanted to know which tokens lead to these enum values. -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at From jpnurmi at gmail.com Wed Oct 31 12:41:21 2018 From: jpnurmi at gmail.com (J-P Nurmi) Date: Wed, 31 Oct 2018 12:41:21 +0100 Subject: [Development] Serialising UI state in QML via QSettings and JSON: QByteArray vs QString In-Reply-To: References: Message-ID: On Wed, Oct 31, 2018 at 8:25 AM Mitch Curtis wrote: > > Pass the state as a base64 string. Where does it turn to a byte array if > > Qt.btoa() returns a string? > > As of the previous patch set, saveState() returned a QByteArray, so the user starts off with a byte array. If I somehow manage to make Qt.atob() and Qt.btoa() accept and return a byte array (it wouldn't make sense to accept a byte array and return a string), this prevents writing such state to JSON due to its lack of support for byte arrays. > > The only way to serialise SplitView's state to JSON if we changed these functions to use byte arrays would be to go through each value in the QVariantMap that is exposed to QML for it to set the UI state (QJsonObject can't be exposed to QML) and check if it's a byte array and then convert it to a Base64 string. That seems very hacky for users. > > > > What do you think about the proposed solution of saveState() returning a > > Base64 QString? > > > > -1 :) > > Can you explain why? It's a negligible difference in binary vs text for the amount of data we're talking about. What you do inside saveState() and restoreState() is your business. Whether you use JSON, CBOR, QDataStream, or something else, doesn't really matter. But I don't see any compelling reason to deviate from the "standard" QByteArray-based save/restoreState() pattern used in Qt Widgets, including QSplitter. Don't let a silly bug in Qt.btoa() drive the API design. If you want to store a binary blob in JSON, base64 is probably a good option, but why enforce it for those who don't need it? For C++ users, QByteArray provides the tools to encode and decode base64. Since base64 is ASCII, you can safely convert to QString and store it in JSON. In QML, you are supposed to be able to do the very same with Qt.atob(), Qt.btoa(), and toString(). -- J-P Nurmi From Oswald.Buddenhagen at qt.io Wed Oct 31 13:01:07 2018 From: Oswald.Buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 31 Oct 2018 12:01:07 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: <1540980978.3872805.1560727336.1140E12B@webmail.messagingengine.com> References: <20181030164054.GC9915@troll08> <1540980978.3872805.1560727336.1140E12B@webmail.messagingengine.com> Message-ID: <20181031120104.GA331@troll08> On Wed, Oct 31, 2018 at 11:16:18AM +0100, Robin Burchell wrote: > On Tue, Oct 30, 2018, at 5:40 PM, Oswald Buddenhagen wrote: > > on top of that there are long-term savings to be made from increased > > productivity (which several posters to this thread have confirmed or > > implied). that alone won't offset the cost vs. using cmake (it would > > vs. developing and using qmake), but it's not negligible. > > I think that qbs's worst enemy was that the "competition" of > everything else in the space was good _enough_ (yep, even qmake, warts > and all). Build systems, from the perspective of the people using them > to build other things, are not a tangible part of the deliverable > product you make money off of. They are a tool that _enable_ you to > produce such a product. > well, yes, of course. we knew that when we embarked on the journey - build systems aren't exactly the kind of thing that many people get excited about. mostly frustrated with. ^^ > Any effort that goes into changing that tooling takes effort away from > other areas that more directly make money - and that effort requires > justification. From my personal experience, I have never had a > compelling answer for "why should we port to qbs" to give that > justification. > that's a perfectly fine attitude. nobody would ask you to port away from a build system that is adequate and maintainable. except by telling you "oh, btw, we just deprecated the build tool you're using", that is. > "Why should we port to a tool that very few other people are using > that doesn't provide clearly night-and-day amazing benefits when what > is available today is better known and works well enough"? Indeed, > I'll let you know if I ever figure out an answer to that one. > we/i have three target audiences in mind: - full-time build system maintainers like myself. we feel the pain all day, so it's a purely selfish move to create and push something that actually doesn't suck. part of the plan is to have a tool that isn't arcane to the degree that any non-trivial task must involve the maintainer to arrive at an acceptable quality. - "forced switchers". a lot of projects are still on autotools, and with the expansion of their supported platforms beyond traditonal unix, they typically rewrite the build system. - qt (creator) users who have no strong preference for their new projects. the idea was to have qbs as the default, to offer a *fully* integrated out-of-the-box experience, something that cannot possibly be achieved with qmake or cmake. while not 100% achieved due to resourcing constraints, the IDE story was central to initially "selling" the project internally. it's all about developer experience, just like qt creator, and for that matter qt itself. From giuseppe.dangelo at kdab.com Wed Oct 31 13:21:29 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Wed, 31 Oct 2018 13:21:29 +0100 Subject: [Development] Qt6 source changes In-Reply-To: <55CC6C02-355A-47E5-9935-9A124D8ACCA0@gmail.com> References: <55CC6C02-355A-47E5-9935-9A124D8ACCA0@gmail.com> Message-ID: <72af28fc-18a7-8be6-027c-bee44c2ff4ae@kdab.com> Hi, Il 31/10/18 11:19, Иван Комиссаров ha scritto: > 1) QAbstractItemModel. I want to introduce change that adds QModelIndex parameter to headerData(). For now, QHeaderView ignores the rootIndex() property which prevents creating models with sub tables in each index (only tree models are supported now). The example - you need to display a struct (or, protobuf message) as a table. Each struct can have sub structs (or, arrays of structs) so the tree is not enough to display it. I wrote a working prototype back in 2015 which required subclassing QAIM and copying the whole QHeaderView into the project. In this case source compatibility can be saved by having 2 virtual headerData methods, the one without modelIndex market deprecated. This is reasonable given the tree-of-tables that QAbstractItemModel models; there's the bigger question of whether the one-API-fits-all is a good way forward, however I don't see anyone willing to rewrite the model classes for this. (There are also another couple of ideas I have in the QAIM department, e.g. a multiData(), which is just BC because it's a new virtual). More in general, are the existing views supposed to leverage the nested header data? And, apart from the issue of taking function overloads, how is this a source incompatible change? > 2) QVariantList/QList and friends. I would like to to see most of QList usages in Qt eliminated in favor of QVector. I won't repeat Marc's arguments against QList. Instead, I want to ask the other thing - is breaking user code that uses "QList list = someQtApiFunc();" is forbidden too? If Assumption that QVector is API-compatible with QList (which is not true, I suppose, but can be mostly fixed) that should not be a big deal to replace the usages of a QList with "auto list = someQtApiFunc();". Qt should really evolve and stucking with QList for the next 10 years is a bad idea IMO. This is still an open problem. For starters, I would be against such a massive break for user code. "Auto"-ifying doesn't work as you described, because for many other usages you can't use auto but must name the type (class members, function parameters, pre-C++14 function returns). If you want to achieve that, it's just simpler to make QList a type alias or a subclass of QVector. Or leave QList alone, deprecate it, change Qt to return QVectors, and add some implicit conversion. In other words, I've no idea :) Even then, we need to solve the other problems: 1) QStringList/QByteArrayList/etc. having extra functions on top. Keep as is, move them to QVector? 2) There are users relying on QList optimized prepend behaviour. How to support that? 3) There are users relying on QList's integrity of references when in array-of-pointers mode. (Note: 2+3 aren't "hearsay". Qt itself relies / used to rely on them, e.g. in QPostEventList. I can't imagine in how many other places in Qt a QList is being used relying on this optimization...) My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From sergio.martins at kdab.com Wed Oct 31 13:42:50 2018 From: sergio.martins at kdab.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Wed, 31 Oct 2018 12:42:50 +0000 Subject: [Development] who generates gui/text/qcssparser.cpp In-Reply-To: <3445728.Ka22BYXq7U@lapi> References: <3445728.Ka22BYXq7U@lapi> Message-ID: On 2018-10-31 11:40, Martin Koller wrote: > In this file I find: > > // auto generated. DO NOT EDIT. > class QCssScanner_Generated > > Who/what generates this file ? Looks like is generated by util/lexgen $ cd util/lexgen $ qmake && make $ ./lexgen css3-simplified.lexgen Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From mitch.curtis at qt.io Wed Oct 31 14:15:35 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Wed, 31 Oct 2018 13:15:35 +0000 Subject: [Development] Serialising UI state in QML via QSettings and JSON: QByteArray vs QString In-Reply-To: References: Message-ID: > -----Original Message----- > From: J-P Nurmi > Sent: Wednesday, 31 October 2018 12:41 PM > To: Mitch Curtis > Cc: development at qt-project.org > Subject: Re: [Development] Serialising UI state in QML via QSettings and > JSON: QByteArray vs QString > > On Wed, Oct 31, 2018 at 8:25 AM Mitch Curtis wrote: > > > Pass the state as a base64 string. Where does it turn to a byte > > > array if > > > Qt.btoa() returns a string? > > > > As of the previous patch set, saveState() returned a QByteArray, so the > user starts off with a byte array. If I somehow manage to make Qt.atob() and > Qt.btoa() accept and return a byte array (it wouldn't make sense to accept a > byte array and return a string), this prevents writing such state to JSON due > to its lack of support for byte arrays. > > > > The only way to serialise SplitView's state to JSON if we changed these > functions to use byte arrays would be to go through each value in the > QVariantMap that is exposed to QML for it to set the UI state (QJsonObject > can't be exposed to QML) and check if it's a byte array and then convert it to > a Base64 string. That seems very hacky for users. > > > > > > What do you think about the proposed solution of saveState() > > > > returning a > > > Base64 QString? > > > > > > -1 :) > > > > Can you explain why? It's a negligible difference in binary vs text for the > amount of data we're talking about. > > What you do inside saveState() and restoreState() is your business. > Whether you use JSON, CBOR, QDataStream, or something else, doesn't > really matter. But I don't see any compelling reason to deviate from the > "standard" QByteArray-based save/restoreState() pattern used in Qt > Widgets, including QSplitter. Don't let a silly bug in Qt.btoa() drive the API > design. If you want to store a binary blob in JSON, base64 is probably a good > option, but why enforce it for those who don't need it? For C++ users, > QByteArray provides the tools to encode and decode base64. Since base64 is > ASCII, you can safely convert to QString and store it in JSON. In QML, you are > supposed to be able to do the very same with Qt.atob(), Qt.btoa(), and > toString(). Looking closer into the code and tests, it seems that they are indeed completely broken, and somehow nobody ever noticed or complained: http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/qml/qml/v8/qqmlbuiltinfunctions.cpp?id=4a886753a75c7c4d66f1fa9cab5a6c5a03240df3#n992 http://code.qt.io/cgit/qt/qtdeclarative.git/tree/tests/auto/qml/qqmlqt/tst_qqmlqt.cpp?id=4a886753a75c7c4d66f1fa9cab5a6c5a03240df3#n937 http://code.qt.io/cgit/qt/qtdeclarative.git/tree/tests/auto/qml/qqmlqt/data/atob.qml?id=4a886753a75c7c4d66f1fa9cab5a6c5a03240df3 http://code.qt.io/cgit/qt/qtdeclarative.git/tree/tests/auto/qml/qqmlqt/data/btoa.qml?id=4a886753a75c7c4d66f1fa9cab5a6c5a03240df3 I'll look into fixing them and then go back to using QByteArray in the API. > -- > J-P Nurmi From chgans at gmail.com Wed Oct 31 14:36:11 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Thu, 1 Nov 2018 02:36:11 +1300 Subject: [Development] Who is in charge of qt-project.org? Message-ID: Hi, Can we have Qt mailing list archive back? I believe it is tracked by https://bugreports.qt.io/browse/QTWEBSITE-831 and as been going on for weeks. Can the "Qt Project Hosting Foundation" (from whois record) take care of that? What is going on? Chris From andy.shaw at qt.io Wed Oct 31 14:53:44 2018 From: andy.shaw at qt.io (Andy Shaw) Date: Wed, 31 Oct 2018 13:53:44 +0000 Subject: [Development] Who is in charge of qt-project.org? In-Reply-To: References: Message-ID: <6C73856E-F97F-469D-9877-43E01A312D7D@qt.io> It is there, but you have to go to http://lists.qt-project.org for now, it is being moved to a new server so at some point the https address will be back, but until then you need to use the http address. Andy Development på vegne av Christian Gagneraud skrev følgende den 31.10.2018, 14:36: Hi, Can we have Qt mailing list archive back? I believe it is tracked by https://bugreports.qt.io/browse/QTWEBSITE-831 and as been going on for weeks. Can the "Qt Project Hosting Foundation" (from whois record) take care of that? What is going on? Chris _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From chgans at gmail.com Wed Oct 31 15:01:37 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Thu, 1 Nov 2018 03:01:37 +1300 Subject: [Development] Who is in charge of qt-project.org? In-Reply-To: <6C73856E-F97F-469D-9877-43E01A312D7D@qt.io> References: <6C73856E-F97F-469D-9877-43E01A312D7D@qt.io> Message-ID: On Thu, 1 Nov 2018 at 02:53, Andy Shaw wrote: > > It is there, but you have to go to http://lists.qt-project.org for now, it is being moved to a new server so at some point the https address will be back, but until then you need to use the http address. In case you're not aware, HTTP is being deprecated, and modern, up-to-date web browser will redirect you to HTTPS/443 if it is available. If lists.qt-project.org doesn't support HTTPS, then it shouldn't answer on port 443. To be clear: my web browser will redirect me to https automatically because https is port 443 and port 443 on lists.qt-project.org is open and responding. The issue is that port 443 is serving plain HTTP instead of HTTPS. In a broader statement, i'm questioning the fitness of the Qt company to manage the qt-project.org domain. Obviously the Qt company is not making any money with qt-project.org, so please hand it over to the community. Chris > > Andy > > Development på vegne av Christian Gagneraud skrev følgende den 31.10.2018, 14:36: > > Hi, > > Can we have Qt mailing list archive back? > I believe it is tracked by > https://bugreports.qt.io/browse/QTWEBSITE-831 and as been going on for > weeks. Can the "Qt Project Hosting Foundation" (from whois record) > take care of that? > What is going on? > > Chris > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > From mwoehlke.floss at gmail.com Wed Oct 31 15:17:04 2018 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 31 Oct 2018 10:17:04 -0400 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181030215059.GA11838@ugly> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <20181030171752.GE9915@troll08> <20181030182501.GF9915@troll08> <6d692097-14fc-95bc-c323-32af6f635197@gmail.com> <20181030215059.GA11838@ugly> Message-ID: <1a0c2ef8-5ed2-1194-80e7-4d9303c7a137@gmail.com> On 30/10/2018 17.51, Oswald Buddenhagen wrote: > for starters just some food for thought: > QBS-995 should be implementable on top of it. > if you want to go full monty, QBS-942 is your target. What are those? Can you provide links? > one thing i noticed is that you multiplex build variants and other stuff > into a single file. this is not helpful for packaging. This is not entirely true; a single package specification *can* be split into multiple units. (I'm not sure this is well documented, but it is definitely intended. OTOH, while I'm pretty sure this is well supported for separate *components*, I'm less sure about separate *configurations* of the same component, so maybe there is room for improvement.) There does need to be one package that owns the "root" specification, but this is not so different from one package owning the top level directory. > after much > thinking about the matter, i concluded that the interface files should > correspond to "atomic linkable entities", which essentially means actual > libraries That's basically the pkg-config approach... and I believe that design to be intractable. In short, it fails to specify how to do the equivalent of `find_package(X COMPONENTS A B C)`. Especially if you have e.g. (ignoring 'C' for simplicity): X.A-1.2 X.A-1.0 X.B-1.1 X.B-1.0 You *have* to be able to do package-level queries; otherwise, how do you know (assuming X-1.z are mutually incompatible, but the consumer can use any X-1.z) to use X-1.0? > not one interface to describe all build variants, Aside from this isn't how lots of existing packages work, how would you then architect the system to allow the user to both be able to choose which build variant to use *or* to just pick one? Requiring the user to know which variant they want is an anti-goal. > and not one interface to describe each architecture variant within a > multi-arch library. Actually, I'm not sure if this would work. I won't swear that it won't (I don't think I've ever really thought about it), but it wasn't a design goal. The goal of having an arch specification is so that a consumer can ignore packages that are built for an incompatible architecture. (This is one of features that CMake is currently missing.) IOW, the intent was for one package specification to have only a single architecture. And at least CMake currently wouldn't support such packages anyway. (At best, it would use the component's from the consumer's arch and pretend the rest doesn't exist.) -- Matthew From thiago.macieira at intel.com Wed Oct 31 16:30:28 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 31 Oct 2018 08:30:28 -0700 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <41f44d86-861a-ea69-d0a1-fcd1f636146c@kdab.com> References: <20181031111742.7AFF.6F0322A@gmail.com> <41f44d86-861a-ea69-d0a1-fcd1f636146c@kdab.com> Message-ID: <1617550.SAbemMF5Zp@tjmaciei-mobl1> On Wednesday, 31 October 2018 03:35:32 PDT Giuseppe D'Angelo via Development wrote: > > for (const auto &c = container; auto &element : c) > > Why not using this one for *both* lvalues and rvalues? Once more, one > fewer thing to teach. C++17 required (and I didn't know this specific syntax worked). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Oct 31 16:33:15 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 31 Oct 2018 08:33:15 -0700 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1653559.CV2QjtXsQV@tjmaciei-mobl1> Message-ID: <18798308.psFCI2om8n@tjmaciei-mobl1> On Wednesday, 31 October 2018 03:02:04 PDT Bernhard Lindner wrote: > Maybe I worked for the wrong companies all the time. But whenever we wanted > to have proof that some tool or library actually meets our requirements, it > never was sufficient to *ask* for proof. We needed to test it by *ourselfs* > in a feasibility project. For qbs, most of the proof was "you still have work to do". That means *I* didn't have to do anything, but the proponents of it had to get it to mature. > And normally *none* of the candidates completely met all of our requirements > so we chose the tool with the least flaws, the best potential and (most > important!) with the most dedicated maintenance/support crew. And of course > some trust was part of the decision. Of course, not denying that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Oct 31 16:28:45 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 31 Oct 2018 08:28:45 -0700 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181031055957.GA24580@klara.mpi.htwm.de> References: <13D90296-84E6-491B-9A71-3A880FC868A3@qt.io> <1833828.G43E4eZFvL@tjmaciei-mobl1> <20181031055957.GA24580@klara.mpi.htwm.de> Message-ID: <7867869.XuAOyZs5DA@tjmaciei-mobl1> On Tuesday, 30 October 2018 22:59:57 PDT André Pönitz wrote: > Where would a QBS-promoting webpage be located? > > qt-project.org ? Sure, why not? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philwave at gmail.com Wed Oct 31 16:52:10 2018 From: philwave at gmail.com (Philippe) Date: Wed, 31 Oct 2018 16:52:10 +0100 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <1617550.SAbemMF5Zp@tjmaciei-mobl1> References: <41f44d86-861a-ea69-d0a1-fcd1f636146c@kdab.com> <1617550.SAbemMF5Zp@tjmaciei-mobl1> Message-ID: <20181031165208.2FC5.6F0322A@gmail.com> > C++17 required (and I didn't know this specific syntax worked). AFAIR, this is in fact a C++20 proposal. Hence best is: for (auto &element : std::as_const(container)) Philippe On Wed, 31 Oct 2018 08:30:28 -0700 Thiago Macieira wrote: > On Wednesday, 31 October 2018 03:35:32 PDT Giuseppe D'Angelo via Development > wrote: > > > for (const auto &c = container; auto &element : c) > > > > Why not using this one for *both* lvalues and rvalues? Once more, one > > fewer thing to teach. > > C++17 required (and I didn't know this specific syntax worked). > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From giuseppe.dangelo at kdab.com Wed Oct 31 16:54:48 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Wed, 31 Oct 2018 16:54:48 +0100 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <20181031165208.2FC5.6F0322A@gmail.com> References: <41f44d86-861a-ea69-d0a1-fcd1f636146c@kdab.com> <1617550.SAbemMF5Zp@tjmaciei-mobl1> <20181031165208.2FC5.6F0322A@gmail.com> Message-ID: <90d26844-6e15-7cc1-198e-df9b353c9589@kdab.com> Il 31/10/18 16:52, Philippe ha scritto: > AFAIR, this is in fact a C++20 proposal. Yes, it is (only if / switch got the optional initializer in C++17). Anyhow, nothing special about this: 1) can just do the same in pre-C++2a in two lines 2) not using C++-latest costs more :-) Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From Riitta-Leena.Miettinen at qt.io Wed Oct 31 17:26:43 2018 From: Riitta-Leena.Miettinen at qt.io (Riitta-Leena Miettinen) Date: Wed, 31 Oct 2018 16:26:43 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: References: Message-ID: >Date: Wed, 31 Oct 2018 08:28:45 -0700 >From: Thiago Macieira >To: >Subject: Re: [Development] Build system for Qt 6 >Message-ID: <7867869.XuAOyZs5DA at tjmaciei-mobl1> >Content-Type: text/plain; charset="iso-8859-1" > >>On Tuesday, 30 October 2018 22:59:57 PDT Andr? P?nitz wrote: > >Where would a QBS-promoting webpage be located? > > > >qt-project.org ? > >Sure, why not? > >-- >Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center Hello, We actually have a separate domain for Qbs at qbs.io. Currently, it redirects to the Qbs Manual at doc.qt.io, but we were working on it: https://bugreports.qt.io/browse/QBS-1341 Leena -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.ronin at yahoo.it Wed Oct 31 17:23:49 2018 From: v.ronin at yahoo.it (Kain Vampire) Date: Wed, 31 Oct 2018 16:23:49 +0000 (UTC) Subject: [Development] Who is in charge of qt-project.org? References: <1677105861.30132854.1541003029183.ref@mail.yahoo.com> Message-ID: <1677105861.30132854.1541003029183@mail.yahoo.com> WHAT A TWAT! P.S. Yes, feel free to ban me, it was worth it. -----Original Message----- From: Christian Gagneraud [mailto:chgans at gmail.com] Sent: 31 October 2018 14:02 To: andy.shaw at qt.io Cc: development at qt-project.org Subject: Re: [Development] Who is in charge of qt-project.org? On Thu, 1 Nov 2018 at 02:53, Andy Shaw wrote: > > It is there, but you have to go to http://lists.qt-project.org for now, it is being moved to a new server so at some point the https address will be back, but until then you need to use the http address. In case you're not aware, HTTP is being deprecated, and modern, up-to-date web browser will redirect you to HTTPS/443 if it is available. If lists.qt-project.org doesn't support HTTPS, then it shouldn't answer on port 443. To be clear: my web browser will redirect me to https automatically because https is port 443 and port 443 on lists.qt-project.org is open and responding. The issue is that port 443 is serving plain HTTP instead of HTTPS. In a broader statement, i'm questioning the fitness of the Qt company to manage the qt-project.org domain. Obviously the Qt company is not making any money with qt-project.org, so please hand it over to the community. Chris > > Andy > > Development på vegne av Christian Gagneraud skrev følgende den 31.10.2018, 14:36: > >     Hi, > >     Can we have Qt mailing list archive back? >     I believe it is tracked by >     https://bugreports.qt.io/browse/QTWEBSITE-831 and as been going on for >     weeks. Can the "Qt Project Hosting Foundation" (from whois record) >     take care of that? >     What is going on? > >     Chris >     _______________________________________________ >     Development mailing list >     Development at qt-project.org >     http://lists.qt-project.org/mailman/listinfo/development >     > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Oct 31 17:46:06 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 31 Oct 2018 09:46:06 -0700 Subject: [Development] Qt6 source changes In-Reply-To: <55CC6C02-355A-47E5-9935-9A124D8ACCA0@gmail.com> References: <55CC6C02-355A-47E5-9935-9A124D8ACCA0@gmail.com> Message-ID: <2595549.zIR5TNrLAL@tjmaciei-mobl1> On Wednesday, 31 October 2018 03:19:46 PDT Иван Комиссаров wrote: > Hello, Thiago wrote in the "buildsystem thread" that Qt 6 will be source > compatible with Qt5. As long as I fully support source-compatibility with > both hands, I would like to ask several questions about possible > source-breaking changes. Qt6 won't be fully source-compatible. The idea is that we'll break it to fix things, but attempt to keep compatible as much as possible to avoid death by a thousand paper cuts. > 2) QVariantList/QList and friends. I would like to to see most of > QList usages in Qt eliminated in favor of QVector. I won't repeat Marc's > arguments against QList. Instead, I want to ask the other thing - is > breaking user code that uses "QList list = someQtApiFunc();" is > forbidden too? If Assumption that QVector is API-compatible with QList > (which is not true, I suppose, but can be mostly fixed) that should not be > a big deal to replace the usages of a QList with "auto list = > someQtApiFunc();". Qt should really evolve and stucking with QList for the > next 10 years is a bad idea IMO. We're studying what to do with QList, but the idea is that the name "QList" will be completely ok and identical to QVector. The technical mechanism is in flux. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Oswald.Buddenhagen at qt.io Wed Oct 31 17:46:12 2018 From: Oswald.Buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 31 Oct 2018 16:46:12 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: <1a0c2ef8-5ed2-1194-80e7-4d9303c7a137@gmail.com> References: <20181030171752.GE9915@troll08> <20181030182501.GF9915@troll08> <6d692097-14fc-95bc-c323-32af6f635197@gmail.com> <20181030215059.GA11838@ugly> <1a0c2ef8-5ed2-1194-80e7-4d9303c7a137@gmail.com> Message-ID: <20181031164610.GA18625@troll08> On Wed, Oct 31, 2018 at 10:17:04AM -0400, Matthew Woehlke wrote: > On 30/10/2018 17.51, Oswald Buddenhagen wrote: > > for starters just some food for thought: > > QBS-995 should be implementable on top of it. > > if you want to go full monty, QBS-942 is your target. > > What are those? Can you provide links? > qt jira tasks. ;) for me they are the first hits on google ... > > one thing i noticed is that you multiplex build variants and other stuff > > into a single file. this is not helpful for packaging. > > This is not entirely true; a single package specification *can* be split > into multiple units. (I'm not sure this is well documented, but it is > definitely intended. OTOH, while I'm pretty sure this is well supported > for separate *components*, I'm less sure about separate *configurations* > of the same component, so maybe there is room for improvement.) > There does need to be one package that owns the "root" specification, > but this is not so different from one package owning the top level > directory. > for components, that seems unnecessary in principle. if there is anything shared, that's rather naturally expressed by there typically being a central sub-package which every other one depends on anyway (say, qtcore). for build variants you'd indeed get 100% redundancy with my concept, but that really doesn't sound exceedingly problematic given that we're talking about small auto-generated files. > > after much thinking about the matter, i concluded that the interface > > files should correspond to "atomic linkable entities", which > > essentially means actual libraries > > That's basically the pkg-config approach... and I believe that design > to be intractable. In short, it fails to specify how to do the > equivalent of `find_package(X COMPONENTS A B C)`. > i'd just aggregate by components: {qt.core, qt.gui} is the same as {qt.{core, gui}}. not sure what qbs currently does internally ... > Especially if you have e.g. (ignoring 'C' for simplicity): > > X.A-1.2 > X.A-1.0 > X.B-1.1 > X.B-1.0 > > You *have* to be able to do package-level queries; otherwise, how do you > know (assuming X-1.z are mutually incompatible, but the consumer can use > any X-1.z) to use X-1.0? > you can specify version constraints in the dependencies like e.g. debian packages do. > > not one interface to describe all build variants, > > Aside from this isn't how lots of existing packages work, how would you > then architect the system to allow the user to both be able to choose > which build variant to use *or* to just pick one? Requiring the user to > know which variant they want is an anti-goal. > one can priorize certain property values, both inside the interface and on the consumer side. > > and not one interface to describe each architecture variant within a > > multi-arch library. > > Actually, I'm not sure if this would work. > slicing interfaces would work just fine for mac, because it's possible to use just one architecture slice at any given time. however, it would be inefficient (more tool calls) and at some point one needs to join the own build artifacts into a multi-arch binary again anyway. of course, one could make the consuming system intelligent enough to recognize that a group of interfaces refer to different slices of the same binary, but that seems unnecessarily complex. conversely, having "lumped" multi-arch interfaces works as well, because that just represents the reality of the binaries. however, the interface then actually needs to specify a list of contained architectures. From thiago.macieira at intel.com Wed Oct 31 17:47:14 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 31 Oct 2018 09:47:14 -0700 Subject: [Development] qMoveToConst helper for rvalue references to movable Qt containers? In-Reply-To: <20181031165208.2FC5.6F0322A@gmail.com> References: <41f44d86-861a-ea69-d0a1-fcd1f636146c@kdab.com> <1617550.SAbemMF5Zp@tjmaciei-mobl1> <20181031165208.2FC5.6F0322A@gmail.com> Message-ID: <1554374.7bIYhBLJmk@tjmaciei-mobl1> On Wednesday, 31 October 2018 08:52:10 PDT Philippe wrote: > Hence best is: > > for (auto &element : std::as_const(container)) Which is why we added qAsConst. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mwoehlke.floss at gmail.com Wed Oct 31 18:09:13 2018 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 31 Oct 2018 13:09:13 -0400 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181031164610.GA18625@troll08> References: <20181030171752.GE9915@troll08> <20181030182501.GF9915@troll08> <6d692097-14fc-95bc-c323-32af6f635197@gmail.com> <20181030215059.GA11838@ugly> <1a0c2ef8-5ed2-1194-80e7-4d9303c7a137@gmail.com> <20181031164610.GA18625@troll08> Message-ID: On 31/10/2018 12.46, Oswald Buddenhagen wrote: > On Wed, Oct 31, 2018 at 10:17:04AM -0400, Matthew Woehlke wrote: >> On 30/10/2018 17.51, Oswald Buddenhagen wrote: >>> after much thinking about the matter, i concluded that the interface >>> files should correspond to "atomic linkable entities", which >>> essentially means actual libraries >> >> That's basically the pkg-config approach... and I believe that design >> to be intractable. In short, it fails to specify how to do the >> equivalent of `find_package(X COMPONENTS A B C)`. > > i'd just aggregate by components: {qt.core, qt.gui} is the same as > {qt.{core, gui}}. not sure what qbs currently does internally ... Again, how then does the consuming tool know which qt.core and which qt.gui are compatible with each other? How does it handle the case of finding a qt.core with no matching qt.gui? Having a top-level spec provides a well-defined answer to these sorts of problems; if the top-level spec doesn't meet the user's requirements, you ignore the entire thing and keep looking. >> Especially if you have e.g. (ignoring 'C' for simplicity): >> >> X.A-1.2 >> X.A-1.0 >> X.B-1.1 >> X.B-1.0 >> >> You *have* to be able to do package-level queries; otherwise, how do you >> know (assuming X-1.z are mutually incompatible, but the consumer can use >> any X-1.z) to use X-1.0? > > you can specify version constraints in the dependencies like e.g. debian > packages do. Again, please explain how you will ask the consuming tool to find your requirements, and how it will accomplish this task. With CPS as currently designed, it is easy: # CMake syntax, but same principle would apply to any tool find_package(X COMPONENTS A B) I think you are suggesting that finding build requirements has to be done as a single, monolithic pass; i.e. a project must specify ALL of its requirements before ANY attempt is made to satisfy those requirements. But a) that's harder to implement, and b) existing build systems do not work that way (at least, both CMake and autotools don't). Moreover, a package+components based model (i.e. CPS in its current form) can be made to work with a tool that *does* work that way (QBS?), but you have not demonstrated how a components-only model could be made to work with a tool that does *not* do global dependency solving. (Admission: CPS has been strongly influenced by what *CMake* needs. A specification that doesn't satisfy CMake's needs, e.g. pkg-config, is probably a non-starter as far as potentially replacing CMake's current stuff.) -- Matthew From Oswald.Buddenhagen at qt.io Wed Oct 31 19:26:50 2018 From: Oswald.Buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 31 Oct 2018 18:26:50 +0000 Subject: [Development] Build system for Qt 6 In-Reply-To: References: <20181030171752.GE9915@troll08> <20181030182501.GF9915@troll08> <6d692097-14fc-95bc-c323-32af6f635197@gmail.com> <20181030215059.GA11838@ugly> <1a0c2ef8-5ed2-1194-80e7-4d9303c7a137@gmail.com> <20181031164610.GA18625@troll08> Message-ID: <20181031182647.GB18625@troll08> On Wed, Oct 31, 2018 at 01:09:13PM -0400, Matthew Woehlke wrote: > On 31/10/2018 12.46, Oswald Buddenhagen wrote: > > On Wed, Oct 31, 2018 at 10:17:04AM -0400, Matthew Woehlke wrote: > >> On 30/10/2018 17.51, Oswald Buddenhagen wrote: > >>> after much thinking about the matter, i concluded that the interface > >>> files should correspond to "atomic linkable entities", which > >>> essentially means actual libraries > >> > >> That's basically the pkg-config approach... and I believe that design > >> to be intractable. In short, it fails to specify how to do the > >> equivalent of `find_package(X COMPONENTS A B C)`. > > > > i'd just aggregate by components: {qt.core, qt.gui} is the same as > > {qt.{core, gui}}. not sure what qbs currently does internally ... > > Again, how then does the consuming tool know which qt.core and which > qt.gui are compatible with each other? How does it handle the case of > finding a qt.core with no matching qt.gui? > as i said below, by the sub-packages constraining their transitive dependencies. > Having a top-level spec provides a well-defined answer to these sorts of > problems; if the top-level spec doesn't meet the user's requirements, > you ignore the entire thing and keep looking. > that answer might be unnecessarily strict, though. if i build a 3rd-party qt module and install it into /opt/myqt, it might be compatible with the system qt in /usr. i want to be able to use that additional qt module by depending on {qt.{core,gui,3rdpartymodule}}. > >> You *have* to be able to do package-level queries; otherwise, how do you > >> know (assuming X-1.z are mutually incompatible, but the consumer can use > >> any X-1.z) to use X-1.0? > > > > you can specify version constraints in the dependencies like e.g. debian > > packages do. > > Again, please explain how you will ask the consuming tool to find your > requirements, and how it will accomplish this task. > > With CPS as currently designed, it is easy: > > # CMake syntax, but same principle would apply to any tool > find_package(X COMPONENTS A B) > > I think you are suggesting that finding build requirements has to be > done as a single, monolithic pass; i.e. a project must specify ALL of > its requirements before ANY attempt is made to satisfy those > requirements. > but that's exactly what you do anyway with the syntax above, within the scope of a single package. whether the interfaces are explicitly aggregated by some top-level file or implicitly by some shared properties and mutual constraints is completely inconsequential for the user. From mwoehlke.floss at gmail.com Wed Oct 31 20:41:49 2018 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 31 Oct 2018 15:41:49 -0400 Subject: [Development] Build system for Qt 6 In-Reply-To: <20181031182647.GB18625@troll08> References: <20181030171752.GE9915@troll08> <20181030182501.GF9915@troll08> <6d692097-14fc-95bc-c323-32af6f635197@gmail.com> <20181030215059.GA11838@ugly> <1a0c2ef8-5ed2-1194-80e7-4d9303c7a137@gmail.com> <20181031164610.GA18625@troll08> <20181031182647.GB18625@troll08> Message-ID: On 31/10/2018 14.26, Oswald Buddenhagen wrote: > On Wed, Oct 31, 2018 at 01:09:13PM -0400, Matthew Woehlke wrote: >> Again, how then does the consuming tool know which qt.core and which >> qt.gui are compatible with each other? How does it handle the case of >> finding a qt.core with no matching qt.gui? > > as i said below, by the sub-packages constraining their transitive > dependencies. That is insufficient. A.X can be used by itself. A.Y also can be used by itself. However, mixing different versions of A.X and A.Y is an error. Even if you propose to solve this by having both A.X and A.Y depend on a "virtual" A.base target of the same version, you still haven't explained how to make it so a consumer can find the correct version of A in the pathological scenario I outlined without a global dependency solver. Please explain this, not with platitudes, but with a *concrete example*, i.e. show what the components specifications would look like and what steps the build tool will take to find the correct versions of the components. >> Having a top-level spec provides a well-defined answer to these sorts of >> problems; if the top-level spec doesn't meet the user's requirements, >> you ignore the entire thing and keep looking. > > that answer might be unnecessarily strict, though. if i build a > 3rd-party qt module and install it into /opt/myqt, it might be > compatible with the system qt in /usr. i want to be able to use that > additional qt module by depending on {qt.{core,gui,3rdpartymodule}}. Well, then, don't make it part of the "Qt" package. I don't think you can have it both ways. (If it's a third-party module, why is it a first party component of the "Qt" package?) >> I think you are suggesting that finding build requirements has to be >> done as a single, monolithic pass; i.e. a project must specify ALL of >> its requirements before ANY attempt is made to satisfy those >> requirements. > > but that's exactly what you do anyway with the syntax above, within the > scope of a single package. whether the interfaces are explicitly > aggregated by some top-level file or implicitly by some shared > properties and mutual constraints is completely inconsequential for the > user. Not quite. CPS as currently specified does need bookkeeping, but it does *not* need global dependency solving. (Although this does, admittedly, have the disadvantage that it may fail in cases where global solving might succeed, and thus require more user hand-holding to arrive at an overall acceptable "answer".) As there is no global solving, each request to find a package is considered on its own: - First, look for a candidate package. - For each candidate: - If that package's arch is incompatible, TTA¹. - If that package has a dependency for which an incompatible version is already "being used", TTA. - For each of the package's dependencies, recursively invoke this process. - If dependencies could not be found, TTA. - If the candidate does not provide the components required by the consumer, TTA. (¹ "Try, Try Again"... IOW, make a note of why this package is not acceptable and continue with the next candidate. If no suitable candidate is found, these notes may be used to tell the user why a candidate was rejected.) The difference is that, once a package is found, it is found, and cannot be "un-found". The tool does not have to try all possible candidates in all possible combinations. Also, this process can be dropped into existing build tools that also look for one package (or component) at a time. It is not implausible, for example, that I could write a CLI-compatible pkg-config implementation that uses CPS, or that I could extend CMake's find_package to look for CPS's and turn them into imported targets. This means that CPS has the potential to "just work" with existing build tools, and even existing software using those build tools. In fact, this is explicitly one of the goals of CPS. A system relying on global dependency solving can't do that. (The bookkeeping is that the system can't "commit" to adding dependencies into the global space until a candidate is accepted, so it needs a separate "holding space" that it can throw out again if it turns out a candidate is not viable.) -- Matthew From chgans at gmail.com Wed Oct 31 22:50:26 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Thu, 1 Nov 2018 10:50:26 +1300 Subject: [Development] Who is in charge of qt-project.org? In-Reply-To: <1677105861.30132854.1541003029183@mail.yahoo.com> References: <1677105861.30132854.1541003029183.ref@mail.yahoo.com> <1677105861.30132854.1541003029183@mail.yahoo.com> Message-ID: On Thu, 1 Nov 2018 at 05:28, Kain Vampire via Development wrote: > > WHAT A TWAT! > > P.S. > > Yes, feel free to ban me, it was worth it. Was it? You could have used the word 'idiot', at least it is not an insult to the feminine gender. You could have as well quoted which part of the message you didn't like. I'm taking you didn't like part 2. This was obviously a provocative statement, but it was not an insult. I still stand that the qt-projects.org domain should not be managed (directly or indirectly) by the Qt Company, there is a clear conflict of interest. Something that has been raised several times in the past (Check the mailing list archives about the captive/deceptive portal hat is/was the Qt's download page). lists.qt-projects.org has had issue for more than a month, and (suddenly) got resolved overnight. [Side note: http stopped to redirect to https, but https is still down, which means that https urls returned by search engine are broken. Whoever runs codereview.qt-project.org has access to a wildcard ssl certificate (*.qt-project.org), but it seems that whoever runs lists.qt-project.org doesn't.] As an experience, try to type "download qt" in you favorite search engine, and tell me what you get, here is my top results: https://www.qt.io/download https://www1.qt.io/offline-installers/ https://download.qt.io/archive/qt/ qt-project.org/downloads The interesting bit is that qt-project.org/downloads redirects to https://www.qt.io/download. Basically, qt-projects.org is just a facade to qt.io, I think this is not healthy. There is no public expression of the "Qt Project". Concerning, the "Qt Project Hosting Foundation", i've found: https://wiki.qt.io/Qt-contributors-summit-2014-QtCS2104_Foundation https://investors.qt.io/governance/management/ (where it is mentioned that Tuukka Turunen is a "Chairman of the Board of Directors in the Qt Project Hosting Foundation") http://website.informer.com/Cristina+Hamley+Qt+Project+Hosting+Foundation.html Chris PS: I do not hate the Qt Company, nor do I hate anyone working for them. Without license, without money, there would be no "Qt Company", and without "Qt Company", the "Qt Project" would be substantially different. As a license owner and an OSS enthusiast I am thankful to the Qt Company and to all numerous direct and indirect "Qt Project" contributors.