[Interest] Priority of bugs

[Krzysztof Kawa]

Hi,
I really hate to be "that guy" again, but I'd just like to know what's going on.

Some time ago I complained about bugs not being resolved for many
major releases. I was then told my reports were P2 or lower and I
can't expect them to be taken care of. That sucks for me but I can
understand to some degree.
But now a new release is out and I still have three P1:Critical
issues, reported 3 or 4 releases ago, all being regressions btw, and
nothing is fixed. There's a next major release around the corner and
it doesn't seem to fix these either.

Are only P0 reports looked at? Why do we even have other categories if
they are all treated the same way?

It feels like more and more features I don't need are being added and
more and more features I've been using for years are randomly broken
in new releases and never fixed back while hanging in jira limbo.

Wouldn't it be a good idea to have a clear policy like certain P level
is fixed or at least a workaround proposed in the span of X releases
at which point they become a block or are dropped entirely? And
shouldn't regressions be treated more seriously? If a new feature has
a bug I just don't start to use it, no problem, but if something
breaks after update I'd like to at least know I can skip a release and
wait for a fix. Now I don't know if it ever gets fixed again.

[Konstantin Tokarev]

20.09.2018, 15:59, "Krzysztof Kawa" <***@gmail.com>:
> Hi,
> I really hate to be "that guy" again, but I'd just like to know what's going on.
>
> Some time ago I complained about bugs not being resolved for many
> major releases. I was then told my reports were P2 or lower and I
> can't expect them to be taken care of. That sucks for me but I can
> understand to some degree.
> But now a new release is out and I still have three P1:Critical
> issues, reported 3 or 4 releases ago, all being regressions btw, and
> nothing is fixed. There's a next major release around the corner and
> it doesn't seem to fix these either.
>
> Are only P0 reports looked at?

Only P0 bugs block releases, others don't have predicatable schedule.

You may get fixes faster if
* you contact maintainers of respective code and provide additional
information such as debugging details
* you convince people that priority should be promoted to P0
* you contribute fixes yourself

> Why do we even have other categories if
> they are all treated the same way?

To sort issues by priority in JIRA queries, of course :)

>
> It feels like more and more features I don't need are being added and
> more and more features I've been using for years are randomly broken
> in new releases and never fixed back while hanging in jira limbo.
>
> Wouldn't it be a good idea to have a clear policy like certain P level
> is fixed or at least a workaround proposed in the span of X releases
> at which point they become a block or are dropped entirely? And
> shouldn't regressions be treated more seriously? If a new feature has
> a bug I just don't start to use it, no problem, but if something
> breaks after update I'd like to at least know I can skip a release and
> wait for a fix. Now I don't know if it ever gets fixed again.
> _______________________________________________
> Interest mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

--
Regards,
Konstantin

[Thiago Macieira]

On Thursday, 20 September 2018 08:20:23 PDT Konstantin Tokarev wrote:
> 20.09.2018, 15:59, "Krzysztof Kawa" <***@gmail.com>:
> > Hi,
> > I really hate to be "that guy" again, but I'd just like to know what's
> > going on.
> >
> > Some time ago I complained about bugs not being resolved for many
> > major releases. I was then told my reports were P2 or lower and I
> > can't expect them to be taken care of. That sucks for me but I can
> > understand to some degree.
> > But now a new release is out and I still have three P1:Critical
> > issues, reported 3 or 4 releases ago, all being regressions btw, and
> > nothing is fixed. There's a next major release around the corner and
> > it doesn't seem to fix these either.
> >
> > Are only P0 reports looked at?
>
> Only P0 bugs block releases, others don't have predicatable schedule.

No. P0 means "stop whatever you're doing and fix this now". It doesn't block a
release, it block any further work.

P1 blocks a release.

Or at least it should. Sometimes a bug is mis-prioritised. More often, we
override at release time saying "it's better to release this now than to wait
longer until everything is fixed".

>
> You may get fixes faster if
> * you contact maintainers of respective code and provide additional
> information such as debugging details
> * you convince people that priority should be promoted to P0

You're not going to promote to P0 unless you're a developing Qt itself. If
you're not following the Git repository, then new issues cannot block your
work by definition.

> * you contribute fixes yourself
>
> > Why do we even have other categories if
> > they are all treated the same way?
>
> To sort issues by priority in JIRA queries, of course :)
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Alex Blasche]

