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

[Thiago Macieira]

On quinta-feira, 21 de julho de 2016 17:05:42 PDT Prav wrote:
> But this field is CHANGEBLE! So Fix Version SHOULD NOT BE KNOWN. It is how
> maintainer see planning of it currently.

That is not how we use the bug tracker, as I've explained. The rest of your 
email is not relevant.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On quinta-feira, 21 de julho de 2016 10:20:59 PDT Prav wrote:
> Hello, Everyone.
> 
> > Bugs are fixed when they are fixed. You won't get any estimate before the
> > developer actually starts fixing the issue. And even then, it may take
> > months or more until it actually gets fixed.
> 
> Agree but devil is in details. Currently there is a practice to not fill-out
> necessary fields for the bugs and not to change its status. I exactly mean
> * Not changing from Reported to Opened (or Need Info or Closed) ... like it
> is with discussed QTBUG-53019 (1/2 year old) 

Bugs should be triaged, which means they should go to Opened, Need Info or 
Closed in a timely basis. This is a mistake and should be corrected.

> * Not assigning responsible person in Assignee field like it is for ex. with 
> QTBUG-46812 (1 year old) 

Assignee is only important when the bug is being worked on. If no one is 
working on it, Unassigned is fine.

> * Not assigning Fix Version/s ... which can mean there is no plans for the
> bug. No plans can be because of 3 reasons:
> I do not care and going to silently ignore the bug
>   OR
> I agree with the bug but have so many bugs to fix already so that
> this is to far from my 1 month plan (or 3 month plan or 1 year plan ...
> nobody knows what plan is meant) OR
> I except the bug but do not want to bother myself with filling this
> field about my plans

Or, the actual case, which is neither: "Fix version" is assigned when the fix 
is committed to that particular version and the issue moves to Closed. "Fix 
version" is not used for wishes, but for actual fact.

> This is probably means that we need some easy to use query in bug-tracker
> system which can show up "unprocessed bugs" ... which is bugs with state
> Reported
> OR
>   no Assignee
> OR
>   no Fix version
> With sorting from oldest creation date to newest.

Just the first counts as "untriaged".

> If Yoann Lopes will fill the bugs fields why in the world would Denis
> Shienkov ever wrote this letter. Never. Because attitude to the bug will be
> clear to him.

Or, like I've just proven, people can misunderstand intentions and might still 
have complained. If the bug had been accepted (status Opened) but no work done 
in one year, I can bet there would still be complaining now.

> And Denis can only live with this (like trying to fix himself, or hire
> someone or stick to Qt 5.5.1 forever or whatever else)

This option is open to you right now. Why are we spending time discussing the 
issue report attributes instead of fixing the issue?

> I IMHO see Denis Shienkov's personal attacks to Yoann Lopes quite reasonable

Personal attacks ARE NEVER REASONABLE.

I'm going to repeat myself: PERSONAL ATTACKS ARE COMPLETELY UNACCEPTABLE.

You can and should frankly discuss technical issues. You can argue why a 
commit should be different, why a bug deserves a different priority and you 
can argue that someone should dedicate more time to a given task.

However, I don't care how much you may hate someone for any perceived or real 
insult, work or lack of work. YOU NEVER ATTACK PERSONALLY. That's entirely 
unacceptable under the Qt Project governance rules and any governance rules of 
any project I participate in and especially helped create. I only know of one 
notable exception that permits personal attacks and almost everyone I know 
(except the involved ones) think it's a bad idea to permit it.

> And I totally agree that "Bugs are fixed when they are fixed". And agree
> that maintainers need to respect Best Practices of working with
> bug-tracking ALSO (which exactly mean filling out ALL these 3 fields ...
> they ALL are important).

Except that our practice is not to set those fields. The only field that could 
have been set in this particular case is the Status: the bug should have been 
triaged and then transitioned from Reported to Opened.

> Can Qt Product Managers arise the importance of Best Practices of working
> with bugs-tracker for developers?

We already have. I remember discussing this in one of the Contributor Summits. 
It should be in the wiki somewhere.

> Can someone create this query inside bug-tracker system and share it with
> everyone so that unprocessed bugs can be shown?

Everyone can. It's easy with JIRA. Takes a couple of clicks to find all bugs 
that are in Reported state and needs to be triaged. Takes a couple of other 
clicks to find all Open bugs (verified to be issues) and thus any developer can 
take ownership of and start working.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Robin Burchell]

