ubuntu-bugcontrol team mailing list archive

[Jeremy Szu <jeremy.szu@xxxxxxxxxxxxx>]

Hi,

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 do and I signed off the "Ubuntu Code of Conduct" already.
Here is my launchpad account https://launchpad.net/~os369510

Have you read Bugs/Triage, Bugs/Assignment, Bugs/Status and
> Bugs/Importance? Do you have any questions about that documentation?
>
Yes, I read them and they are awesome, I even think we should consider
leveraging the rules in our private projects with some adjustments to
secure the developers' resources.

What sensitive data should you look for in a private Apport crash report
> bug before making it public? See Bugs/Triage for more information.
>
>From the wiki, there are many:
*original stacktraces, Stacktrace.txt (retraced) and ThreadStacktrace.txt
(retraced)) have anything that looks like sensitive data passed as function
arguments. Examples are passwords, things that look like bank account
numbers, CSS keys, user names, server names, etc.*
In my personal experience, I would check "dmitable" as well as "lspci",
"lsusb" to see if the machine is a pre-market machine, also, whether having
some pre-market components on the system which is not yet announced by
vendor (under NDA to be enabled in Linux).

Is there a particular package or group of packages that you are interested
> in helping out with?
>
Due to my limited knowledge, I'm happy to support:
nvidia related: "ubuntu-drivers-common", "nvidia-graphic-drivers-...",
"nvidia-settings", "nvidia-prime"
hardware enablement: "linux", "linux-firmware"
system fundamental: "systemd*", "grub"
desktop environment related: "mutter", "gnome*", "mesa", "alsa*"
installer related: "ubiquity", "maas"

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.
>
Based on my previous experience, I usually need to tag target series of
linux package when doing the SRU, for example:
https://bugs.launchpad.net/bugs/1910561
https://bugs.launchpad.net/bugs/1920030
https://bugs.launchpad.net/bugs/1930707
https://bugs.launchpad.net/bugs/1939473
https://bugs.launchpad.net/bugs/1982716

So firstly, the linux-oem package is in the "main" but doesn't have a
"Task" field.
Based on the definition:

*"core":*

*A core package can be identified as being part of a task in the apt-cache
headers. You can see the apt-cache headers by running
apt-cache show [package] in a terminal, and looking at the "Task: " field
in the output.*

*"non-core":*

*A non-core package can be identified as a package that is not part of a
task, and is not in 'main'. You can see the apt-cache headers by running
apt-cache show [package] in a terminal, and looking at the "Task: " field
in the output.*
it looks to me that it does not belong to both definitions, however, due to
the importance of the kernel. I will treat it as a "core" package.
For these five, I think they are "medium" because "A usability issue that
does not limit the functionality of a core application." and "A problem
with a non-essential hardware component" which is LED as well as audio.

Although they happen on a specific platform (uncommon), it's not possible
to simply work-around.

A "Low" case could be:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1985887
In this issue, it's caused by a new systemd-oomd daemon and what we face to
this issue is because the stress test which is unusual scenario.
Although a user reports it happens on his side, it needs to copy a large
file from an external disk. Which is unusual to me.
I will set it to "Low" also because it has a low fail rate and users can
simply redo the action to work-around it.

A "High" to "Critical" case could be:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842320
This is an old bug, which will happen if the initramfs become larger.
It can be an easy work-around with the compression rate but once it happens
some users may not be able to boot the system (if the old kernel has been
auto-removed). User needs to boot from live-usb to save the system.
Also, at installation time, some users may not be able to boot up the
system for installation because casper grows the initramfs.
Although the impact is a lot, fortunately it requires users to use the high
resolution screen.
Until then, I may give a "High" importance.
However, a lot of users are impacted by this and the experience is terrible
(just do the `apt upgrade` or upgrade from 20.04), the system becomes
unable to boot. Users need to pay a lot of time finding this thread. Also,
many new laptops support 4K monitors. If the latest Ubuntu isn't able to be
installed on the latest machines, then it's upsetting. Thus, I may change
from "High" to "Critical" after the discussion.

-- 
Sincerely,
Jeremy Su