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 < [email protected]> 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 <[email protected]> > Date: Thu, Sep 4, 2025 at 10:51 AM > Subject: Re: [Ubuntu-bugcontrol] ubuntu-bugcontrol application > To: Mitchell Augustin <[email protected]> > Cc: <[email protected]>, Jean-Baptiste Lallement < > [email protected]> > > > Hi Mitchell, > I'm leaving my comment in line (in blue) ... > > On Sat, Jun 21, 2025 at 7:10 AM Mitchell Augustin < > [email protected]> 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-uyp07fgm6t1ozqkqadsa5jrzo0reneyzgqzub4mdrr...@mail.gmail.com/ >> , >> >> https://lore.kernel.org/all/[email protected]/ >> ), >> 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 : [email protected] >> 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: [email protected] Location: United States of America canonical.com ubuntu.com
_______________________________________________ Mailing list: https://launchpad.net/~ubuntu-bugcontrol Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol More help : https://help.launchpad.net/ListHelp
