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