[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