Alex Blasche wrote: > Fact is that Qt is huge and there are not enough work hours in a day to fix them all.
I'm a maintainer of a pretty large code base myself so I understand that completely. > (...) some bugs are simply too hard to fix (...) and (...) there are things which are too risky to fix because they have an extremely high potential to break other things. Granted, but those are not the things I'm talking about. The types of bugs I'm talking about are regressions, in some cases introduced by new functionality that is buggy itself. Fixing them shouldn't be any harder than introducing them. If all else fails - revert the new feature that caused the issues. It doesn't work correctly anyway and breaks existing apps. > As I said, I don't want to excuse just merely point out that it is not always as clear cut as you might think. We know our painful limits and we are extremely happy for every help we can get from the community. Alex, I'm not trying to pin blame on anyone. I understand the hardships all too well. I'm only interested in finding a solution. I would gladly help myself more but as I mentioned I already maintain a lot of code and I often can't afford to tackle another project. The regressions hurt even more because of that as I need to spend time to find horrible workarounds in my own code. I do plan to engage more though, as the number of regressions affecting me personally is reaching a tipping point. I just need to figure out the logistics. > Some domains are only maintained by the community and I am sure you can understand that nobody can or should ask them to work beyond their dedication either. Yes, and I wouldn't even start this topic if it was about those community driven modules. My complaint is mostly about the older parts, specifically widgets, which I consider core (as the location in the repo would suggest). > There are a few things where bug reporters can help too. Providing information when asked is extremely helpful. This might mean that reporter has to strip down their buggy app to a point that we can run it by ourselves or they even attempt to identify the problem in the code. That's why we have this additional state "Need more Info" in Jira. Sadly, there are over 2k bugs in the system where we asked for more feedback and have not received the required info within the last 6 months. This situation is so bad that we'll soon close those tasks as incomplete. Of course, the reporter can always reopen and provide more info in case the reporter or the assignee forgot about it. But in the greater context this is an expression of us trying to improve by focusing effort. I deal with bug reports all day long so I get that too. There's nothing more annoying than a report along the lines of "something is wrong, fix it" and then radio silence. I always try to provide as much info as I can and attach a simplistic repro code. > Looking from an individual reporters perspective, there are bound to be lucky and unlucky ones. I get that. Let me try to be more constructive then - looking at the proportion of the number of those long standing unresolved issues to the number of bullet points in the release notes by module I'd say a lot of those unlucky ones sit in the widgets area (e.g. 2 minor fixes in 5.11.2 is hardly an adequate pace). Maybe some resources could be shifted there? I know the focus is on the newer ui technologies (I don't want to start the flame on QML) and I know Qt Company maintains the position that widgets are still supported but, to me at least, the facts speak for themselves - widgets are really being penalized - either by lack of maintenance or regressions caused by advancements in those other areas. > P.S. On the positive side, in regular intervals we do a bugfixing week. During such a week the entire RnD org focuses only on bugs. I consider them a fairly successful exercise and as luck will have it, we have one next week 😉 That's great to hear. It's a good initiative, but I fear that due to the size of Qt that's simply not enough (as unsympathetic as it may sound, sorry). Also I obviously don't know that but I suspect the focus of these bugfixing weeks is on the new shiny stuff, not older tech like widgets, right? At least I don't see that in release notes volume. Qt is on a pretty steady schedule of releases now. I know this might sound radical but would it be possible to have lets say once in a year full minor (i.e. 5.x) release devoted solely to bug fixing and not (or sparingly) introducing new features? I understand features are the fuel of a project but it looks like each new feature drags a flush of regressions behind it that are rarely rectified. That's simply not sustainable. In Qt 4 I was always looking forward to new releases to discover new features. In Qt 5 it gradually shifted towards grumpily wondering what's gonna break this time. Qt won't stop growing and with its increasing size the amount of maintenance, especially on these older modules, needs to grow at least equally or we'll have a steaming pile in couple of years. You can't grow skyscrapers on rotting foundations. I don't mean to sound alarming, as the situation is not that grave yet, but the tendency does show.
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
