[Interest] Priority of bugs

[Krzysztof Kawa]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20181001/30f65d35/attachment.html>