On Thu, Jul 21, 2016, at 04:05 PM, Prav wrote:
> Agree with you if this field was unchangeable once it was set (nobody
> knows the future exactly ... ).
> But this field is CHANGEBLE! So Fix Version SHOULD NOT BE KNOWN. It is
> how maintainer see planning of it currently.

Looking at my current world of choice: QtQuick (not QML, & not Controls)
currently has - roughly - 385 open bugs. Three maintainers (Shawn &
myself for QtQuick, Gunnar for scenegraph parts) - one of which works on
Qt full time - plus a number of assorted contributors (in and outside
the Qt Company) who all have their own priorities, wants, needs, and
desires.

The very nature of an open source project is that the resources that it
has are unreliable. Outside of the core of people paid to work on it,
there is no predictability about how much effort people are able to put
in, let alone the completely unpredictable nature of software estimates,
which is a widely known problem: I expect you've heard of it before so I
won't go into it. And of the core of people paid to work on it, they
have their priorities set based on a number of different variables:
things they want to work on, things they are paid to work on, feature
work vs bugs (and then: paid customers vs not, etc).

On top of that, many bugs can't be estimated just by looking at the
report. It requires knowledge of the code to find a fix, to understand
possible implications and side-effects, testing, etc. I'm the first
person to tell you that I don't have a clue how long a number of the
bugs filed on QtQuick will take to fix right now, simply because I don't
have an immediate understanding of what the problem actually is.

I've rambled a bit here, but the point that I'm trying to make is: even
if I *wanted* to, I couldn't try plan all 385 of those into something
sensible, even if I was willing to spend all of the time that I spend
looking at code/bugs/reviews on the meta-work that you're proposing
(planning with all of those people) here. And that's just for one small
part of Qt.

Long story short, I don't see that happening. I don't think it's
actually written down or formalised anywhere, but AFAIK, fix version
tends to only be set on bugs that are actually fixed, to indicate which
version the fix is going to land in, or on high priority blockers.

-- 
  Robin Burchell
  ro...@viroteck.net
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Mitch Curtis]

> -Original Message-
> From: Development [mailto:development-bounces+mitch.curtis=qt.io@qt-
> project.org] On Behalf Of Prav
> Sent: Thursday, 21 July 2016 4:06 PM
> To: development@qt-project.org
> Subject: Re: [Development] [QtMultimedia] Still is supported, active?
> 
> Hello, Everyone.
> 
> >> 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.
> 
> Agree with you if this field was unchangeable once it was set (nobody
> knows the future exactly ... ).
> But this field is CHANGEBLE! So Fix Version SHOULD NOT BE KNOWN. It is how
> maintainer see planning of it currently.

It sure is changeable, and we do change it... when:

1) It's a blocker and it has to be fixed by a certain version.
2) The bug is fixed.

Read this thread:

http://lists.qt-project.org/pipermail/development/2015-November/023847.html

The conclusion from the chief maintainer was:

> I think this makes most sense. The old way where we had a Fix Version set for 
> open bugs is at the minimum confusing to users. Usually it's worse, because 
> it creates false expectations. Setting a Fix Version on an open bug is 
> somewhat of a commitment by us that we will do what we can to get that bug 
> fixed for this version. And that's more the exception than the rule, ie. It 
> makes the bug a showstopper for that release.

Which implies that if anything, we'd create a separate field for estimated fix 
dates, if we ended up doing that at all. Being an estimated fix date, and given 
everything that has already been said so far, this field will never be close to 
accurate enough to be relied upon. This defeats the purpose of it for 
situations where someone actually wants to contribute a fix and is (for some 
reason) relying on it to know whether they can begin working on it, rather than 
just taking action and contacting the responsible developer. And if it's not 
useful in that scenario, when would it be useful?

That is to say, P1s and P0s will (hopefully) always get fixed quickly, but 
anything beyond that depends on a huge factor of things. There's no useful 
estimate that can be given unless the set of bugs is tiny. Even if estimates 
could be given for some specific bugs, there's no guarantee it would be for the 
ones that Denis is interested in, and so you'd still end up with people being 
wished away to hell... and I think we can both agree that hell is not a 
productive working environment.

