forwarding to Sebastien (since we talked about that offline, due to
issues with the ML)
---------- Forwarded message ---------
From: *Frank Heimes* <frank.heimes@xxxxxxxxxxxxx>
Date: Thu, Sep 4, 2025 at 10:51 AM
Subject: Re: [Ubuntu-bugcontrol] ubuntu-bugcontrol application
To: Mitchell Augustin <mitchell.augustin@xxxxxxxxxxxxx>
Cc: <ubuntu-bugcontrol@xxxxxxxxxxxxxxxxxxx>, Jean-Baptiste Lallement
<jean-baptiste.lallement@xxxxxxxxxxxxx>
Hi Mitchell,
I'm leaving my comment in line (in blue) ...
On Sat, Jun 21, 2025 at 7:10 AM 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 <http://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.
Yes, this is originally meant to not spam people and teams with random
assignments of bugs and annoy them.
If you have discussed a particular case with someone (team or person,
maintainer or developer etc.) and there is agreement that an
assignment should be done, it can be done of course.
In your particular working environment in PE (Partner Engineering, and
with that also in mine ;-) ) I agree that this is very often the case,
especially the assignments on a project level (rather than the
assignment on the package level).
Since these projects are usually PE projects, hence owned and managed
by PE, I would even say that these are out of scope for
'ubuntu-bugcontrol' - however, the same care and diligence should be
used there as well (whereas I have no doubt in your case).
> 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.
Yes, even IP addresses and generally information that can be collected
which might allow to profile an individual or a system.
> 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.
That's great, since I see that you already did quite some
contributions to the package:
https://launchpad.net/ubuntu/+source/edk2/+changelog
and some people that contributed to edk2 in the past now have other
assignments.
> 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)
I like that the upstream edk2 issue was added and referenced to the LP
bug, as well as the detailled SRU justification in the bug description.
I think that either attaching a patch/debdiff or MRs are sufficient -
but having both does not harm.
It is also great that you promptly answered the questions and concerns
from the SRU team (that is what they expect).
And you also took care about the transitioning, by solving failed
autopkgtest - great!
I think you handled this complex bug in a very good way - and your
additional explanations above are sound to me.
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.
Good contribution and upstream work here, and a good view of the
bigger picture - means curtin and dkms.
(I'm just wondering why no project is marked as affecting this, since
I seem to have been verified with Mlx OFED in PE, but anyway,
unrelated to ubuntu-bugcontrol.)
Looks like this happened in a devel release only ? Since it was not
makred by certain series' ...
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.
Here I think for such a big changes file, the 'Where problems could
occur' is probably not exhaustive enough, since there can be always
issues that may lead to a regression, but anyway, that was accepted by
the kernel team.
But the bug triage and handling was good.
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.
Ok, you kept the bug 'alive' (after it Expired) and drove it to
completion.
Here I see that it would have been good that you could do more work on
the bug management yourself, like nominating series etc.
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.
This is anoher bug that seem to have happened while working on the
devel release.
The rationale for the importance you decided upon is good.
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.
I think a correct rationale for toggling this to wishlish here.
Thank you in advance for your review of my application,
Especially the bugs at the beginning of your list, that you almost
entirely triaged and drove yourself (of course with the exception of
people that needed to help out for changes where you do not have
permissions yet) are good and (I guess) what we want to see in such an
application.
Based on this, as well as based on my interaction with Mitchell beyond
these work samples, I think he is thoughtful in his decisions and
(helps) to drive LP bugs to completion.
Hence I vote for adding Mitchell to the ubuntu-bugcontrol group !
--
Mitchell Augustin
Software Engineer - Ubuntu Partner Engineering
_______________________________________________
Mailing list: https://launchpad.net/~ubuntu-bugcontrol
Post to : ubuntu-bugcontrol@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol
More help : https://help.launchpad.net/ListHelp
