Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On 05.02.2020 13:04, Jani Heikkinen wrote: > >> -Original Message- >> From: Eskil Abrahamsen Blomfeldt >> Sent: keskiviikko 5. helmikuuta 2020 13.06 >> To: Edward Welbourne ; Jani Heikkinen >> ; Lars Knoll ; Volker Hilsheimer >> >> Cc: Qt development mailing list ; >> releas...@qt-project.org >> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is >> in effect now >> >> >> On 05.02.2020 11:50, Edward Welbourne wrote: >>> Jani Heikkinen (5 February 2020 06:42) Why this is so important that we should get the exception & go in after >> FF? >>> Do we allow changes approved before feature freeze to get past the >>> Coin hurdle, even if that happens after FF ? How much fixing of the >>> change (if it turns out to have problems integrating) is acceptable, >>> before we declare that it's no longer the change that was approved in time >> ? >> >> >> If the change is ready and approved by the time of feature freeze and only >> delayed by CI problems, failures from other changes in a batch, or the >> awkwardness of our dependency structure, I think it has to be acceptable to >> merge after the freeze. Otherwise feature freeze becomes a lottery where >> the features in a given release is based mostly on chance. > By default we shouldn't put any new features in after FF, not even those > which were approved early enough. Not respecting the freeze date was one of > biggest reasons why we failed to keep the release schedule with earlier > releases. And after we started to be much tighter with the freeze we have > been much better to keep the schedules as well... Hi, You are looking at this from a very different perspective than me, which is totally understandable. As a developer of the product, I want a deadline for when I should have my feature finished. If the deadline is "maybe one month before the feature freeze, maybe one week, who knows it kind of depends on whether the CI system is acting up and what other changes your fix happens to be bundled with", then that makes it impossible to plan anything. If we estimate, based on statistics, that it will take one month to get features in, then we should set the feature freeze one month earlier. If we think it will take one week, then we should set it one week earlier. At least we should give people a specific date and guarantee that if they make it in time for this, their change will be in the next release. If this is one month before the actual feature freeze, then so be it. If it takes that long to get a change in, then definitely should be very visible to everyone, including the stake-holders who depend on features being released when we say. If it turns out that we miscalculated the estimate, then this should just cause a delay to the release. It shouldn't cause us to make a release containing a random set of features based on whoever won the lottery this time. I understand that your responsibility is making the release on time, and late submissions make this difficult, but the way to solve this is to add the extra slack between the feature freeze and the point where we can start stabilizing to the release schedule. If we see that changes that are staged at the freeze date consistently take between 1 day and 1 week to merge because we have broken systems or because so many people stage their changes at the same time, then that means we have to extend the period between freeze and release by one week. > We are doing time based releases so if new feature misses the deadline > there will be next one coming after few months. It might be quite long > time for unique feature but on the other hand it isn't really that > long... Our goal is to cut the schedule between FF and final release, > not reserving more time there. Ok, currently there is of course some > buffer in; Release plans are based on previous releases and realized > schedules there. But we should be able to develop our ways of working > & our release systems so that we can make that time much shorter. That > way we could get more time to develop new features. The next one will be coming after six months in most cases (Qt 5.15 is special of course). This is a pretty long time. But more importantly, expecting every single developer in the Qt community to internalize the flakiness of the CI system or the risk that your change may be rejected because it happened to be bundled with a broken change is the wrong angle in my opinion. We would just be distributing the responsibility of analyzing our release systems to hundreds of people instead of doing it once, as part of the release planning. So if you know how long it will typically take for a change to get in, then why not give people the actual date they should target in order to be sure to get their changes merged? And if our estimates are wrong, then we should own that mistake, instead of telling developers that their changes have missed the deadline because we are una
Re: [Development] The future of smart pointers in Qt API
QList is most definitely a typedef to QVector in Qt/dev: https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/tools/qcontainerfwd.h > On 6. Feb 2020, at 20:20, Иван Комиссаров wrote: > > Wait, what?? When did that decision was made? > > I am tired fixing performance bugs induced be the replacement QList with > QList>, can we please get rid of the QList class finally? > >> 6 февр. 2020 г., в 20:14, Matthew Woehlke >> написал(а): >> I thought we decided *not* to >> do that!) >> > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Erich-Thilo-Straße 10 D-12489 Berlin eike.zil...@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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating André Hartmann for maintainer for QCanBus API
Its been a while and I lost track of this thead. Congratulations to André. I recorded the change of maintainership in https://wiki.qt.io/Maintainers -- Alex From: Development on behalf of Alex Blasche Sent: Tuesday, 26 November 2019 09:36 To: development@qt-project.org Subject: [Development] Nominating André Hartmann for maintainer for QCanBus API Hi, The QCanbus API is part of the QtSerialBus module. Since its first release it has come a long way. In particular, André Hartmann & Denis Shienkov made big contributions over time. For that I am very grateful. Thank you. As the current maintainer of the QCanBus API I would like to hand the maintainer baton over to André. He has done a very good job of fixing the day-to-day issues popping up on a regular base. Unrelated to QtSerialBus, he contributed to Qt Creator and other parts in QtBase. -- Alex ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
> Edward Welbourne > > Alexander Akulich (6 February 2020 16:33) asked: > > Are we going to provide some Qt5 → Qt6 migration tool? > > https://codereview.qt-project.org/c/qt/qtrepotools/+/289121 > > > It is trivial to grep the sources for > > "SIGNAL(error(QAbstractSocket::SocketError))" and print a warning > > about the dangerous Qt4-style connection. > > Check with Friedemann on the review, but I suspect he'd welcome a patch that > adds that to the tool. I think clazy has a check for this already? https://github.com/KDE/clazy/blob/master/docs/checks/README-old-style-connect.md Mark ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
I commented on one exact situation: if we rename QAbstractSocket::error(QAbstractSocket::SocketError) signal then we can easily grep sources for all Qt4-style connections to this particular signal (because it has a very special signature). There is a place for false-positives but I think it is acceptable. On Fri, Feb 7, 2020 at 12:38 PM Mark De Wit wrote: > > > Edward Welbourne > > > Alexander Akulich (6 February 2020 16:33) asked: > > > Are we going to provide some Qt5 → Qt6 migration tool? > > > > https://codereview.qt-project.org/c/qt/qtrepotools/+/289121 > > > > > It is trivial to grep the sources for > > > "SIGNAL(error(QAbstractSocket::SocketError))" and print a warning > > > about the dangerous Qt4-style connection. > > > > Check with Friedemann on the review, but I suspect he'd welcome a patch that > > adds that to the tool. > > I think clazy has a check for this already? > > https://github.com/KDE/clazy/blob/master/docs/checks/README-old-style-connect.md > > Mark ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On 05.02.2020 11:50, Edward Welbourne asked: Do we allow changes approved before feature freeze to get past the Coin hurdle, even if that happens after FF ? How much fixing of the change (if it turns out to have problems integrating) is acceptable, before we declare that it's no longer the change that was approved in time ? Eskil Abrahamsen Blomfeldt (keskiviikko 5. helmikuuta 2020 13.06) replied: >>> If the change is ready and approved by the time of feature freeze >>> and only delayed by CI problems, failures from other changes in a >>> batch, or the awkwardness of our dependency structure, I think it >>> has to be acceptable to merge after the freeze. Otherwise feature >>> freeze becomes a lottery where the features in a given release is >>> based mostly on chance. Makes sense. See below. On 05.02.2020 13:04, Jani Heikkinen wrote: >> By default we shouldn't put any new features in after FF, not even >> those which were approved early enough. Not respecting the freeze >> date was one of biggest reasons why we failed to keep the release >> schedule with earlier releases. And after we started to be much >> tighter with the freeze we have been much better to keep the >> schedules as well... Eskil Abrahamsen Blomfeldt (7 February 2020 08:58) > You are looking at this from a very different perspective than me, > which is totally understandable. Indeed - still, let us all try to see this from each others' perspectives. That gives a better chance of finding a resolution we can all be happy with. > As a developer of the product, I want a deadline for when I should > have my feature finished. If the deadline is "maybe one month before > the feature freeze, maybe one week, who knows it kind of depends on > whether the CI system is acting up and what other changes your fix > happens to be bundled with", then that makes it impossible to plan > anything. On the other hand, if a change that should be subject to FF turns out to have problems that mean it wasn't actually ready in time, how severe can those problems be and *not* imply that we should keep that feature out ? This week, we've given special dispensation for things that were delayed due to minor problems that were known at the time of FF. That seems a reasonable level of flexibility in an otherwise hard FF. If a change that seemed ready for merge last Friday turns out to cause problems that weren't anticipated then, unless they are promptly resolved and low-risk (given the previously accepted change), it makes sense to block that change until the next release - otherwise, the release process becomes chaos, as it voids FF's rule about what's in and what's out. [snip] > The next one will be coming after six months in most cases (Qt 5.15 is > special of course). This is a pretty long time. But more importantly, > expecting every single developer in the Qt community to internalize > the flakiness of the CI system or the risk that your change may be > rejected because it happened to be bundled with a broken change is the > wrong angle in my opinion. I don't think anyone is currently standing for that position: if the only thing that's kept a change out is CI failure, or being staged alongside someone else's broken change [0] on the day of FF, then I think we're all in agreement that the change "made it in time". On the other hand, the broken change whose premature staging blocked others' changes from getting integrated *should* be subject to scrutiny - if it can be fixed safely, satisfactorily and promptly then fine, but if it's going to delay other changes with further integration failures then we should be ready to Just Say No to it after the FF deadline passes. [0] and you know which change I'm thinking of, Eskil. I'm happy to see it got fixed up quickly ;^> We presently have (only semi-formally) a process that requires API changes to be in by the FF deadline but provides for community (i.e. this list) approval of stragglers, when we are confident they are unlikely to harm stability or schedule. That seems workable. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
Hi, In practice we also do have some slack in the schedule exactly to allow sorting everything out. Unfortunately it is often not long enough, but we have delay in getting the alpha out. I do agree that we should include the features that are ready in time - and I do not think there are many who would disagree. One thing that tends to happen is the last minute pile up of commits at or near the FF time. While understandable, the more we can do to avoid this the more likely it is to have successful integrations. Especially with Qt 6 we need to make sure as many items as possible are not piling up just at the FF date. Maybe we should set a bit earlier FF date for the modules most others depend upon? Or other similar phasing instead of a day when everything needs to be in. Yours, Tuukka On 7.2.2020, 9.59, "Releasing on behalf of Eskil Abrahamsen Blomfeldt" wrote: On 05.02.2020 13:04, Jani Heikkinen wrote: > >> -Original Message- >> From: Eskil Abrahamsen Blomfeldt >> Sent: keskiviikko 5. helmikuuta 2020 13.06 >> To: Edward Welbourne ; Jani Heikkinen >> ; Lars Knoll ; Volker Hilsheimer >> >> Cc: Qt development mailing list ; >> releas...@qt-project.org >> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is >> in effect now >> >> >> On 05.02.2020 11:50, Edward Welbourne wrote: >>> Jani Heikkinen (5 February 2020 06:42) Why this is so important that we should get the exception & go in after >> FF? >>> Do we allow changes approved before feature freeze to get past the >>> Coin hurdle, even if that happens after FF ? How much fixing of the >>> change (if it turns out to have problems integrating) is acceptable, >>> before we declare that it's no longer the change that was approved in time >> ? >> >> >> If the change is ready and approved by the time of feature freeze and only >> delayed by CI problems, failures from other changes in a batch, or the >> awkwardness of our dependency structure, I think it has to be acceptable to >> merge after the freeze. Otherwise feature freeze becomes a lottery where >> the features in a given release is based mostly on chance. > By default we shouldn't put any new features in after FF, not even those which were approved early enough. Not respecting the freeze date was one of biggest reasons why we failed to keep the release schedule with earlier releases. And after we started to be much tighter with the freeze we have been much better to keep the schedules as well... Hi, You are looking at this from a very different perspective than me, which is totally understandable. As a developer of the product, I want a deadline for when I should have my feature finished. If the deadline is "maybe one month before the feature freeze, maybe one week, who knows it kind of depends on whether the CI system is acting up and what other changes your fix happens to be bundled with", then that makes it impossible to plan anything. If we estimate, based on statistics, that it will take one month to get features in, then we should set the feature freeze one month earlier. If we think it will take one week, then we should set it one week earlier. At least we should give people a specific date and guarantee that if they make it in time for this, their change will be in the next release. If this is one month before the actual feature freeze, then so be it. If it takes that long to get a change in, then definitely should be very visible to everyone, including the stake-holders who depend on features being released when we say. If it turns out that we miscalculated the estimate, then this should just cause a delay to the release. It shouldn't cause us to make a release containing a random set of features based on whoever won the lottery this time. I understand that your responsibility is making the release on time, and late submissions make this difficult, but the way to solve this is to add the extra slack between the feature freeze and the point where we can start stabilizing to the release schedule. If we see that changes that are staged at the freeze date consistently take between 1 day and 1 week to merge because we have broken systems or because so many people stage their changes at the same time, then that means we have to extend the period between freeze and release by one week. > We are doing time based releases so if new feature misses the deadline > there will be next one coming after few months. It might be quite long > time for unique feature but on the other hand it isn't really that > long... Our goal is to cut the schedule between FF and final release, > not reserving more time there. Ok,
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
I started to work on the error() signal renaming here:
https://codereview.qt-project.org/q/topic:%22error-occured%22
On Wed, Feb 5, 2020 at 10:12 PM Thiago Macieira
wrote:
>
> On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote:
> > On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira
> >
> > wrote:
> > > The correct signal for an error situation is errorOccurred, like in
> > > QLocalSocket and QProcess.
> >
> > Actually both QLocalSocket and QAbstractSocket renamed the "error()"
> > getter to keep using "error()" signal as opposed to many other Qt
> > modules "errorOccurred()" signals.
>
> Which is the opposite of QProcess and violates the naming convention. Signals
> are named after verbs in the past tense and properties & property getters are
> simple nouns. So "error" is the getter, "errorOccurred" is the signal.
>
> qprocess.h:
>
> #if QT_DEPRECATED_SINCE(5, 6)
> QT_DEPRECATED_X("Use QProcess::errorOccurred(QProcess::ProcessError)
> instead")
> void error(QProcess::ProcessError error);
> #endif
> void errorOccurred(QProcess::ProcessError error);
>
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel System Software Products
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On Wednesday, 5 February 2020 15:34:27 PST Alexander Akulich wrote: > Do we want to sort out all overloads of error() signal/getter in all > (essential?) modules for Qt 6? > > For example, Qt Multimedia still has more than a dozen public classes > with such overloads (of a signal and a getter) in 5.15 and dev. We wanted to do it for 5.6, so 6.0 seems like early enough, yes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
On 07/02/2020 03.14, Eike Ziller wrote: > QList is most definitely a typedef to QVector in Qt/dev: What happened to providing a container type with guaranteed indirect storage? There remains no such type in STL. Last I saw, I thought we were going to provide that... -- Matthew ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
On Thursday, 6 February 2020 05:51:17 PST Alex Blasche wrote: > Either option solves the ambiguity. What's more important to our users - a > consistent naming convention or an early warning/compile error when > adopting Qt 6? False dichotomy. Both are important and both are achievable. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Using SSE/NEON in Qt 6
On Thursday, 6 February 2020 03:45:51 PST Lars Knoll wrote: > Hi, > > We’ve seen that in a couple of places things like matrix operations are a > CPU bottleneck. Being able to provide SSE/NEON optimised versions of some > of those operations could help significantly. > On x86/x64, we require SSE2 already anyway, so we should be able to use > those unconditionally. On ARM, we can make this a compile time option with > a C implementation as the fallback. x86-64 instruction set mandates SSE2 and it's used anyway because it's the ABI way of doing floating point operations. So SSE2 should be no brainer on 64- bit. The question is what to do for 32-bit. I don't think it's very difficult, though: if we have the SSE2 code in the header, then it's checked by #ifdef __SSE2__ and there'll be a fallback path anyway. That fallback path will be the non- SSE2 i386 code path. Then there's the question of how to package this. I suggest that we enable SSE2 by default on the Windows 32-bit build, if we still have a 32-bit build. We don't ship 32-bit Mac or Linux builds. For Linux distributions, this is also already solved: build twice and place one lib in /usr/lib and the other in /usr/lib/sse2. GNU libc knows how to load this. > One problem is, that we can only get full benefit out of those if we can > offer them inline. That would basically imply making our qsimd_p.h header > public and including that one from qvectornd.h and qmatrixnxn.h (so that we > can implement the operations using the SSE/NEON intrinsics). If we do that, > we could e.g. implement QVector4D holding a __m128 value (and the neon > equivalent on ARM). We should simplify qsimd_p.h. There's some compatibility code there for GCC pre-4.9, which we don't support any more in 5.14. We need to decide whether we want runtime detection in inline headers. If we do, then we need an API for that and qCpuHasFeature hasn't maintained ABI. Moreover, we'll get requests for features that we don't currently need/use. If we don't need runtime detection, then just #include or a wrapper header to deal with MSVC not defining __SSE2__. qfloat16.h does that. We also need to decide whether we want the macro normalisation that qsimd_p.h does should be public too. qsimd_p.h defines the GCC/Clang macros that ICC and MSVC don't (__F16C__, __PCLMUL__, __FMA__, __LZCNT__, etc.). > I personally don’t think including qsimd.h (and implicitly immintrin.h) from > our public headers would be a problem, but I’d be happy to hear arguments > for/against it. immintrin.h shouldn't be. qsimd_p.h only after clean up and especially nailing the qCpuHasFeataure() API. > As a side note: SSE 4.1 offers some nice additional instructions that would > simplify some of the operations. Should we keep the minimum requirement for > SSE at version 2, or can we raise it to 4.1? I don't recommend it. The gain compared to SSE2 is not enough and it brings headaches. Instead, write code paths that use __AVX2__. Lots of modern CPUs support it and they can be co-installed with the main version on Linux (like Clear Linux does and I've done for my openSUSE package) and on Macs. It doesn't need to be #ifdef __AVX2__. Code should use the minimum feature that they support, like qhash.cpp and qstring.cpp do. That has the following benefits: 1) Mac 64-bit and Clear Linux have SSE4.2 as a baseline, so they'll be enabled even for the base versioni 2) People building from sources with -march=native (Gentoo users?) on older but pre-AVX2 machines will get benefit too 3) For matrix multiplication, I bet that __FMA__ is actually a much more important gain than anything else and it comes with the same architecture as __AVX2__. Use qCpuHasFeature(ArchHaswell) I recommend the 64-bit Linux and Mac binaries include AVX2 versions for the libraries that most benefit from it (QtCore, QtGui and Qt3D). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
