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

Thiago Macieira thiago.macieira at intel.com
Tue Oct 4 22:37:20 CEST 2016


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




More information about the Interest mailing list