[Interest] What don't you like about Qt?

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

Your comments may be accurate but I'm not sure they have appeased many of the disgruntled customers.

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.

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.

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

> On 5 Oct. 2016, at 07:37, Thiago Macieira <thiago.macieira at intel.com> wrote:
> 
>> Em terça-feira, 4 de outubro de 2016, às 16:03:00 CEST, Jason H escreveu:
>> I think the bigger issue, that many people have expressed here, but not said
>> as such, is the Qt release cycle is not Agile. 
> 
> It's as fast as it can be. We can't release faster than it is because the 
> steps just take too long.
> 
>> what it's users want or need. Sometimes though, it's not even so much that
>> we need release, we just need a patch to hold us over to the next release.
> 
> All bug reports, when fixed, have a link to the actual change in codereview.qt-
> project.org, which contain the patch and the SHA-1 of the Git commit. So you 
> *do* have the patch.
> 
>> My Agile team does two week sprints so we can reorder priorities twice a
>> month. 
> 
> It takes us three weeks to create source and binary packages, then test them 
> for sanity, before we release.
> 
>> The Qt community has no say (AFAIK) in determining the priority
>> status, or what is worked on when. 
> 
> Priority is determined on facts, not on popularity. If you have more facts, 
> provide them. If you can show that a lot of applications are affected by the 
> bug, it gains in priority.
> 
> That said, the most common issue for bugs not getting fixed is that the 
> developers couldn't figure out how. Voting won't change that fact.
> 
>> I think the incorporation of a regular search of that nature would immensely
>> improve the product. I don't think there is any transparency in the
>> selected for fix criteria?
> 
> There isn't, because developer selects the bugs they're going to fix. There's 
> common procedure.
> 
> My procedure is: I'll fix everything that is assigned to me, the moment it's 
> assigned, if I can. If I couldn't within one day, I won't be able to until 
> there's more information posted.
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>  Software Architect - Intel Open Source Technology Center
> 
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest