[14:30] <cpaelzer> hey
[14:31] <didrocks> o/ (for once, in a meeting, but mostly around)
[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:33] -ubottu:#ubuntu-meeting- Launchpad bug 2028054 in hplip (Ubuntu) "[MIR] python-rlpycairo" [Undecided, Confirmed]
[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:34] -ubottu:#ubuntu-meeting- Launchpad bug 2054480 in nbd (Ubuntu) "[MIR] nbd-client" [Undecided, Incomplete]
[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:36] <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] -ubottu:#ubuntu-meeting- Issue 54 in canonical/ubuntu-mir "Remove libgoa from the upstream redflags" [Open]
[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] -ubottu:#ubuntu-meeting- Launchpad bug 2060035 in msgraph (Ubuntu) "[MIR] msgraph" [Undecided, Fix Released]
[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] -ubottu:#ubuntu-meeting- Issue 55 in canonical/ubuntu-mir "end-of-cycle unexpected changes" [Open]
[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
[15:00] <meetingology> Meeting ended at 15:00:17 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-04-23-14.31.moin.txt
[15:00] <didrocks> sounds like a nice way to end up the cycle! :)
[15:00] <sarnold> thanks cpaelzer, all
[15:00] <didrocks> thanks!
[15:00] <slyon> thanks cpaelzer, all! o/
[15:00] <eslerm_> o/
[18:59] <amurray> o/
[19:00] <seb128> hey
[19:01] <amurray> hey seb128
[19:01] <seb128> bah, looks like I forgot to update the wiki after the previous meeting!
[19:01] <seb128> https://irclogs.ubuntu.com/2024/04/09/%23ubuntu-meeting.html
[19:01] <seb128> "Next chair will be vorlon, with sil2100 as backup"
[19:01] <seb128> Steve sent apologies
[19:02] <seb128> I expect Lukasz is busy on release week but he didn't decline/send an email, let me ping him
[19:02] <seb128> Robie declined the calendar invite
[19:04] <seb128> amurray, Lukasz doesn't seem to be online...
[19:04] <seb128> it's not really surprising that on release week that people are busy with other things
[19:05] <seb128> amurray, should we just skip that one?
[19:05] <amurray> yeah, fair enough
[19:06] <seb128> alright, I will update the wiki with the content with the previous meeting and bump the next meeting date / keep the chairs
[19:06] <amurray> also the next one is scheduled during the product roadmap - so I assume we'll skip that too and so next TB meeting would be 21st may
[19:06] <seb128> amurray, thanks and have a nice day!
[19:06] <seb128> ah, fair comment, I will do that directly and email the list about  it
[19:06] <amurray> cheers - you too - have a good night :)
[19:06] <seb128> thanks :)