Qt Developers Discuss What To Do With All Their "P1" Priority Bugs

[ssokolow]

If bugs are open for a long time they should be automatically closed after new versions come out UNLESS they are still a bug.

When you say automatically, I think "This is the NPM/Webpack-era version of http://www.jwz.org/doc/cadt.html"

[franglais125]

When P1s pile up, you either don't have enough capacity or you lack proper management.
Changing the rules so the numbers look pretty is never the solution.

The solution is clearly to reduce the number of tests: it makes us look bad!
As an angry, childish orange man would put it.

(jk)

[C8292]

When you say automatically, I think "This is the NPM/Webpack-era version of http://www.jwz.org/doc/cadt.html"

LOL yes.
ahaha

[tildearrow]

Fix them. Come on, we need a proper release.
Many big companies use Qt for their products, and you don't want to screw them up.

[Slartifartblast]

Qt or not Qt, that is the question, Whether 'tis nobler in the mind to suffer the slings and arrows of outrageous GTK.

[_ONH_]

This is commercial software. So it will ship as soon as possible. Can’t miss out on revenue.

I always have stroke the mechanical engineer’s nose into his failures while working as a mechanic. If a solution was not found for the next release. The Next step go to his boss complain about the issue and tell them how much of my time the workaround costs me, and the customer to maintain the machine. mosten times they overpaid the parts supplier or overpaid the engineer. Because it is his job to or to get qa his work before it goes into production, if there is a week needed to fix it then the production of parts get postponed a week. Then they make the issue not appearing systematically in every new product. Since then the assembly process has shortened one week, because the products are engineered better and supplier pay for are deducted for defective parts. And moste machines get delivered with less than 1 week delay, instead the usual 4-6 week prior.

One just had to kick the bwl guy, to understand he loses money while just doing qa with the finished product, instead of doing in in ever single step..

i don’t know way this commercial qt don’t get this in order.
Halve the answers on the mailing list are are really joke, originating form people not savvy in Qa or thinking not caused by me so it’s not my problem.

There is clearly a fundamental problem with the release Manager not caring about a at all, moste likely for the last 3 to 5 years.

instead of releasing qt6.0 they certainly should Tahoe 1or2q to fix their qa issue.

[carewolf]

If bugs are open for a long time they should be automatically closed after new versions come out UNLESS they are still a bug.

Many of them are against unmaintained modules such as QtQuick1, QtScript or QtWebKit. The Qt company closing them because they no longer maintain those modules might not be received well by the open source project sometimes still trying to keep these projects alive.

[lowflyer]

Sure, throw the baby out with the water

The company I'm working for is just about to throw that baby out, including the bathwater. I was the guy that introduced Qt to our company about 12 years ago. These days we are about to replace it with something else because of the constant issues we have with it. Granted, the times were not easy for what is now called "the Qt company". But instead of improving their core product we saw them literally dancing with every new fad in the industry: Automotive, Animation, Web etc. Instead of providing a solid build system they invented three "own solutions" until the finally admitted that they were unable to do it right and now grudgingly start to support CMake. QtQuick (as it is called today) is a similar issue.
All of that is just about the code base. Not talking about the support (yes we had paid support) or the licensing issues.

[brent]

Oh yeah, Qt Quick / QML, "the future" of Qt... except its not. It's supposed to make everything easier, but you quickly end up wrestling with C++, QML and JavaScript at the same time, and then everything becomes more cumbersome, complicated and harder. JavaScript in particular feels like an alien as part of the package. You can't use the regular JavaScript ecosystem tools, like npm. And of course, writing the code to make interoperation between C++ and JavaScript happen is a lot of work.

[kpedersen]

Oh yeah, Qt Quick / QML, "the future" of Qt... except its not. It's supposed to make everything easier, but you quickly end up wrestling with C++, QML and JavaScript at the same time

Yep. It pretty much turns your whole project into a binding creation exercise. Good luck maintaining that shite in a few years.

The problem is there are too many non-technical developers out there who "fear" C++ and do really stupid things just to avoid it.