ubuntu-bugcontrol team mailing list archive

[Mitchell Augustin <mitchell.augustin@xxxxxxxxxxxxx>]

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.augustin@xxxxxxxxxxxxx> 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-uYp07FgM6T1OZQKqAdSA5JrZo0ReNEyZgQZub4mDRrV5w@xxxxxxxxxxxxxx/,
> https://lore.kernel.org/all/20250218222209.1382449-1-alex.williamson@xxxxxxxxxx/),
> 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.augustin@xxxxxxxxxxxxx
Location:United States of America


canonical.com
ubuntu.com