> If you maintain something you know best about plans. So share your
> estimation! (this field is here for a reason).

Nope, that's not what it's for.

> You know tasks, you visit meetings there plans are discussed, you
> communicate with other who involved ... you know situation with module
> better then others ... so why not share your vision in this simple field?

See above.

> Moreover this field can be used to better support prioritization for
> maintainer plans.

I don't see how this changes anything. The maintainer already has an overview 
over the priority of bugs. As always, people will disagree with that priority, 
and, as always, they'll get told the same things they're being told by others 
in this thread.
 
> Bugs with same priority but lower Fix Version have higher priority. So
> actually beneficial for maintainers too.
> 
> 
> Moreover there are other 2 fields which also need to be set. And not
> filling them give instability for the bug too.
> Do not want instability in feedback ... make bug's state stable. Easy!
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Mitch Curtis]

> -Original Message-
> From: Development [mailto:development-bounces+mitch.curtis=qt.io@qt-
> project.org] On Behalf Of Prav
> Sent: Thursday, 21 July 2016 1:32 PM
> To: development@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@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Prav]

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

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

[Prav]

Hello, Everyone.

>> So while I agree that angriness is not helpful for mail list ... messages 
>> like this
>> are probably the seed to rethink strategy of working with bugs.

> Somewhat a side remark, but the unfortunate consequence of this thinking is
> that the objectively best way to get a lot of Qt developers interested in your
> problem is to write e-mails that breach of etiquette (to put it mildly).

This will NOT ever be a result (unfortunate consequence) of such thinking. And 
this is again about details. Proposed reaction is NOT about fixing Denis's bug.
Proposed improvements probably will not help with exactly this bug ever as this 
is more about maintainer's work.
Because if fixing start to be a result of insulting in emails/mailinglist ... 
then mailinglist became in majority "insulting platform"

Improvement is for making bug-tracking better is sense of giving less reasons 
for bug-reporters in general to ever write such letters.
And as result will be lower insulting ... and NOT like you have said
> "objectively best way to get a lot of Qt developers interested in your 
> problem is to write e-mails that breach of etiquette"
... we always meet this devil in details.


Predictable "unfortunate consequence" of not improving will be more such 
letters (IMHO). Which mean that "objectively best way" (as you have said) to 
react to such letters is
to improve bug-trackering in general ... to give less food to write such 
letters.

Food for this is "floating"/unstable state of reporter which comes from silent 
behaviour of maintainer (bug is unprocessed ... which means necessary fields 
are still blank).
Do NOT make reporter's state unstable and you will never get unstable messages 
from reporter. EASY!


> If Denis would have written a reasonable e-mail asking about the status of Qt
> Multimedia (without insults, attacks, and wishing anyone to hell), we most
> probably won't have this discussion.

> I think Denis should end this e-mail thread by apologizing, and start a new 
> one
> in a reasonable way.

Agree. But his behavior is the result of some objective problems which should 
not be rejected ALSO.

I think this is about of mutual respect. Maintainer have to consider influence 
of keeping silent about bugs as NEGATIVE INFLUENCE on bug-reporter.
And IMHO this influence is not fully understanded by some maintainers ... and 
now we have Denis's letter.

I do not know what can be the best analogy ... probably it is like
when you ask librarian about some missing book you can not find and he/she does 
not answer ... with not NO, not YES ...
zero reaction on you ... just keep doing something he/she was doing ... this 
surely earlier or later will piss you off.
And next event - reaction ... it depends on person. And you gess what ... some 
people will start insulting!
So here we are ... predictable percent of insulting in such cases.


Again IMHO ... in this case probably better to ask both sides to make 1 step 
toward peace.
Yoann Lopes to process the bug (fill the fields ... not fixing it ... fixing is 
up to mainteiners plans which should come from bugs priority) and Denis 
Shienkov to apologies for rudeness.



PS
People with high emotional level can be considered as bad because of negative 
effect of insulting overs.

BUT having such persons inside society helps find problems earlier because they 
are ones who feels problems most painfully because of this high emotionality.
So this feature can be used by society in positive key. And I do not reject 
that insulting practice badly influence society too. Here we simply have 
phenomenon (medal) with two sides


And I agree that probably we can start another thread for discussion of ways to 
improve bug-tracker.
Because this thread has some too negative messages which gives unproductive 
effect for cooperation for improving things.

