[Development] [QtMultimedia] Still is supported, active?

Mitch Curtis mitch.curtis at qt.io
Thu Jul 21 13:54:15 CEST 2016

> -----Original Message-----
> From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-
> project.org] On Behalf Of Prav
> Sent: Thursday, 21 July 2016 1:32 PM
> To: development at qt-project.org
> Subject: Re: [Development] [QtMultimedia] Still is supported, active?
> Hello, Everyone.
> > If you want this bug fixed, or to improve the QtMM quality there are far
> better ways:
> > - Get a Qt support license from the Qt Company and raise the issue to
> > them. They very often help raising important customer issues like this
> > one to P1 since in the end, it's that money that pays Qt Company
> developers.
> > - Try to fix the issue yourself. You already did more than many users
> > by bisecting the issue, thanks for that. But if this issue is really a
> > showstopper like you say, it can't be that Yoan is the only person in
> > the world that can and would be willing to fix it.
> > - Hire somebody to fix the bug. We at Woboq can help fixing nasty
> > issues like those in a very reasonable timeframe, KDAB does so as well.
> Here is also one important detail. If Denis need to decide to hire someone
> he need information about plans of fixing the bug.
> If he need to wait 1/2 year to get estimation that this bug is not going
> to be fixed in nearest months this can make him piss off. Easy imaginable!
> If "Fix Version" is filled by Yoann Lopes 6 months ago then he will get
> this estimation and can decide to hire Woboq or someone else to fix or
> whatever.

This is an unreasonable expectation to place on developers. For blockers (which, as far as I understand, this was not), yes, the fix version is most likely going to be known, but for many bugs, it's extremely difficult to know when they will be fixed. Things happen, priorities change. Also, there are always lots of bugs waiting to be fixed. It's a huge product.

The more reasonable approach to this is to contact the maintainer or the current assignee and let them know that you're planning on working on it, to avoid stepping on each other's toes.

But then again.. we both know that anyone who is *serious* about getting something fixed would have taken this approach, right? :) Only those who complain (regardless of the facts and realities presented to them) while making no attempts to come forward with a solution would consider this an effective use of their time.

> Currently he is in "floating"/unstable/non-informative situation. So less
> reasons to act smart and more food for emotional letters.
> If this situation looks fine for maintainers then there is no sense in
> shutting up Denis. What to expect? People cry/insult if it hurts and no
> one listen. So predictable!
> Maintainers need to think about bug-reporters ALSO ... and keep bug-
> reporters in stable state.
> Imagine if for this bug "Fix Version" was filled with "Qt 6.0" then Denis
> Shienkov will get estimation of what waits him. And he can act.
> If for some reasons this estimation will be changed by maintainer to let's
> say 6.5 (or 5.10) then bug-reporter will send email notification to Denis
> about change of attitude to the bug he care about. Easy!
> So IMHO here we have violation of Best Practices of bug-tracking from
> maintainer and emotional angry-letter as the result of 1/2 year influence
> of this violation on bug-reporter. Simple!
> That is why I propose to create query in bug-tracker which will show up
> such violations.
> This is not about fixing bugs ... this is about respecting from
> maintainer's side the bug-tracker fields which need to be filled and which
> influences bug-reporters.
> Just fill 3 fields.
> Done!
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

More information about the Development mailing list