ubuntu-bugcontrol team mailing list archive

[Vej <ubuntu@xxxxxxxxxxxxxxxx>]

Hello!

Here are my comments regarding your application.

Am 11.09.2018 um 23:17 schrieb Paul White:
> 1) Do you promise to be polite to bug reporters even if they are rude to you or Ubuntu? Have you signed the Ubuntu Code of Conduct?
>
> Yes I promise to be polite to all bug reporters. I signed the CoC in 2010.
Great!
> 2) Have you read Bugs/Triage, Bugs/Assignment, Bugs/Status and Bugs/Importance? Do you have any questions about that documentation?
>
> Yes. I refer to them often when unsure of which of which option to take. I have various wiki pages bookmarked on my web browser tool bar and a number of items copied into my scratch pad for easy reference.
>
> My only question: Is there a reason why the Google Translate service is not recommended as a quick method of obtaining a translation?
The translations made by that service are a good way to get the rough details of a text, but they are sometimes misleading especially when technical terms are involved (this might depend on the source language). That is why I personally would not recommend that service for translating non English bug reports, but prefer the current solution using the translators. This is slower, but gives more reliable results.
> 3) What sensitive data should you look for in a private Apport crash report bug before making it public? See Bugs/Triage for more information.
>
> I've have always been aware that a bug report should not be made public if it contains any personal information that a bug reporter would never want to be made public such as passwords, bank details or encryption keys. Before making any of my own bug reports public I always ensure that any core dump file has been removed and have checked the stack traces for any text strings containing personal or private information.
>
> 4) Is there a particular package or group of packages that you are interested in helping out with?
>
> Desktop applications such as Firefox, Chromium, Synaptic, Thunderbird, FileZilla and Geany.
Sounds great .
> 5) Please list five or more bug reports which you have triaged and include an explanation of your decisions. Please note that these bugs should be representative of your very best work and they should demonstrate your understanding of the triage process and how to properly handle bugs. For all the bugs in the list, please indicate what importance you would give it and explain the reasoning. Please use urls in your list of bugs.
>
> a.  text within address bar is not automatically selected when I click in the address bar
> https://bugs.launchpad.net/bugs/1677641
>
>      Checked my own Firefox installation against the information given
>      Suspected there was a configuration option to enable expected behaviour
>      Searched through Mozilla documentation and advised reporter of appropriate article
>      Marked "Invalid" as Firefox is working as designed in Ubuntu
This is okay. One minor detail:  I would have told them that it is working as requested instead. Keep in mind, that a feature request would have been a valid bug which should have been put on the wishlist. So "works as requested" is a valid reason for invalid whereas "works as designed" is not, because it might generally be a request to change the design .
> b.  Firefox stops loading Farmville 2 and hangs
> https://bugs.launchpad.net/bugs/1740180
>
>      Asked reporter if problem still exists with latest Firefox release
>      Found upstream bug and added to report
>      Bug status changed to "Confirmed" as many other reports found on web regarding this issue
You should have stated that in the report because at it is nobody knows why you set this to confirmed. If I would have read this report before I would have assumed, that you confirmed it personally.
>      Corrected spelling of "Farmville"
>      Would mark with "Low" importance as the bug affects a single non-essential use of Firefox
I am fine with that.
>      Note:
>      Updated apport information was asked for as that was what I was initially asked to do. Experience has shown that it is best to check for an upstream or duplicate bug first and just ask if the bug is still being seen in a currently supported release of Ubuntu. I would generally ask for apport information if it has never been submitted and it would help to confirm version information and the desktop environment, kernel etc. If anyone fixing the bug needs to ask for it then they can at a more appropriate time.
>
> c.  Firefox 57 ignores package on halt
> https://bugs.launchpad.net/bugs/1732946
>
>      Ascertained not a Firefox bug
>      Found similar synaptic bug report
>      Marked as duplicate after asking reporter to confirm both bug reports referred to the same issue
>      I was involved in confirming the synaptic bug and marking it with "Low" importance as synaptic is no longer officially supported
Well I do not really like the reasoning here. You should try to assess the bugs importance related to the software you are dealing with. The fact that "synaptic is no longer officially supported" does only mean that this is of course a "non-core" application. Bugs in such applications can still be severe if they render that specific application unusable.

A better reasoning might be, that the halt function itself is not a core feature of synaptic and will thus impact only a small userbase (referring to "Bugs that affect a non-essential aspect and limited scope of the application" from https://wiki.ubuntu.com/Bugs/Importance).
>      Subsequently marked the synaptic bug a duplicate of 12-year old bug #42178 which I hadn't previously been aware of. This bug was also marked with "Low" importance.
>
> d.  Thunderbird asks three times for my master password
> https://bugs.launchpad.net/bugs/940631
>
>      Established bug report still valid after six years
>      Looked for upstream reports
>      Worked with reporter to establish which report best described his issue
>      Linked appropriate report and updated bug description
>      Added some info to upstream report
>      Informed reporter that bug should be fixed with an upcoming releaser
>      Arranged to be marked with "Low" importance as there is an easy workaround of pressing escape key twice after the first password prompt completed.
Well done!
> e.  Thunderbird hogs CPU while waiting for master password
> https://bugs.launchpad.net/bugs/1209095
>
>      Reproduced bug using current versions of Ubuntu and Thunderbird
>      Looked for an upstream report but didn't find one
>      Updated bug report to confirm bug still current
>      Created upstream report and linked report ID
>      Would mark with "Low" importance as affects limited scope of an application
>      Updated with revised Mozilla bug as my report was a duplicate of an existing report that had not found when searching
I would triage this as "Medium" according to "A bug that has a moderate impact on a core application. " (firefox is a core application as it is in the "ubuntu-desktop" task), as I regard the master password as an essential aspect thus disqualifying the rule "Bugs that affect a non-essential aspect and limited scope of the application " used by you.
> I thank you all for any time that you spend on reviewing and assessing my application.
I currently vote neutral, which may change to positive depending on the discussion with the rest of the team.

Best regards

Vej