Let's see if Denis will start the new thread for making bug-tracker better 
place. And I will copy with pleasure my letter about my vision on improvements 
in this thread.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Jocelyn Turcotte]

> On 21 Jul 2016, at 11:01, Denis Shienkov  wrote:
> 
> @ Thiago,
> 
> >The one you linked to is P2 - Important. It's neither critical nor
> showstopper.
> 
> It isn't I did the decision about assigning the P2 status. I personally would 
> establish P0/P1 if it would make sense (but, it is just "empty work" which 
> won't change anything).  
> Since many bugs with P1 statuses still are not considered.
> 
> > It's not critical, according to whoever triaged it.
> 
> If the AVI video playback shows with 0.5-1 FPS then it is not critical for 
> you? Then it is strange for me... o_O
> 
> > Where's your proof?
> 
> My proof - it is a BUG tracker and current QtMM status.
> 
> @ Kai,
> 
> > I think Denis should end this e-mail thread by apologizing, and start a new 
> > one
> in a reasonable way.
> 
> I do not consider myself as the guilty person and I have nothing to apologize.

I think that the bug is important, and I can understand how hard this bug can 
affect the product that you're trying to ship but you can't be angry at Yoan 
personally. If he choses to fix your bug to justify his salary, he will have to 
decide what else NOT to do, which will most likely make somebody else angry. 
It's his decision as to what to fix, and knowing how difficult it is to 
maintain a cross-platform multimedia library I think that you greatly 
underestimate his value as the QtMM maintainer in your message.

The real issue is that QtMM is understaffed, and I can only see one outcome 
resulting from you making him responsible for your user's disappointment: make 
him less motivated to do his job to the point where nobody else wants to work 
on QtMM. Is this what you want?

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.

It can be frustrating relying on somebody else for your own software's quality, 
but open source projects have no responsibilities other than managing a flow of 
efforts toward a common goal. The project itself isn't responsible for fixing 
every issue or regression and there has to be a system of mutual benefit 
(usually ultimately involving money) to make things go forward. Food and coffee 
needs to go in the mouth of developers to produce those patches through key 
presses and mouse clicks, and anger doesn't help growing coffee.

Cheers,

Jocelyn Turcotte
http://woboq.com

> 
> BR,
> Denis
> 
> 
> 
> 
> 2016-07-21 10:41 GMT+03:00 Kai Koehne :
> > -Original Message-
> > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> > [...]
> > So while I agree that angriness is not helpful for mail list ... messages 
> > like this
> > are probably the seed to rethink strategy of working with bugs.
> 
> Somewhat a side remark, but the unfortunate consequence of this thinking is
> that the objectively best way to get a lot of Qt developers interested in your
> problem is to write e-mails that breach of etiquette (to put it mildly).
> 
> If Denis would have written a reasonable e-mail asking about the status of Qt
> Multimedia (without insults, attacks, and wishing anyone to hell), we most
> probably won't have this discussion.
> 
> 
> 
> I think Denis should end this e-mail thread by apologizing, and start a new 
> one
> in a reasonable way.
> 
> Just my 2 cents,
> 
> Kai
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Denis Shienkov]

@ Thiago,

>The one you linked to is P2 - Important. It's neither critical nor
showstopper.

