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@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest