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

[jKicker]

Is it time to fork Qt? Kt?

What...? Fork to get the same bugs with less manpower? You can always do (local) fork, fix the bug and contribute back

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.

Spot on.

[Guest]

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.

Well you see almost all commercial software is managed like this. Write crap software, and hire and promote people based on whether they'll have a beer with you or some stupid shit.

"It's ok if we write crap software, we can always push a new update to fix it."

"It's ok to write bad code, QA will catch any bugs, because they'll always be consistently reproducible."

"It's ok if we write bad multi-threaded code with race conditions, we can consistently reproduce such bugs and if we show that a bug doesn't happen after one test on one device, then there's no problem."

"There's no point in writing good code, because we're moving so fast, it will be overwritten by new code anyway/we'll throw out that feature in a couple of minutes" - code ends up being used for decades and runs cities and banking systems.

"Why didn't you write production quality code during that hackathon where I chose what you would work on, and I didn't tell you I wanted the feature to actually be in production"

This is the kind of stupid shit that many managers, product managers and developers think. They're all idiots who can't do their job right, but are promoted because they can butter up management.

[Guest]

I just remember one of the latest episodes of a famous Linux show (maybe the one with Noah.. I forgot the title) they were all frothing about KDE latest release, KDE here KDE there.. like totally fan boys, everybody was raving about it. I found it so childish. I guess Gnome supporters must be doing the same, I just found it ridiculous consider ridiculous being a very popular show to polarize listeners like that, especially considering the little imperfections they were mentioning while lauding it (settings thrown everywhere for example). I just found it incredibly ugly looking desktop that reminds of my dark ages using Windows
But I confess that I'll might give it a try if they find a way to simplify settings or hiding advanced ones somewhere. Life is chaos already, I don't need that in a GUI!

I like the KDE options, I want configurability. It should be better organized I agree, I remember when there were 3 different places for power management settings (maybe there still are?).

[Guest]

Better known as the "Red Hat bug management policy".
Yes, it's a dishonest way to handle bugs, but suggesting that KDE is the only project to suffer from it is unfortunately very optimistic: GNOME practically invented the concept.

It's not exclusive to Redhat or open source. This is also the rule in the entire software industry (or to be more general, anything humans do). Very few things are actually properly done.

[Guest]

It isn't about solving issues in that sense, it's about getting rid of bugs that were false positives, weird distribution configuration related, dependencey related, etc. Drop everything, see what people actually start reporting, and go from there.

The bugs will just snowball again, because the development model is broken. This is like the Reapers coming in every now and then to kill everyone in Mass Effect.

[lowflyer]

What are you changing to?

That's not decided yet. We're still collecting contenders. We've already worked with Qt for 12 years, so we are not in a hurry to change. In the meantime we accumulated quite a bit of direct graphics programming, so we could potentially end up with a homegrown solution.

Copperspice and WX are currently on the list. We're even looking at ImGUI. Any possible fork of Qt can expect some attention from our side.

[lowflyer]

Well, you, as the end user, are entitled to use whatever toolkit works for you.
I was just saying, just because someone mismanaged the backlog is no grounds for a company that lives for one product to close up shop.

Fwiw, I had the same feeling that they're branching out too fast, but, unlike you, I have never programmed for/using Qt. I see I was not wrong. Also fwiw, companies have a duty to explore new things, lest they end like Microsoft scoffing at mobile two decades ago. They still need to get their priorities straight and allocate resources accordingly, tho.

I'm totally with you. I've worked in the past with all "classical" gui toolkits (Microsoft, WX, GTK, TK ...) and I can safely say the Qt is quite a solid compared to those. Especially with a C++ mindset. You're also correct that every company should do research and development. But not to the point of neglecting their core product in order to run behind every new fad. Qt has served us well in the past and it makes it quite demanding for an alternative. I would rather like to use Qt "because we like it" and not just "because the alternatives are not as good" - but that's the point where we are at the moment.

I still hope that they will "turn the ship around" but once we've jumped, we will not likely turn back.

[f0rmat]

Well you see almost all commercial software is managed like this. Write crap software, and hire and promote people based on whether they'll have a beer with you or some stupid shit.

"It's ok if we write crap software, we can always push a new update to fix it."

"It's ok to write bad code, QA will catch any bugs, because they'll always be consistently reproducible."

"It's ok if we write bad multi-threaded code with race conditions, we can consistently reproduce such bugs and if we show that a bug doesn't happen after one test on one device, then there's no problem."

"There's no point in writing good code, because we're moving so fast, it will be overwritten by new code anyway/we'll throw out that feature in a couple of minutes" - code ends up being used for decades and runs cities and banking systems.

"Why didn't you write production quality code during that hackathon where I chose what you would work on, and I didn't tell you I wanted the feature to actually be in production"

This is the kind of stupid shit that many managers, product managers and developers think. They're all idiots who can't do their job right, but are promoted because they can butter up management.

I believe that the process you described above is referred to as "Agile Development."

[_ONH_]

I believe that the process you described above is referred to as "Agile Development."

So agile doesn’t require qa?

Apparently that unattended bugs tracker defies the agile Manifest point 3, 5, 7, 8, 9, 12 which imply QA is dropped from the Projektmanager to every participant, without taking from pm the responsibility to be assured QA has happened.
10 implies QA, if one factors in full lifetime cost, which is problematic if support and maintenance is split into a separate entity or contracts.

So, if you tell this is agile, you might have passed a test to be able to reciting the concept, without having understood anything. It might apply to how it is implemented in many entities, I wouldn’t be surprised.

In my graduation year 8 out of 10 didn’t understand a dime of pm after graduating. Now the company they work for struggle to find consumers to pay the price premium needed to pay the high wages for the higher educated in our country, so they cutting the worker of their fair share for the manual and dirty work.
This because the quality the product have can be done in low wage countries at a fraction of the cost, if one supplies them with a good pm to lead the project in an old fashioned way.

[f0rmat]

So agile doesn’t require qa?

Apparently that unattended bugs tracker defies the agile Manifest point 3, 5, 7, 8, 9, 12 which imply QA is dropped from the Projektmanager to every participant, without taking from pm the responsibility to be assured QA has happened.
10 implies QA, if one factors in full lifetime cost, which is problematic if support and maintenance is split into a separate entity or contracts.

So, if you tell this is agile, you might have passed a test to be able to reciting the concept, without having understood anything. It might apply to how it is implemented in many entities, I wouldn’t be surprised.

It was a joke. Of course any type of any development or any project at all requires QA/QC. My comment was only directed at the fact that so many things that I see (and I am not a developer) are so focused on "speed" and "agility" that they lose focus on "quality" "usability" "assessment" and "verification." And you are right, I have come across many who can recite the theory of something, but do not understand nor can they put it into practice.

And for the record, I am not a PMP, but I have managed many large scale projects.