Thanks for reviewing Skia, > Why is this coming so late in the cycle? The linked "upstream" patch seems to be 3 months old already, and could have been exercised way earlier.
The prototyping in WirePlumber was started three months ago, but it depended on an in-progress API in snapd[1]. The interfaces were changing as snapd iterated their design, so the WirePlumber prototype was moving along with it and not ready to be reviewed. Once that API was merged two weeks ago, I needed to update the snapd-glib[1] API to support the new interfaces for exposure to WirePlumber[2], which only landed a few days ago. > The "upstream" change is not really upstream, it's just in your tree. As mentioned, there's no guarantee that anyone from upstream has even red the code once, meaning that Ubuntu would have to maintain for 15 years a code that might actually receive no maintenance at all from any party involved, because the definitive solution might end up completely different. That also means future SRUs will have to deal with that piece of code no one has looked at before. I can't argue with those concerns... The ask was to get a prototype out to our users to gather feedback on an experimental feature to prove/disprove overall approach. I was using "upstream" only to differentiate from the packaging changes, apologies if that sounded like I was trying to suggest this was upstream reviewed. I thought in the worst case we could simply drop the patch to Wireplumber in a follow-up if things didn't work out. > On the "due to lack of interest in maintaining support for snapd integrations" part, I see no mention of that in the linked RFC. It might have been discussed elsewhere on a side-channel though. This was discussed in a side-channel. An upstreamable mediation API would need to generic over the prompting backend (not snapd specific as proposed here) and would require larger architectural work that upstream hasn't shown much bandwidth yet for working on. Given priorities this cycle, such a coordination effort wasn't feasible, instead the idea was to get a minimal prototype out there for user-feedback. > However, I'd like to suggest a different approach to still enable experimenting with that in Resolute: ship that in a different, new package The initial approach I considered was to ship the module disabled by default, requiring a configuration change to enable (applied by a new binary package). The requirement I was working to was a low-friction opt-in experience, a toggle in Security Center to enable prompting globally, which made a default-loaded pass-through module the chosen path, not requiring user to modify any configuration or install additional packages. [1] https://github.com/canonical/snapd/pull/16630 [2] https://github.com/canonical/snapd-glib/pull/224 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2144988 Title: [FFE] Introduce permission prompting module for microphone access To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wireplumber/+bug/2144988/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
