Em quarta-feira, 5 de outubro de 2016, às 08:13:38 CEST, John C. Turnbull escreveu: > 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 thread. > 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 > product. 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 issue. 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 innovation. > 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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest