ubuntu-bugcontrol team mailing list archive

[Mitchell Augustin <mitchell.augustin@xxxxxxxxxxxxx>]

Thank you both for your review and feedback! I look forward to
triaging/solving more bugs like this going forward. :)

-Mitchell Augustin

On Thu, Sep 4, 2025 at 5:30 AM Sebastien Bacher <
sebastien.bacher@xxxxxxxxxxxxx> wrote:

> Hey there,
>
> Thanks Frank for forwarding, launchpad timeouts trying to load
> +editmailinglists on my account and such I can't subscribe to the
> mailinglist...
>
> @Mitchell, Thanks for your work on Ubuntu bug triage.  I've reviewed your
> application and I think your contributions record is sufficient to be a
> member of the team. I've added you now
>
> Cheers,
> Sébastien
> Le 04/09/2025 à 12:24, Frank Heimes a écrit :
>
> 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
>>
>> > 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
>>
>

-- 
[image: Canonical-20th-anniversary]

Mitchell Augustin

Software Engineer - Ubuntu Partner Engineering

Email:

mitchell.augustin@xxxxxxxxxxxxx

Location:

United States of America


canonical.com

ubuntu.com