14:31 <cpaelzer> #startmeeting Weekly Main Inclusion Requests status
14:31 <meetingology> Meeting started at 14:31:27 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
14:31 <meetingology> Available commands: action, commands, idea, info, link, nick
14:31 <cpaelzer> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe )
14:31 <slyon> o/
14:31 <eslerm_> o/
14:31 <dviererbe> o/
14:31 <cpaelzer> Let us see if the release week is calm or already showing a barrage for next cycle
14:31 <cpaelzer> #topic current component mismatches
14:31 <cpaelzer> Mission: Identify required actions and spread the load among the teams
14:31 <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
14:32 <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
14:32 <cpaelzer> empty but the known false positive
14:32 <cpaelzer> #topic New MIRs
14:32 <cpaelzer> Mission: ensure to assign all incoming reviews for fast processing
14:32 <slyon> cpaelzer: thanks for promoting all the recent mismatches!
14:32 <cpaelzer> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir
14:32 <cpaelzer> np slyon, it was my contribution to get the release ready
14:32 <cpaelzer> list is empty as well
14:32 <cpaelzer> #topic Incomplete bugs / questions
14:32 <cpaelzer> Mission: Identify required actions and spread the load among the teams
14:32 <sarnold> good morning
14:32 <cpaelzer> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir
14:33 <cpaelzer> one case not yet discussed (6 days old AFAICS)
14:33 <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/python-reportlab/+bug/2028054
14:34 <slyon> nothing new here, I guess.
14:34 <slyon> can stay as-is, or be set to Invalid..
14:34 <cpaelzer> a good explanation on why things can be not in main
14:34 <cpaelzer> thanks Till
14:34 <slyon> gentle reminder for sarnold to have a brief look at https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/2054480 -- but it will be post Noble at this point.
14:34 <cpaelzer> can stay as-is
14:35 <slyon> (so take your time)
14:35 <sarnold> slyon: aye :( it's beena  busy week. last time around I forgot this, time around around I deprioritized it :(
14:35 <cpaelzer> ack to have this early in 24.10
14:35 <cpaelzer> sarnold: understandable, and now the ship has sailed - so take your time
14:35 <sarnold> :(
14:35 <cpaelzer> do not be sad!
14:35 <cpaelzer> #topic Process/Documentation improvements
14:35 <cpaelzer> Mission: Review pending process/documentation pull-requests or issues
14:35 <cpaelzer> #link https://github.com/canonical/ubuntu-mir/pulls
14:35 <cpaelzer> #link https://github.com/canonical/ubuntu-mir/issues
14:36 <cpaelzer> two newer cases worth to discuss
14:36 <cpaelzer> https://github.com/canonical/ubuntu-mir/issues/54
14:36 <cpaelzer> +1 from me as well
14:36 <slyon> +1 for dropping the libgoa-* restriction!
14:36 <cpaelzer> any objections, maybe we miss why it was excluded
14:37 <slyon> This is related to https://bugs.launchpad.net/ubuntu/+source/msgraph/+bug/2060035
14:37 <didrocks> +1 too
14:37 <sarnold> it's funny, I had the impression goa overall was deprecated or similar?
14:38 <eslerm_> I have not looked into libgoa deeply. It sounds reasonable due to webkit removal, but extra attention around oauth2 sounds useful as well
14:39 <cpaelzer> would that extra attention need effort?
14:39 <cpaelzer> or is it just a benefit of the new goa handling it that way?
14:40 <eslerm_> it is certainly a much better scenario than including webkit
14:40 <cpaelzer> ok, then I think I'll land a change as requested
14:40 <cpaelzer> thanks for the discussion
14:41 <cpaelzer> Next is an absolutely valid complain https://github.com/canonical/ubuntu-mir/issues/55
14:41 <sarnold> +441 -1334  :D :D :D
14:41 <cpaelzer> hehe @sarnold
14:41 <cpaelzer> was that a rush - yes
14:41 <cpaelzer> but no one had better options
14:42 <cpaelzer> Instead of just shrudding I usually aim for lessons learned and improvements
14:42 <sarnold> indeed, what I'm hoping to come of this is perhaps an idea of how some automation could be built to help us find cases half-way through a cycle
14:42 <cpaelzer> In this particular case i can tell you that the reason for it was a loss of ownership between 4 teams
14:42 <cpaelzer> and the fix is also already clear, we have concluded who owns it (will be CPC) properly and that will be in place in a bit
14:42 <cpaelzer> working with Eric on this
14:42 <cpaelzer> the other outcome is something along the suggestion of sarnold
14:43 <cpaelzer> how to detect "unmaintained" earlier/better
14:43 <cpaelzer> but just to mention, this was known to be unmaintained - yet it fell into the responsibility cracks
14:43 <didrocks> I would put unmaintained equating multiple owners, which ends up to no owners
14:44 <cpaelzer> didrocks: exactly
14:44 <cpaelzer> didrocks: at least the chance of behaving that way
14:44 <cpaelzer> does anyone have code to check project health in a sane way this could be built upon?
14:45 <cpaelzer> Hmm
14:45 <sarnold> in some sense there's probably too many "project health" metrics that exist and could be used, and none probably has enough signal to noise
14:45 <didrocks> nothing comes to mind, I think this task needs a proper owner (pun intended) with research to provide metrics + ubuntu specifity and so on…
14:45 <cpaelzer> This might be a step in the release process
14:45 <cpaelzer> like Release -x weeks
14:45 <sarnold> didrocks: lol :)
14:45 <cpaelzer> check all your subscribed packages if they are maintainable
14:46 <didrocks> maybe a first easy step is how long since the last package update?
14:46 <didrocks> not a very good metric, but sounds an easy one enough (we need to exclude pure rebuild-only upload though)
14:46 <didrocks> that would mean some maintainance, but a random definition of "some" :)
14:47 <sarnold> how long since a new upstream release?
14:47 <slyon> There's the Canonical spec CT002, which might help with that..
14:48 <slyon> "CT002 - Supply Chain Community Analytics"
14:48 <sarnold> heh :( the search function doesn't find find it via 'ct002' or 'suppl'
14:48 <didrocks> (I don’t have access to it)
14:49 <sarnold> .. and the site lacks the usual 'report a bug on this site' -- who owns this site to report a bug that it lacks a bug report link? :)
14:49 <slyon> https://docs.google.com/document/d/1tUrHVI-EIC7vJ4QmOkr_SoJX7b4ykSyoxVffGPwgLBw <- Canonical employees should be able to access this
14:49 <didrocks> sarnold: heh :)
14:50 <didrocks> thanks slyon
14:50 <jbicha> sarnold: GNOME devs seem a bit meh about GNOME Online Accounts in a world with lots of sandboxed apps; I think UOA may have had a better architecture for that. But meanwhile GOA is still useful for the base desktop
14:50 <cpaelzer> Updating the issue
14:51 <slyon> I think they are planing some recurring porject health checks, which we might be able to rely upon
14:51 <sarnold> jbicha: hmm, I hadn't thought about sandboxing here.. I can see why that would influence their thinking. but if it's not explicitly dead, yay.
14:52 <cpaelzer> updated the case, it will stay open until there is an owner to work on the tooling and/or the discussion to get it into the release process
14:52 <cpaelzer> thanks for the input on GOA jbicha
14:53 <cpaelzer> going on in the agenda
14:53 <cpaelzer> #topic MIR related Security Review Queue
14:53 <cpaelzer> Mission: Check on progress, do deadlines seem doable?
14:53 <cpaelzer> Some clients can only work with one, some with the other escaping - the URLs point to the same place.
14:53 <cpaelzer> #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=%5BMIR%5D&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir
14:53 <cpaelzer> #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=[MIR]&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir
14:53 <cpaelzer> Internal link
14:53 <cpaelzer> - ensure your teams items are prioritized among each other as you'd expect
14:53 <cpaelzer> - ensure community requests do not get stomped by teams calling for favors too much
14:53 <cpaelzer> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
14:53 <cpaelzer> thanks for having the boto stack there
14:53 <cpaelzer> all else looks as I'd expect
14:55 <sarnold> eslerm_ knocked out the libyuv mir while traveling :)
14:55 <slyon> thank you so much!
14:56 <sarnold> otherwise seems to be mostly known states
14:56 <cpaelzer> great
14:56 <cpaelzer> #topic Any other business?
14:56 <slyon> nothign
14:56 <sarnold> thanks for making this the smoothest lts cycle that I remember
14:57 <slyon> do I hear sarcasm there? Or does it just relate to the MIR process?
14:57 <didrocks> I really appreciate how the security part is now predictable and working well!
14:58 <sarnold> it took a lot of concerted work from a lot of people to prune dependencies, work with upstreams, and figure out how to get things done predictably
14:58 <didrocks> on the smooth part, I would say at least for me that the MIR part woud qualify as such :)
14:58 <didrocks> would*
14:58 <sarnold> slyon: the MIR process -- xz was  a thing, but you and vorlon and crew managed to keep us on schedule all the same
14:59 <cpaelzer> yeah
14:59 <slyon> indeed, MIRs were mostly well planned and executed this cycle!
14:59 <cpaelzer> that thanks I definetly share
14:59 <cpaelzer> in the past MIR process weird, Release easy - now the inverse :-)
14:59 <eslerm_> thanks everyone :)
15:00 <cpaelzer> I'll call the meeting done with these nice words
15:00 <cpaelzer> onto another good cycle (for the things we can influence)
15:00 <sarnold> :)
15:00 <cpaelzer> #endmeeting