________________________________________
From: Interest <interest-bounces+alexander.blasche=***@qt-project.org> on behalf of Thiago Macieira <***@intel.com>

On Thursday, 20 September 2018 08:20:23 PDT Konstantin Tokarev wrote:
> 20.09.2018, 15:59, "Krzysztof Kawa" <***@gmail.com>:
> > Hi,

> > Are only P0 reports looked at?
>P1 blocks a release.

>Or at least it should. Sometimes a bug is mis-prioritised. More often, we
>override at release time saying "it's better to release this now than to wait
>longer until everything is fixed".


As a more elaborate explanation I recommend reading

https://codereview.qt-project.org/#/c/225694/16/jira-update.txt

In particular I'd like to point out section 3.2 and 3.3. P1 blocks a release if the FixVersion tag is set.
Since Qt uses time boxed releasing, there are bound to be bugs we cannot address as Thiago mentioned.

--
Alex

[Christoph Feck]

On 20.09.2018 14:59, Krzysztof Kawa wrote:
> [...] If a new feature has
> a bug I just don't start to use it, no problem, but if something
> breaks after update I'd like to at least know I can skip a release and
> wait for a fix.

While this makes sense, in practice most bug fixing is spent to make the
new features actually work. There is no point in adding features, if
they are not useable because of bugs.

Since time and developer resources are limited, even that goal is hardly
reached, so it seems natural that fixes for other issues need additional
help and/or additional time.

Also note that everyone has their own favorite bugs. For example, I am
still using Qt 4 for one of my applications because of QTBUG-57485, but
hey, Qt 4 still works :)

--
Christoph Feck
KDE Bug Triaging Team

[Krzysztof Kawa]

Christoph Feck wrote:
> in practice most bug fixing is spent to make the
> new features actually work. There is no point in adding features, if
> they are not useable because of bugs.

Funny you should say that. I actually wish this was true, but take a
look at the sad history of QTBUG-52108 for an example of how it really
is. A new feature came out in 5.6 in a state that made it unusable
from the start and it also broke some previous stuff on the way. With
new releases it deteriorated further and now there's an unusable
feature and no fixes for either the regressions or the new bugs. At
this point I don't expect it to ever get fixed as it's "just" P2. This
seems to be the norm for the last few releases - one step forward two
steps back.

> Also note that everyone has their own favorite bugs

Sure, but there are bugs and then there are bugs. I totally get that
some missing links in the doc (QTBUG-69484) are just tiny
inconvenience and not a big deal to overwhelming most, but something
like basic mouse events not working correctly (QTBUG-68221) or crashes
and memory leaks on something as fundamental as docking a window in a
window framework kinda is a big deal to me.

Anyway, I really don't want to stretch this rant. I'm just bummed
about the degrading quality of my favorite framework and I hoped I'm
not the only one that noticed. But maybe I am.

[Tomasz Olszak]

Hi Krzysztof,

I would suggest to contact maintainer on IRC and ask if there is something
you can help with.

E.g I encountered QTBUG-70222, contacted Alex and in 20 minutes he guided
me how to provide data he needs to narrow down and fix the issue.

For some other bugs/features it was easier to just fix/impement them myself
instead of waiting for other people.

If you have reproducible crash in docked window I can imagine that it
should be easy to fix. Qt is well written and you don't need to be very
experienced to fix a bug here and there.



20 wrz 2018 20:04 "Krzysztof Kawa" <***@gmail.com> napisał(a):

Christoph Feck wrote:
> in practice most bug fixing is spent to make the
> new features actually work. There is no point in adding features, if
> they are not useable because of bugs.

Funny you should say that. I actually wish this was true, but take a
look at the sad history of QTBUG-52108 for an example of how it really
is. A new feature came out in 5.6 in a state that made it unusable
from the start and it also broke some previous stuff on the way. With
new releases it deteriorated further and now there's an unusable
feature and no fixes for either the regressions or the new bugs. At
this point I don't expect it to ever get fixed as it's "just" P2. This
seems to be the norm for the last few releases - one step forward two
steps back.


> Also note that everyone has their own favorite bugs

Sure, but there are bugs and then there are bugs. I totally get that
some missing links in the doc (QTBUG-69484) are just tiny
inconvenience and not a big deal to overwhelming most, but something
like basic mouse events not working correctly (QTBUG-68221) or crashes
and memory leaks on something as fundamental as docking a window in a
window framework kinda is a big deal to me.

