ubuntu-bugcontrol team mailing list archive

[Brian Murray <brian@xxxxxxxxxx>]

On Tue, Jan 17, 2023 at 07:04:29PM +0800, Jeremy Szu wrote:
> 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.

I agree with your assessment of a Medium importance for these bugs.

> 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.

You did a great job of engaging with the user and getting information
from them so that we better understand the issue. I actually consider
copying large files from an external disk more common than you do so
would give a bug involving that particular use case a Medium importance.

> 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.

Its worth mentioning that all Ubuntu installs should have at least two
kernels installed at any point in time so there should always be one
kernel to fall back to.

> 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.

I agree with a Critical importance here as difficulty booting is a
terrible experience and not easy to recover from even if two kernels are
available.

Thanks for your application, I've gone ahead and added you to the team!

Cheers,
--
Brian Murray