vim MP: MP LGTM, but the bug reference is missing from the changelog entry. Requested this change to Danilo, who addressed the request. Approved and uploaded.
Sponsored rsyslog merge. While there’s a newer version in Debian now, this version is a bug fix release and the new one is not entirely so it wouldn’t really fit FFe.
I used git-ubuntu prepare-upload args to sponsor the merges, so history should be preserved in the target branch!
rsyslog was handled in the past, discussed and unsubscribed sponsors.
openssh SRU which was not yet ready, reviewed, tested and recommended several changes
octavia-dashboard I was unclear if this would not need more to be ready and asked on the bug what I’d want. But then this was auto-subscribed and might not yet have meant to be ready.
Important context
There was no activity in IRC.
I ran a bit short due to unplanned meetings, but there wasn’t much more in the queue either (two more MPs of my team for which I can withstand the stares for not having them sponsored).
Looked over patches for r-cran-flextable, dipy, and pyfai. They all look fine to me. I don’t have upload permissions for any of them though so they’re still available for the next patch pilot.
https://bugs.launchpad.net/octavia/+bug/2024188 : I was about to upload, but checked in with the OpenStack team since there were mention of repositories other than the archive. It ended with @corey.bryant kindly offering to do the sponsoring.
Same story for the first two of a series of patches all related to support of the NXP S32G board (LP: #2034640, LP: #2034641)
Of the remaining patches, reviewed the arm-trusted-firmware one and left comments on some of the improvements that would be required (starting with where the patches come from). Was going to remove ubuntu-sponsors and mark incomplete but Laider Lai managed to respond very quickly with the requested changes so the next pilot can continue reviewing this one.
Also reviewed the u-boot one and left comments on some improvements that would be required, and the potential for the up-streaming of the changes. Removed ubuntu-sponsors for now.
Important Context
Most (at time of writing all) of the [needs-packaging] bugs in the queue are related to NXP S32G support.
There were 15 requests in the sponsorship queue. Two were apparantely already handled by the kernel team’s process and needed closing. Seven were contributions from one person from Canonical’s hardware enablement team, and don’t look like they can be handled through patch piloting. I reviewed and sponsored one. Two are already being reviewed by Andreas. One was for flash-kernel (another hardware enablement) that Dave has partially reviewed - perhaps he’s the best person to look again as it’s quite involved. That leaves two I didn’t have time to look at.
A common theme seems to be really complex hardware enablements or new features. I’m not sure these can ever be expected to be handled by generalist patch pilots, rather than Ubuntu developers with specialised experience in those specific areas. I’m concerned that we’re doing a disservice by encouraging these types of contributions to use the sponsorship queue. A topic for further discussion, perhaps?
The kernel team say they do not accept MPs and contributors must follow their process instead. This is not ideal and the opposite of my previous request. But the kernel team process is so far removed from the rest of Ubuntu development process that it’s probably not worth tackling that monster right now. For now, I closed the MPs since a kernel team member confirmed to me that these requests are being handled through their process.
The only reason these appear as git-ubuntu repositories in the first place is because we don’t have a good mechanism for me to detect kenrels and not import them. The list of kernel source packages is ever-growing and linux-firmware is for example not a kernel so a simple linux* match won’t work.
These are all filed by someone from Canonical’s hardware enablement team. Steve already mentioned in the first bug that it can’t be handled by generalist patch pilots since it also requires kernel process. The submitter doesn’t appear to have ever been on IRC as far as I can tell, so I was unable to just ask them there. I sent them a private message asking what process led them to submitting these here, and if they have an alternative, to try and understand how I might be able to improve the overall process here.
I’m not sure if it’s intentional that this other MP is no longer in the sponsorship queue due to [1], and/or if Andreas is expecting to look at it again himself or it should be reconsidered by a patch pilot. I pinged Andreas.
The status of the sponsoring queue is similar to that @rbasak described, with many very specific sponsorship requests mostly around kernel packages. I didn’t take action on those.