Anyway, I really don't want to stretch this rant. I'm just bummed
about the degrading quality of my favorite framework and I hoped I'm
not the only one that noticed. But maybe I am.

[Nyall Dawson]

On Fri, 21 Sep 2018 at 04:04, Krzysztof Kawa <***@gmail.com> wrote:
>
> Christoph Feck wrote:
> > in practice most bug fixing is spent to make the
> > new features actually work. There is no point in adding features, if
> > they are not useable because of bugs.
>
> Funny you should say that. I actually wish this was true, but take a
> look at the sad history of QTBUG-52108 for an example of how it really
> is. A new feature came out in 5.6 in a state that made it unusable
> from the start and it also broke some previous stuff on the way.

FWIW, I've also encountered some serious issues with this
functionality under gnome, where floating docks will get stacked under
main windows if they were previously tabbed and restoreState is
called. The only "fix" is to disable this feature by not setting
QMainWindow::GroupedDragging.

Nyall

[Shawn Rutledge]

> On 21 Sep 2018, at 01:07, Nyall Dawson <***@gmail.com> wrote:
>
> FWIW, I've also encountered some serious issues with this
> functionality under gnome, where floating docks will get stacked under
> main windows if they were previously tabbed and restoreState is
> called. The only "fix" is to disable this feature by not setting
> QMainWindow::GroupedDragging.

I noticed in Creator that if I have a file dialog open, it’s possible to put the main window on top of the dialog. Sounds like maybe it’s related...

[Alex Blasche]

> -----Original Message-----
> From: Interest <interest-bounces+alexander.blasche=***@qt-project.org> On
> Behalf Of Krzysztof Kawa
...
> Anyway, I really don't want to stretch this rant. I'm just bummed about the
> degrading quality of my favorite framework and I hoped I'm not the only one
> that noticed. But maybe I am.

I won't justify why a particular bug has or has not been fixed. That's futile and leads nowhere. Fact is that
Qt is huge and there are not enough work hours in a day to fix them all. Add natural fluctuation of maintainerships (and its implied competency loss), the fact that some bugs are simply too hard to fix (as they require complete rewrite of subsystems or even Qt6) and last but not least there are things which are too risky to fix because they have an extremely high potential to break other things - well, you can get an idea how hard the problem is. Darwinism works for bugs too....

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. 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.

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.

In summary, I absolutely understand your frustration and it pains me too. Looking from an individual reporters perspective, there are bound to be lucky and unlucky ones. As we focus on bugs in the greater scheme of all of Qt I would hope that the lucky ones have a majority. I hope I could shed some light on it from the other side of the fence and create some understanding of the enormity of the task you are asking for.

--
Alex

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 😉

[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.

[Tuukka Turunen]

Hi,

Just to note that more than “two minor fixes” were done related to widgets in Qt 5.11.2 of the total 262 fixes: https://bugreports.qt.io/issues/?filter=19635

Widgets is an important area and we are actively maintaining those. There is less new development than on some other areas, but Widgets are not forgotten.

This is just to point out that situation is not as bad as you said. There is always possibility to do more and there are certainly many bugs still to fix in Widgets area.

Yours,

Tuukka

From: Interest <interest-bounces+tuukka.turunen=***@qt-project.org> on behalf of Krzysztof Kawa <***@gmail.com>
Date: Monday, 1 October 2018 at 16.30
To: "***@qt-project.org" <***@qt-project.org>
Subject: Re: [Interest] Priority of bugs

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).

[Krzysztof Kawa]

Tuukka Turunen wrote:
> Just to note that more than “two minor fixes” were done related to widgets in Qt 5.11.2

Sorry, my bad. I was (wrongly) basing that statement on the contents
of the changelist:
http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.11.2

If you filter that Jira link to widgets only its around 20, not 2, so
I clearly overstated.
Still, I stand by everything else I said.

[Alex Blasche]

________________________________________
From: Krzysztof Kawa <***@gmail.com>

>> 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?

I wanted round this discussion up by stating the outcome of last week (Tuukka's link was based in previous time span, aka 5.11.2):

https://bugreports.qt.io/issues/?filter=20014

There might be some bugs in the list which were fixed by people from outside of Qt RnD but I can count over 100 bugs being squashed and the set includes 15 widget related bugs.

There are a few fixes still sitting on codereview which have not merged yet and hence are not resolved yet.

--
Alex