It isn't I did the decision about assigning the P2 status. I personally
would establish P0/P1 if it would make sense (but, it is just "empty work"
which won't change anything).
Since many bugs with P1 statuses still are not considered.

> It's not critical, according to whoever triaged it.

If the AVI video playback shows with 0.5-1 FPS then it is not critical for
you? Then it is strange for me... o_O

> Where's your proof?

My proof - it is a BUG tracker and current QtMM status.

@ Kai,

> I think Denis should end this e-mail thread by apologizing, and start a
new one
in a reasonable way.

I do not consider myself as the guilty person and I have nothing to
apologize.

BR,
Denis




2016-07-21 10:41 GMT+03:00 Kai Koehne :

> > -Original Message-
> > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> > [...]
> > So while I agree that angriness is not helpful for mail list ...
> messages like this
> > are probably the seed to rethink strategy of working with bugs.
>
> Somewhat a side remark, but the unfortunate consequence of this thinking is
> that the objectively best way to get a lot of Qt developers interested in
> your
> problem is to write e-mails that breach of etiquette (to put it mildly).
>
> If Denis would have written a reasonable e-mail asking about the status of
> Qt
> Multimedia (without insults, attacks, and wishing anyone to hell), we most
> probably won't have this discussion.
>
>
>
> I think Denis should end this e-mail thread by apologizing, and start a
> new one
> in a reasonable way.
>
> Just my 2 cents,
>
> Kai
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> [...]
> So while I agree that angriness is not helpful for mail list ... messages 
> like this
> are probably the seed to rethink strategy of working with bugs.

Somewhat a side remark, but the unfortunate consequence of this thinking is
that the objectively best way to get a lot of Qt developers interested in your
problem is to write e-mails that breach of etiquette (to put it mildly).

If Denis would have written a reasonable e-mail asking about the status of Qt
Multimedia (without insults, attacks, and wishing anyone to hell), we most
probably won't have this discussion.



I think Denis should end this e-mail thread by apologizing, and start a new one
in a reasonable way.

Just my 2 cents,

Kai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Prav]

Hello, Everyone.

> Bugs are fixed when they are fixed. You won't get any estimate before the
> developer actually starts fixing the issue. And even then, it may take months
> or more until it actually gets fixed.

Agree but devil is in details. Currently there is a practice to not fill-out 
necessary fields for the bugs and not to change its status.
I exactly mean
* Not changing from Reported to Opened (or Need Info or Closed) ... like it is 
with discussed QTBUG-53019 (1/2 year old)
* Not assigning responsible person in Assignee field like it is for ex. with 
QTBUG-46812 (1 year old)
* Not assigning Fix Version/s ... which can mean there is no plans for the bug.
 No plans can be because of 3 reasons:
I do not care and going to silently ignore the bug
  OR
I agree with the bug but have so many bugs to fix already so that this 
is to far from my 1 month plan (or 3 month plan or 1 year plan ... nobody knows 
what plan is meant)
  OR
I except the bug but do not want to bother myself with filling this 
field about my plans


Having these details like this make such letters from time to time appear in 
mailing list. This is natural and is predictable result.

So while I agree that angriness is not helpful for mail list ... messages like 
this are probably the seed to rethink strategy of working with bugs.

This is probably means that we need some easy to use query in bug-tracker 
system which can show up "unprocessed bugs" ... which is bugs with
  state Reported
OR
  no Assignee
OR
  no Fix version
With sorting from oldest creation date to newest.

All unprocessed bugs make people float in unconditional state like
 floating 1: was the bug accepted or not (state is still Reported)
 floating 2: does anyone (mighty to fix it) knows about it (Assignee filed is 
empty)
 floating 3: how long approximately to wait for fix ... month, 3 months, year, 
10 years (Fix Version blank)

This unconditional state make people do what they do. For example angry letter 
can be easy the result of "floating 1".
May be my request need more buzz so that it will be processed.

If Yoann Lopes will fill the bugs fields why in the world would Denis Shienkov 
ever wrote this letter. Never.
Because attitude to the bug will be clear to him.
And Denis can only live with this (like trying to fix himself, or hire someone 
or stick to Qt 5.5.1 forever or whatever else)

I IMHO see Denis Shienkov's personal attacks to Yoann Lopes quite reasonable 
not in sense of not-fixing the bug but
in sense of not filling bug's fields ... Those fields are in the bug-tracker 
system FOR A REASON and it is
MORE THAN IMPORTANT for reporter to see them filled.


So I am trying to say that there is tendency for qt-devs maintainers to ignore 
value of described fields for reporters of bugs and
angry letter is predictable result of this tendency.

Instead of trying to shut up the Denis we better discuss current situation with 
bug-tracker and decide to make some clear for everyone tools
which can show up forgotten bugs (described idea of unprocessed bug query) 
which makes people write angry.


And I totally agree that "Bugs are fixed when they are fixed". And agree that 
maintainers need to respect Best Practices of working with bug-tracking ALSO
(which exactly mean filling out ALL these 3 fields ... they ALL are important).


>> Otherwise there is an impression that I talk there to myself or to a blank 
>> wall.
You see. He is telling that he feels unheard... he see no reaction ... and he 
start making buzz in mailing list. Very predictable.
But why this reaction should be exactly in fixing the bug? It can be enough to 
fill the bug's fields I think.
Maintainers also have limited working-time.



