[Interest] What don't you like about Qt?
thiago.macieira at intel.com
Wed Oct 5 01:09:25 CEST 2016
Em quarta-feira, 5 de outubro de 2016, às 08:13:38 CEST, John C. Turnbull
> Thiago, with all due respect, and I'm very aware of the significant
> contribution you personally have made to both the Qt product and the
> community, there is clearly a high degree of dissatisfaction with various
> aspects of Qt and the management of the SDLC.
What's SDLC? Software Development Life Cycle?
The Qt Project actually has a very good cycle for an Open Source project. It's
certainly of much higher quality and stricter standards than 95%+ of other
open source software out there. I can tell you that we run more unit tests a
day than the Linux kernel does in a month (or maybe a year).
> Your comments may be accurate but I'm not sure they have appeased many of
> the disgruntled customers.
That may be, but facts and truth often don't serve to appease people. They're
more often than not a harsh reality.
I could have stayed silent, though, like I've done with the rest of this
> My advice (for what it's worth) would be to not ignore the swelling
> negativity that is building amongst paying customers and to see that there
> are some very genuine concerns out there that are making the task of
> putting food on the table more difficult than it need be for some people.
I'm not ignoring the negativity and I doubt anyone is. But people who complain
often have trouble putting their issues in the context of everything else that
is going on.
Also, I don't have any customers. I don't receive a penny, directly or
indirectly, of licensing fees or support contracts. Other people and other
companies involved may have a financial incentive. I don't. All I care are the
Open Source principles and the technical quality.
> It is troubling that you say that often developers simply don't *know* how
> to fix bugs. That does not engender a high degree of confidence in
> customers who have focused their entire business strategic plans on such a
Again, that may be, but what would you rather I said? That developers are
magic geniuses that can fix anything, with little information, in no time at
all and twice on Sundays? C'mon, we're all limited, no one is perfect.
But note I wasn't saying either that the developers are stupid. Far from it.
The most likely cause of not knowing how to fix is that the bug report is
incomplete or the issue is not reproducible. I had one recently that attached
a very nice testcase, with even a shell script that ran everything and set up
properly. And yet, after running for several hours, I couldn't reproduce the
I also have two pending patches to QtDBus that fix some regressions introduced
in 5.6.0 that I still haven't been able to get integrated because they trigger
another regression somewhere that doesn't happen for me. How can I fix that?
Sometimes we can reproduce the issue, but then we end up with a situation that
is so thorny that there is no good solution. Change something here and
everything unravels over there. Or the bug fix introduces regressions.
And then there are people depending on the buggy behaviour. Example: I noticed
that the QFile::created() function did not give you the file's creation time on
BSDs (including Apple OSes), but the file's ctime. The fix was simple. But if I
applied it the way I wanted, I would break people's applications that depended
on created() returning the ctime.
> Further, appearing to be somewhat dismissive of the constructive criticism
> regarding the absence of Agile methodologies within the Qt processes and
> basically saying "that's the way it is", again, may not be seen as helpful
> by some customers.
You can ask for transparency. You can ask for more attention to bug reports
with high priority. You can demand that all bug reports be triaged. I support
you on all of those.
But you can't tell us how to do our jobs. Agile doesn't work for us and I
don't know a single, large open source project with contributors from multiple
companies and across multiple geographies that uses Agile. Trust me when I say
that our methodology actually works: we fix hundreds of bugs per release, we
catch almost all serious regressions and yet we still have time for
> You know the old saying "If it ain't broke, don't fix it".
> Well, sadly, it *is* "broke".
> And even though I personally don't know how, its way past time to "fix it".
Give me an example of a comparable open source project and we'll emulate.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Interest