[Development] HEADS-UP: Branching from '6.4' to '6.4.0' done
Hi Everyone! We have branched '6.4.0' from '6.4' now. So from now on all changes targeted to Qt 6.4.0 release must have 'Pick-to: 6.4.0' and '6.4' is for Qt 6.4.1. There were a few changes staged/integrating at branching time, please check if those need to be cherry-picked in '6.4.0' or not (I already added a comment in those changes). And like earlier staging in '6.4.0' will be restricted to the release team only. Please don't push any nice-to-haves in '6.4.0' anymore. We will monitor changes in '6.4.0' and stage clear blocker fixes automatically. Target is to freeze Qt 6.4.0 RC content at the beginning of next week so please make sure all blockers are fixed and fixes are in '6.4.0' by the end of this week. Blocker list here: https://bugreports.qt.io/issues/?filter=24367 br, Jani Heikkinen Release Manager ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Unscheduled maintenance break for codereview.qt-project.org starting now
Hi, Codereview.qt-project.org is back online. The issue was a huge disk cache that was slowing requests instead of serving them faster Unfortunately also session data was cleaned, so everyone needs to login again. --Jukka From: Development on behalf of Jukka Jokiniva Date: Monday, 5. September 2022 at 19.31 To: qt-dev Subject: [Development] Unscheduled maintenance break for codereview.qt-project.org starting now Hi, Currently codereview.qt-project.org is very slow and in practice unusable. I’ll take it offline as standard reboot doesn’t fix the issue. I’ll keep you informed about the progress. --Jukka Jokiniva, Gerrit Admin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype
Hi, Experience shows that we'll have many, many, many things to consider come Qt 7. And as Qt 6 has shown, such trivialities will be left by the wayside. So, playing the devil's advocate here: if this work is too much for Qt 6.x, what makes us think we'll get it done in the frenzy leading up to Qt 7.0? We have the tools (QT_REMOVED_SINCE + Ivan's work on -disable-deprecated-until) to have a user-configurable, rolling BC window now. We should use these tools to avoid accumulating too much technical debt until 7.0. From a C++ POV, we now only need major versions to break polymorphic inheritance (incl., but not limited to, virtuals), and signals and slots (the latter because of conflicting SC-solutions for new-style and old-style connects). That said, no actual user-visible size-mismatch bug has yet required the change of public interfaces. So there's definitely two stages here: 1) fixing the implementation (we must do this) and 2) fixing the API (much less urgent iff our headers are clean w.r.t. aggressive narrowing warnings (-Wnarrowing) so users can enable them for their own projects to catch the bugs at the API boundary). So, I think the priority and therefore work order should be: 1. Fix all int/uint in the implementation 2. Fix our headers (public and private) to be resistant to aggressive narrowing-conversion compiler warnings 3. Enable said compiler warnings for (growing subsets of) Qt implementation code 4. Fix our APIs Seeing as user-side truncation occurs when passing to function arguments, and seeing that function arguments are much less critical when it comes to SC than function return values, we might even split the API update part to fix setters first, and only then getters. That said, sometimes it's just simpler to do the API change together with the rest. I wouldn't worry too much about the effect this has on users of Qt APIs: Function argument widening is SC, and function return value widening can be buffered with liberal use of auto on the side of the user (I don't want to count the number of trivial bugs that would have been prevented in the Qt5->6 port if Qt didn't have such a conservative stance on the use of auto). We should just communicate clearly that for the next few releases, any int in the API is subject to potential porting to qsizetype, and suggest users to prepare their own code for the change, ideally already in the Qt 6.4.0 changelog, and then in all following ones. Thanks, Marc ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Unscheduled maintenance break for codereview.qt-project.org starting now
Hi, Currently codereview.qt-project.org is very slow and in practice unusable. I’ll take it offline as standard reboot doesn’t fix the issue. I’ll keep you informed about the progress. --Jukka Jokiniva, Gerrit Admin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype
> On 5 Sep 2022, at 14:46, Alex Blasche wrote: >> -Original Message- >> From: Development On Behalf Of >> Marc Mutz […] >> I just want to raise awareness of the issue, which, really, is just an >> incomplete >> port of the Qt containers to qsizetype in 6.0. >> >> Over the last months, however, I've realized that "just the Qt containers" >> introduces a nasty API inconsistency in Qt: qsizetype in Qt containers and >> int >> elsewhere. This inconsistency is un-Qt-ish and creates problems for our >> users. […] > I like the container.size() vs setFoo(int) use case as example to decide how > far we want to spin this inconsistency further ahead throughout all of Qt . I > totally agree with Marc's argument that it is not Qtish and causes pain to > every user. I guess we have three options: > > 1.) What I am wondering though is if we were to sink all the time into Qt to > convert all API's, would Qt be blamed for all the continued porting effect > throughout the years on this issue? After all we cannot do this for one > single release in one go. It would probably find its way into each release > over a couple of years. Does this help Qt in its goal to be easy to use? The > compatibility layer does add its own layer of complexity. > > 2.) An alternative might be to make this change in one go for Qt 7. We would > keep Qt 6.x on the status quo but start adding compatible replacement APi > with an absolute change at 7.0 (ifdefs or typedefs come to mind). Users would > only be burdened one time (though it being one BIG time effort). Such a > change would be much simpler in Qt headers. > > 3.) On the other hand, we have had a lot of Qt 6 ports already and so far, it > did not come up as a major issue in those ports. Could we simply accept this > inconsistency? After all, would QSplitter ever need setWidget(qsizetype, > QWidget*)? Under this scenario we might agree to convert all internal Qt uses > of containers but leave the public API untouched. Of course some dedicated > use case, where extra large files/chunks of data should be read, could get > the treatment much earlier. > > Personally, I cannot agree whether I like Option 2 or 3 more. We have virtual functions that take int and could potentially be fed by the return value of container.size() (or generally need to be able to handle values >2G), so should take a qsizetype (say, QAbstractItemModel::insertRows, overridden by QSqlTableModel). I don’t see how we can change those until Qt 7. So we will have to live with some inconsistency. Given that, and also trying to be pragmatic wrt the effort required (potentially also in client code) in relation to the likelihood of real issues, I’d say that we should focus the proactive effort on QtCore, QtNetwork, QtSQL, QtWebSockets/Channel, and perhaps a few more modules that are likely to have to process >2G quantities of data. In those modules, perhaps there’s a security component to consider, where wrong handling of qsizetype might enable an integer overflow attack. For the other modules, esp those related to user interface development, the chance that an int-API is called with a value above 2G seems very low, even if they are operating internally on Qt containers. I might be missing some real world examples though where e.g. QGraphicsScene or a QTextDocument needs to operate on >2G items. >> the hope is that once we've progressed somewhat, we can enlist compiler >> support >> by globally enabling warnings such as -Wshorten-64-to-32 Would be great if we can do that for the modules above, at least, to avoid further deterioration. And once we have established an acceptable baseline, it would help a lot with doing the rest (or at least more) of the work for Qt 7. Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Proposal to address "Ghost Maintainers"
Hi, Following the “Ghost Maintainer” discussion at the Qt Contributors Summit in June [1] (non-conclusive, but nevertheless relevant), I have proposed a change to the governance model [2] that makes it clearer what is expected from Maintainers, and less (potentially) confrontational to replace inactive maintainers. The latest version of the proposal incorporates all comments made to that change by the reviewers so far. [2] https://codereview.qt-project.org/c/meta/quips/+/423766 This is a material change to the governance model, so great if you can have a look and give a +1 if you agree with it, or otherwise share your objection. Thanks, Volker [1] https://wiki.qt.io/Qt_Contributors_Summit_2022_-_Program/Ghost_Maintainers ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype
> -Original Message- > From: Development On Behalf Of > Marc Mutz I am taking the hot potato and spin this futher. > You may have seen the qsizetype patches we've been pushing over the last > months. This is to give my perspective on the issue and why I think it's > needed: > > First off, while I made QStringView qsizetype'd, because it was designed to > take > input from STL containers[1], I was not involved in the decision to port even > just > the Qt containers to qsizetype in 6.0. > > [1] (it originally used size_t, which is what the STL containers use as > size_type > but it was requested to use a signed type during review) > > I do observe, though, that, starting with the premiss of a Qt container of > size > 2 > Gi, the current code base has a pretty high bug density in this area: Absolutely this must be fixed. Those are plain bugs. <...> > The majority of changes are targeting the second goal. Bugs that fall in the > first > category, like the ones listed above. are user-visible, usually get a commit > and > Jira ticket of their own. > > I don't really want to start a discussion on whether (owning) Qt containers > _should_ support more than 2 Gi elements in the first place. > From my pov, that decision has been made in the run-up to 6.0, and everyone > who knows me knows that I don't much care about the owning Qt containers > and their shortcomings. Indeed. It was decided. > I just want to raise awareness of the issue, which, really, is just an > incomplete > port of the Qt containers to qsizetype in 6.0. > > Over the last months, however, I've realized that "just the Qt containers" > introduces a nasty API inconsistency in Qt: qsizetype in Qt containers and int > elsewhere. This inconsistency is un-Qt-ish and creates problems for our users. > > First up, it's unclear what a Qt container is: is QRegion a container? > What does numRects() return when you setRects with a QList with > 2Gi > elements? Where do we draw the line between Qt container and Qt non- > container? See, in particular, QDataStream's inability to serialize > containers > 2 > Gi (and, in the case of QString, even > 1 Gi). > > Second, the truncation that users face on c.size() (qsizetype) -> > setFoo() (int) is using modulo arithmetic, not saturation arithmetic, so the > result > is very unpredictable: INT_MAX + 1 elements turn into 0 elements, not INT_MAX, > etc, creating a lot of opportunities for False Positives or Negatives, even > with > modestly oversized containers (INT_MAX > + å). The central Qt API guideline is to make APIs easy to use and hard > to misuse. Both parts are violated here, especially since, while compilers > regularly warn about signed/unsigned mismatches, they seldomly warn about > narrowing (proof: Qt compiles). To fix the inconsistency means to port also > the > "non-container" APIs to qsizetype, and handle/detect/defend against overflow > _centrally_, so we don't inflict the issue on every user of the APIs. I like the container.size() vs setFoo(int) use case as example to decide how far we want to spin this inconsistency further ahead throughout all of Qt . I totally agree with Marc's argument that it is not Qtish and causes pain to every user. I guess we have three options: 1.) What I am wondering though is if we were to sink all the time into Qt to convert all API's, would Qt be blamed for all the continued porting effect throughout the years on this issue? After all we cannot do this for one single release in one go. It would probably find its way into each release over a couple of years. Does this help Qt in its goal to be easy to use? The compatibility layer does add its own layer of complexity. 2.) An alternative might be to make this change in one go for Qt 7. We would keep Qt 6.x on the status quo but start adding compatible replacement APi with an absolute change at 7.0 (ifdefs or typedefs come to mind). Users would only be burdened one time (though it being one BIG time effort). Such a change would be much simpler in Qt headers. 3.) On the other hand, we have had a lot of Qt 6 ports already and so far, it did not come up as a major issue in those ports. Could we simply accept this inconsistency? After all, would QSplitter ever need setWidget(qsizetype, QWidget*)? Under this scenario we might agree to convert all internal Qt uses of containers but leave the public API untouched. Of course some dedicated use case, where extra large files/chunks of data should be read, could get the treatment much earlier. Personally, I cannot agree whether I like Option 2 or 3 more. -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Monthly CI maintenance break - September (Mon 5th Sep 2022)
This maintenance break is DONE From: Ville-Pekka Karhu Sent: Monday, September 5, 2022 08:05 To: Qt development mailing list Subject: Re: Monthly CI maintenance break - September (Mon 5th Sep 2022) This maintenance break starts NOW From: Ville-Pekka Karhu Sent: Monday, August 29, 2022 13:05 To: Qt development mailing list Subject: Monthly CI maintenance break - September (Mon 5th Sep 2022) Hi all! We’ll have our scheduled maintenance break on next Monday (5th of September). We’ll begin our work at 5:00 UTC and you can prepare for 6 hours of CI not working. Br, VP ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Repository request: playground/qtscrypt
On 9/2/22 18:04, Oswald Buddenhagen wrote: On Fri, Sep 02, 2022 at 02:15:15PM +, Volker Hilsheimer wrote: +1 to go ahead with QtPythonScripting as the name and repository. how about QtPyScript? that's not so long, and makes the parallel to QtScript very obvious. Hey Ossi, I'd like that name too, but in June this year the 'PyScript' project was announced [1] So it might be confusing for Python users thinking it's a Qt wrapper or library to develop Python applications in WebAssembly. Cheers [1] https://pyscript.net/ -- Dr. Cristián Maureira-Fredes Senior R Manager The Qt Company GmbH Erich-Thilo-Str. 10 D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
