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
_______________________________________________ Mailing list: https://launchpad.net/~ubuntu-bugcontrol Post to : ubuntu-bugcontrol@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol More help : https://help.launchpad.net/ListHelp
