[Qt-interest] (Qt support salesforce "downgrade", bug priorities) (was Qt for the iPad?)

[Thiago Macieira]

Em Quarta-feira 14 Abril 2010, às 10:04:48, Ross Bencina escreveu:
> >As for fixing bugs, that's about priorities: yours and ours will not
> >always match. The team has a lot to do and fixing the P0s and P1s as well
> >as getting
> >the releases out are very important. (Where P1 means "will stop the
> >release from happening" and P0 means "stops Qt development itself so stop
> >whatever you're doing and do this NOW")
> 
> While we're on the topic of bug classification... I would like to see any 
> cosmetic rendering bug which makes an app look broken (ie badly computed 
> update rects which break redraws) raised to P0. I have had support tell me 
> that rendering bugs will not be fixed in a minor update because they are
> not  "critical" enough. This is completely unacceptable. What commercial
> app would ship with a redraw bug -- like lines corrupting a widget due to
> un-updated regions when scrolling? Would you go out in public with a black
> line painted accross your face? In the past I've seen this in QTableView
> and currently I have a similar update issue in QGraphicsView  in 4.6.2
> (bug report on the way..)

This is exactly what I said about the definition of priorities not matching.

Your example is perfect: a rendering glitch is DEFINITELY not a P0. It may 
stop your shipping of your product, but that's a long way away from "Qt 
developers cannot do their work".

See http://qt.nokia.com/developer/task-tracker/qt-bug-tracker-getting-
started#8-how-we-prioritize-bugs

P0 means "work stops for engineers developing Qt itself until this bug is 
fixed". A rendering bug hardly qualifies as that. It's reserved for us only, for 
things like "doesn't compile on a Tier 1 platform", "binary compatibility 
issue", "autotest regression that stops the workflow".

P1 means "critical issue that must be fixed before the release" and is used for 
most regressions, crashes that are not edge cases, likely lockups, etc.

P2 means "important but won't stop the release" and might include the crashes 
and lockups that are unlikely.

Depending on the rendering glitch, it would be a P1 or a P2. If it is as you 
say "scrolling corrupts widget due to not updating" and we're talking about 
proper code that used to work, then it's a P1. If you're misusing the code, or 
if this has never worked, or is easily worked around, it's probably going to 
be a P2.

A crash that is very unlikely or an edge case, for example, will probably be a 
P3.

What I need you to understand is that P2 and P3 bugs are still important. We 
would very much like to fix them all. But while there are P0s and P1s 
remaining, we have to devote our attention to those. What's more, there's such 
a thing as "skills" and "knowledge": fixing a bug requires understanding the 
code in question and the bug report. There are only so many engineers with the 
skills in question and so many hours in a day.

Which brings me to the next point: the better the bug report is, the more 
likely it is to be fixed, even if it is a lower priority. If you include a 
testcase and a patch (and it is correct, of course), it will very likely be 
fixed. If you include a testcase, it's the next best thing and helps a lot.

If you report "widget fails to redraw properly when placed inside a 
QScrollArea and scrolling happens", without a testcase, description or even a 
screenshot, we're probably going to close your report with "Not Enough Info".

Please take a look at http://labs.trolltech.com/blogs/2010/03/02/how-to-file-a-
qt-bug-report-in-the-new-bug-tracker/ for info on a good bug report.

Finally, if you need an engineer to dedicate his/her attention to your issue, 
you have paid support and Premium Support (which is available as well for the 
LGPL version of Qt -- it's not tied to the commercial license). That's why 
these things are there for.

I have been involved in Premium Support cases where I had to meet face-to-face 
with the customer, so that we could debug their code together. They couldn't 
reproduce the problem in a testcase and they couldn't send us their codebase 
either. (Turns out the problem was that they were trying to connect SLOT to 
SLOT, i.e., a misspelt SIGNAL in the first argument)

In another case that comes to mind, we had a crash in QHttp that we couldn't 
reproduce, and this after QNetworkAccessManager already existed. Premium 
Support was activated and they gave me access to their proxy servers, so I 
could reproduce the issue and fix it. (In this particular case, the proxy was 
replying with Content-Length: 0)

Both of these cases would have been rejected as tasks in the bugtracker: the 
first would have been closed as Not Enough Info and the second as Cannot 
Reproduce.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100414/ee1e94e1/attachment.bin