So what I propose IMHO seems to be a good balance for maintainers and 
bug-reporters.



So I have 3 questions in my mind about this:

Can we discuss this theme (about bug-tracker system) with some practical things 
which can be improved from ballancing perspectives of view to tracking of bugs?

Can Qt Product Managers arise the importance of Best Practices of working with 
bugs-tracker for developers?

Can someone create this query inside bug-tracker system and share it with 
everyone so that unprocessed bugs can be shown?

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Thiago Macieira]

On quinta-feira, 21 de julho de 2016 00:19:44 PDT Denis Shienkov wrote:
> It is strange for me, that is performed some "unclear" work there (which
> is improves nothing, but introduces a new bugs IMHO) instead of fixing
> of a *critical* bugs.

The one you linked to is P2 - Important. It's neither critical nor 
showstopper.

> Do you tests before release our module? I think - NOT!

Where's your proof?

> Concerning QtMM maintainer: he should at least let us to know to
> bug-tracker, that the concrete issue will been accepted or not (at least
> not to be silent there).

Bugs are fixed when they are fixed. You won't get any estimate before the 
developer actually starts fixing the issue. And even then, it may take months 
or more until it actually gets fixed.

> Otherwise there is an impression that I talk there to myself or to a
> blank wall.
> 
> Besides, I don't understand, how is it possible to skip such critical
> bug (and others critical bugs), and not to notice it.

It's not critical, according to whoever triaged it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

[Denis Shienkov]

Hi Andy,

I periodically do watching for qt codereview status. So, your provided 
links has not effect for me (I'm do not surprised).


It is strange for me that the majority of these commits have no 
task-numbers, there is an impression, that bugs in a tracker are just 
ignored.


It is strange for me, that is performed some "unclear" work there (which 
is improves nothing, but introduces a new bugs IMHO) instead of fixing 
of a *critical* bugs.


Do you tests before release our module? I think - NOT!

Concerning QtMM maintainer: he should at least let us to know to 
bug-tracker, that the concrete issue will been accepted or not (at least 
not to be silent there).


Otherwise there is an impression that I talk there to myself or to a 
blank wall.


Besides, I don't understand, how is it possible to skip such critical 
bug (and others critical bugs), and not to notice it.


PS: I already repeatedly wrote to mailing-list concerning to QtMM 
status, but nothing changes. I think, nothing will change in future too.


BR,

Denis







20.07.2016 23:38, Andy Nichols пишет:


Hi Denis,


This type of mail in not constructive at all, and is not appropriate 
on this list.



You could propose your concerns about your bug on the bug tracker and 
this mailing list without the personal attacks on a Qt Project developer.



There is active development on the QtMultimedia module even now in the 
vacation season:


https://codereview.qt-project.org/#/q/project:qt/qtmultimedia,n,z


And your claim that the QtMultimedia maintainer Yoann is somehow not 
doing his job is dead wrong:


https://codereview.qt-project.org/#/q/owner:%22Yoann+Lopes%22,n,z


It's not right for you to try shame a fellow developer about someone 
on the public mailing list just because you are upset your bug is not 
being fixed.



Not cool.


Andy Nichols


*From:* Development 
 on behalf of 
Denis Shienkov 

*Sent:* Wednesday, July 20, 2016 10:16:37 PM
*To:* development@qt-project.org
*Subject:* [Development] [QtMultimedia] Still is supported, active?
Hi guys,

I write the angry letter concerning fixing of errors in QtMM the module.
Sorry, but I have no more patience to be silent.

This module contains a set of *critical* errors, some of which aren't
not fixed within 6 months. For example, currently
it is impossible to use QtMM > 5.6 in Windows for video playback, e.g:
https://bugreports.qt.io/browse/QTBUG-53019

This epic bug was introduces in 5.6 and above, though in 5.5.1 it works
"fine".

I had an impression that the maintainer of QtMM (Yoann Lopes) has become
deaf, has become blind, or just ignores any task in the bug tracker. WTF?

As I know he is working in Qt's company (at least from e-mail), receives
money
  for his work, but does nothing.. WTF?

WTF? If you don't support this module - then, please, remove away him to
devils, to hell.

Thanks for attension.

BR,
Denis

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development