Forwarding to Brian Murray since I didn't ever see this appear on the bugcontrol mailing list archive.
Thanks in advance, Mitchell Augustin On Fri, Jun 20, 2025 at 5:59 PM Mitchell Augustin <mitchell.augus...@canonical.com> wrote: > > I, Mitchell Augustin, apply for membership in the ~ubuntu-bugcontrol team. > > https://launchpad.net/~mitchellaugustin > Matrix: @mitchellaugustin:ubuntu.com > > > 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 to both :) > > > 2. Have you read Bugs/Triage, Bugs/Assignment, Bugs/Status and > > Bugs/Importance? Do you have any questions about that documentation? > > Yes. One question: > > "Never assign a report to others" > > I assume there is an implicit "without discussing with them first" at > the end of this, right? It's pretty common for my teammates and I to > move bugs between each other when the situation calls for it, but we > always discuss in advance of changing the assignee. > > > 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. > > Any personally identifying information, such as passwords, usernames, > banking info, keys, etc. > > > 4. Is there a particular package or group of packages that you are > > interested in helping out with? > > Since I've gained some experience working on edk2 over the past few > months, I'd be happy to help with bug triage in it and related > packages > > > 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. > > 1. https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/2101903 > > I diagnosed and fixed the underlying issues of the slow VM boot > behavior described in this bug, which was originally reported to us by > Nvidia. Throughout this process, I extensively communicated with the > upstream edk2 and linux vfio-pci maintainers and ultimately > contributed to both the solution for the underlying kernel issue > (https://lore.kernel.org/all/cahta-uyp07fgm6t1ozqkqadsa5jrzo0reneyzgqzub4mdrr...@mail.gmail.com/, > https://lore.kernel.org/all/20250218222209.1382449-1-alex.william...@redhat.com/), > as well as the fix detailed in this bug report (which was required for > Noble, since the underlying kernel fixes were too substantial to be > SRUd into the Noble kernels). The result of this work is that VMs with > large GPUs passed-through can now benefit from boot times that are > several minutes faster than without this patch. > > I was the bug report creator and author of this ovmf/edk2 fix patch > (https://git.launchpad.net/ubuntu/+source/edk2/tree/debian/patches/0001-OvmfPkg-Use-user-specified-opt-ovmf-X-PciMmio64Mb-va.patch?h=applied/ubuntu/plucky) > and forwarded it upstream > (https://github.com/tianocore/edk2/pull/10856) > > I triaged this as "Medium" since it has a moderate impact > (significantly degraded boot speeds, but still retains full > functionality) on a core application (ovmf, which is a core component > of many virtualization stacks) > > After the patch was released in Noble's ovmf, I updated the bug report > to include the exact steps that one could use to achieve faster boot > speeds on Noble. > I have also retroactively searched around for bug reports (in and out > of LP) related to VM boot slowness with passthrough and linked my bug > report as additional context for future users who may face this issue, > since I've found myself in that position before and have always > appreciated when original contributors to those forum threads follow > up with their solutions. (ex: > https://edk2.groups.io/g/devel/message/121427, and at the top of my LP > 2097389, which seems to get a bit higher SEO rankings in Google) > > 2. https://bugs.launchpad.net/curtin/+bug/2037682 > > I helped diagnose the underlying issue in this report and was the > author of the fixes detailed in this bug. (There was one patch for > Curtin itself, linked in the bug, and another that solved the issue at > the DKMS level, which I forwarded and had merged upstream: > https://github.com/dell/dkms/pull/403) > > Throughout this process, I communicated significantly with the dkms > upstream maintainers and the Curtin team, both of whom were > appreciative of the work and merged the respective patches to their > projects. > > I triaged this as "Medium" since it had a moderate impact (infrequent > hangs during initial provisioning that could usually be resolved with > a retry) on a core application (curtin). I opted not to set it as > 'high' since it was only impacting fresh installations, so there was > no destruction of past state, and since it only occurred sporadically. > > 3. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2111861 > > I also triaged this as "Medium" for the same reasons as (1), since > it's related to the same underlying issue. Similar to my other reports > about this issue, I also linked back to a note for how Noble users can > work around it with my ovmf patch, in case they stumble across this > related report when Googling. > > 4. https://bugs.launchpad.net/ubuntu/+source/ipmitool/+bug/2076173 > > This is an SRU that I worked on as part of a partner request. I > triaged this as a "Low" importance bug, since this is how I treated it > during development (with the agreement of our partner who reported > it). This was based on it only being impactful for a subset of > ipmitool's functionality on a few platforms that were not heavily used > at the time, and since our partner was OK with us waiting for upstream > to merge the functionality described therein. > > 5. https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/2115033 > > I triaged this as a "High" importance bug, since it breaks the build > of a heavily used coreutil. I would not mark it critical since it is a > build-time issue that would not cause any persistent issues with > existing deployments. > > 6. > https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/2115054 > > I triaged this as a "Wishlist" importance bug, since it is a user > request for new functionality in openvpn that would just make the user > flow more obvious - but the bug doesn't actually result in any > degradation of the underlying service. > > Thank you in advance for your review of my application, > > -- > Mitchell Augustin > Software Engineer - Ubuntu Partner Engineering -- Mitchell Augustin Software Engineer - Ubuntu Partner Engineering Email:mitchell.augus...@canonical.com Location:United States of America canonical.com ubuntu.com _______________________________________________ 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
