14:36 <slyon> #startmeeting Weekly Main Inclusion Requests status
14:36 <meetingology> Meeting started at 14:36:08 UTC.  The chair is slyon.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
14:36 <slyon> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe )
14:36 <slyon> #topic current component mismatches
14:36 <slyon> Missio
14:36 <meetingology> Available commands: action, commands, idea, info, link, nick
14:36 <slyon> Mission: Identify required actions and spread the load among the teams
14:36 <slyon> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
14:36 <slyon> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
14:37 <slyon> This looks all very common. Mostly known false-positives. Except for jaraco.text, which apparently didn't make it this cycle, again. :(
14:37 <slyon> #topic New MIRs
14:37 <slyon> Mission: ensure to assign all incoming reviews for fast processing
14:37 <slyon> #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:37 <slyon> empty.
14:37 <cpaelzer> I'm here now, but not the full length
14:37 <cpaelzer> thanks for driving the meeting slyon
14:37 <slyon> #topic Incomplete bugs / questions
14:37 <slyon> Mission: Identify required actions and spread the load among the teams
14:37 <slyon> #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:38 <slyon> going back one week 2023-10-03, we have only one update in bug #2023971
14:38 * slyon reading
14:39 <cpaelzer> I know that mirespace follows some leads I have given her
14:39 <cpaelzer> which will cut down the list of packages needed a lot
14:39 <cpaelzer> essentially she is trying to save us all 40 more MIR packages
14:39 <slyon> nice!
14:40 <slyon> Seems there are some clear next steps defined on her side
14:40 <slyon> Nothing to do for us, right now.
14:40 <slyon> #topic Process/Documentation improvements
14:40 <slyon> Mission: Review pending process/documentation pull-requests or issues
14:40 <slyon> #link https://github.com/canonical/ubuntu-mir/pulls
14:40 <slyon> #link https://github.com/canonical/ubuntu-mir/issues
14:40 <cpaelzer> PR is a draft and held back for better times
14:41 <cpaelzer> the issues are also old news
14:41 <cpaelzer> I think we can go on
14:41 <slyon> ack.
14:41 <slyon> #topic MIR related Security Review Queue
14:41 <eslerm> Simon asked for clarification on when tools in main needed re-review, as we had fro s390-tools
14:41 <slyon> Mission: Check on progress, do deadlines seem doable?
14:41 <slyon> Some clients can only work with one, some with the other escaping - the URLs point to the same place.
14:41 <slyon> #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:41 <cpaelzer> eslerm: you know the discussion on re-review as a process
14:41 <slyon> #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:42 <cpaelzer> which has thoughts, but everyone saying "no resources for that, please do not add it atm"
14:42 <slyon> eslerm: cpaelzer: and for s390-tools it was also a (hidden) component-mismatch
14:42 <cpaelzer> the reason for s390-tools has been because it was a voluntary (appreciated) "there is a massive change"
14:42 <slyon> as it was pulling in new non-reviewed dependencies. (even though vendored)
14:42 <cpaelzer> exactly - ack to slyon
14:43 <eslerm> thank you
14:43 <slyon> Internal link
14:43 <slyon> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
14:43 <slyon> So eslerm, do you want to give and update on the security review process?
14:43 <cpaelzer> or rather s/process/progress/ :-)
14:43 <eslerm> non-reviewed dependencies sounds like the whole process in general ?
14:44 <cpaelzer> it is the whole process, but they could have sneaked them in as they would have been vendored
14:44 <eslerm> Security doesn't have a great way to work through all vendoreded dependencies, rustc has ~700 and we can't review them all
14:44 <cpaelzer> so the tooling would not have stopped them
14:45 <cpaelzer> eslerm: you mean rustc itself has 700 other things?
14:45 <eslerm> ah, understood, I'll add a task to the jira board above
14:45 <eslerm> rustc/cargo has ~700 vendored packages
14:46 <eslerm> issues in those packages should be tracked too
14:46 <eslerm> rustc 1.70.0 has 532 folders in ./vendor/
14:47 <slyon> I agree. I'll start a discussion at the next engineering sprint about having toolchain maintainers provide a set of "base" dependencies (tiny but ubiquitous) for their ecosystem and help maintaining them in "main". Hopefully that should cover many of those 532 folders
14:48 <eslerm> thank you slyon
14:48 <eslerm> overlap with rustc is appreciated
14:48 <cpaelzer> which is one of the issues you see in github
14:48 <cpaelzer> talk about these base sets
14:48 <slyon> any other update from the security team?
14:49 <eslerm> none, except s390-tools being ack'd last week
14:49 <slyon> eslerm: Thanks and kudos. That's much appreciated! I know timing was very tight.
14:49 <slyon> #topic Any other business?
14:50 <slyon> cpaelzer: did you want to bring up anything?
14:50 <cpaelzer> no
14:50 <joalif> none
14:50 <slyon> ok. Nothing from my side either.
14:50 <eslerm> none
14:50 <slyon> Alright. I guess that's it then for today.
14:50 <slyon> thank you all!
14:50 <eslerm> thanks slyon, all o/
14:51 <slyon> #endmeeting