14:34 <sarnold> #startmeeting Weekly Main Inclusion Requests status
14:34 <meetingology> Meeting started at 14:34:00 UTC.  The chair is sarnold.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
14:34 <sarnold> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage
14:34 <meetingology> Available commands: action, commands, idea, info, link, nick
14:34 <sarnold> #topic current component mismatches
14:34 <sarnold> Mission: Identify required actions and spread the load among the teams
14:34 <sarnold> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
14:34 <sarnold> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
14:34 <jamespage> o/
14:34 <didrocks> sarnold was quicker than I getting the wiki page :)
14:34 <didrocks> lintian was false-positive, IIRC?
14:34 <sarnold> hey jamespage, didrocks :)
14:35 <didrocks> esmtp too
14:35 <cpaelzer> sorry, late
14:35 <didrocks> hey jamespage, cpaelzer
14:35 <sarnold> hey cpaelzer :)
14:35 <didrocks> sounds like we are ok on c-m-p and c-m?
14:35 <cpaelzer> reading backlog and thanks sarnold for driving
14:36 <sarnold> yeah, I think they look good \o/
14:36 <sarnold> #topic New MIRs
14:36 <sarnold> Mission: ensure to assign all incoming reviews for fast processing
14:36 <sarnold> #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:36 <didrocks> ah, there has been some updates on tune, let’s look
14:37 <cpaelzer> ok we got an explanation on tuned
14:37 <cpaelzer> tuna was removed for now
14:37 <cpaelzer> do we have all answers we waited for now?
14:37 <cpaelzer> we also got the separataiton from tlp/gamemode
14:37 <cpaelzer> sorry for all the wrong extra characters above :-/
14:38 <sarnold> oh very nice, that's a good explanation of unique and new features
14:38 <cpaelzer> indeed
14:38 <didrocks> yeah, no feedback on the lack of automated tests though
14:38 <didrocks> but I can have a look at do the usual MIR review
14:38 <cpaelzer> so "new version" and "add tests" will be requirements of the review by didrocks I guess
14:38 <cpaelzer> buth we can go on
14:38 <didrocks> ah nice :)
14:38 <cpaelzer> -h
14:39 <didrocks> ah sorry, misread you
14:39 <cpaelzer> ok, so do we agree that this can go back to "new + assigned to didrocks" ?
14:39 <didrocks> thought the new version was adding tests :)
14:39 <didrocks> yeah
14:39 <didrocks> doing so
14:39 <cpaelzer> no not yet, sorry
14:39 <cpaelzer> but it will have to some day before this completes
14:39 <cpaelzer> ok, bug status updated
14:39 <sarnold> okay, so what steps are we expecting Joseph to take before didrocks starts in on it?
14:40 <cpaelzer> I think none
14:40 <didrocks> I’m starting in parallel
14:40 <didrocks> and wrote about lack of tests/new version again: https://bugs.launchpad.net/ubuntu/+source/tuned/+bug/1988066/comments/11
14:40 <cpaelzer> we can let him know that autopkgtests and a version update will be requirements of the reivew result
14:40 <ubottu> Launchpad bug 1988066 in tuned (Ubuntu Jammy) "[MIR] tuned" [High, Confirmed]
14:41 <didrocks> so that we hopefully won’t block on it
14:41 <sarnold> great! nice comment
14:41 <cpaelzer> ack
14:41 <sarnold> #topic Incomplete bugs / questions
14:41 <sarnold> Mission: Identify required actions and spread the load among the teams
14:41 <sarnold> #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:42 <cpaelzer> I mentioned ccid and others last week
14:42 <sarnold> the ccid and related is sadly just ray finding greening pastures :(
14:42 <cpaelzer> we know they are postponed for now
14:42 <sarnold> libqrtr-glib is a challenging case, for discussion in prague, I think?
14:42 <cpaelzer> did anyone read through the updated test plan?
14:43 <didrocks> looks like it’s directly in the bug description
14:43 <didrocks> with "Our Desktop and oem teams don't have access to compatible hardware at the moment to go through the testplan.
14:43 <didrocks> "
14:43 <cpaelzer> which is fine
14:43 <cpaelzer> so I feel this is a reasonable update
14:43 <cpaelzer> we got as much as they can do, and they are willing to continue working with other teams to improve the situation
14:44 <didrocks> do we think that a testplan on a bug report is going to be useful later in time?
14:44 <didrocks> I feel it will go into $launchpad_limbo
14:44 <didrocks> at least, on the wiki, it’s a better place, no?
14:45 <cpaelzer> It is a good start that they have worked on improving it, wiki does not make it better. I'd more expect "here is a script" at some point once they really tried it one. But then desktop and scripts .. :-/
14:46 <didrocks> you have my feeling, but I’m not going to block on this further
14:46 <cpaelzer> My biggest question (and I have no idea yet) is - I feel they really try, but what would we need to feel confident that the effort to get this to be testable not stops once promotion happened
14:46 <sarnold> my concern is that some day we may need to do an update for a security issue, put in time and effort and then be faced with a dilemma: release an update we can't even smoke test or not provide the update at all
14:46 <cpaelzer> Eventually they will own the pain, we have forced them to work on reducing the pain
14:47 <cpaelzer> but indeed other teams like the one of sarnold will share the pain not being guilty of cuasing it in the first place
14:47 <didrocks> (who will remember a test is in a bug with a fixed released status?)
14:47 <cpaelzer> nobody will, it depends on how much really happens as a consequence of "ut we are working on trying to resolve the situation"
14:48 <didrocks> agreed
14:48 <cpaelzer> so will there be a testflinger device early 2023 that sarnold could also use and a doc how to test
14:48 <cpaelzer> yes => gerat
14:48 <cpaelzer> no => not so great
14:48 <cpaelzer> the question is how long do we block on it
14:48 <cpaelzer> as I said I have no great idea yet how to gain this last little bit of confidence
14:48 <cpaelzer> the team (desktop in this case) can sign up for their own pain
14:49 <cpaelzer> but as said above, how about security
14:49 <cpaelzer> sarnold: have you ever done deals like "I'm ok, but until you have FOO you need to do security yourself" or such?
14:49 <sarnold> me neither; we can of course lean on the desktop team in the event it becomes necessary
14:49 <cpaelzer> that sounds like what I asked for
14:49 <sarnold> cpaelzer: it reminds me a bit of the golang vendoring conversations..
14:50 <cpaelzer> yep
14:50 <didrocks> good point
14:50 <sarnold> and unity scopes didn't go great..
14:50 <cpaelzer> you might add that as a comment, like "Thanks for driving towards testability, but until HW and process is available for test and verification be aware that security efforts will need you to assist them"
14:50 <didrocks> like, I’m tracking security update for my owned vendored code (thanks dependabot!) and doing the SRUs myself because that was my decision to vendor code
14:50 <sarnold> very helpful bot :) it sent me an email this morning! :)
14:51 <didrocks> see, how pleasing :p
14:51 <cpaelzer> yep
14:51 <cpaelzer> we also act on pings for e.g. our rocks images - similar situations
14:51 <sarnold> chances are pretty good this thing won't need a security update in the short term
14:51 <sarnold> so gambling on it now is liable to have mostly upsides
14:51 <cpaelzer> ok, if you add something liek the comment above sarnold - then I think we can ack them under the aforementioned conditions
14:52 <sarnold> but the job of a security person is to be pessimistic most of the time. so .. I'd really like to help move things forward, but really want our concerns to be known ahead of time, that we may need someone else's time, a lot of it, at a very inconvenient time
14:53 <cpaelzer> agreed
14:53 <cpaelzer> and we understand that pessimism is from lessons-leaned :-)
14:53 <sarnold> I'll add such a comment to the bug later today, I think we can move on?
14:54 <cpaelzer> yes
14:54 <cpaelzer> thanks
14:54 <sarnold> #topic MIR related Security Review Queue
14:54 <sarnold> Mission: Check on progress, do deadlines seem doable?
14:54 <sarnold> #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:54 <sarnold> Internal link
14:54 <sarnold> - ensure your teams items are prioritized among each other as you'd expect
14:54 <sarnold> - ensure community requests do not get stomped by teams calling for favors too much
14:54 <sarnold> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
14:54 <cpaelzer> I'm biting my nails waiting for mdevctl, seeing you set the status to working this morning made me happy
14:55 <sarnold> heh, that was part of our mir priorities meeting, I noticed belatedly that I never moved the jira status :(
14:55 <cpaelzer> Do you have any uplifting interim info on that sarnold?
14:55 <sarnold> but the good news of that is that I had started on it ages back..
14:55 <didrocks> (unsure how "good" this is sounding, like many problems ahead? :p)
14:55 <cpaelzer> hehe
14:55 <sarnold> cpaelzer: on the one hand, it feels like a very low risk thing -- moving a shell script, any shell script, intended for admin use, to a rust program, is more or less always going to be an improvement :)
14:55 <cpaelzer> yep
14:56 <sarnold> on the other hand I feel like I owe it to my colleagues to try doing some dry-run updates on it -- a small patch to a vendored dep, and lifting a vendored dep to a new version
14:56 <cpaelzer> as I brought it up initially - a great example for discussing rust rules, but actually a good case
14:56 <cpaelzer> sarnold: as long as time does not run out, do what you have to
14:57 <cpaelzer> athos: will be around for questions if you have any
14:57 <sarnold> woot!
14:57 <cpaelzer> but due to time running out, could we have that completed either way until this meeting next week?
14:57 <sarnold> it's kind of mixed as rust code goes; it's hard for me to articulate, since I'm not myself *good* at rust, but it sure reads like someone's *first* rust project
14:57 <cpaelzer> I'd not want to cross with the release team too much in the last week promoting this
14:57 <sarnold> yeah, we've already given them reason to be cranky recently.. heh
14:57 <cpaelzer> sarnold: but still, better thna shell I guess
14:57 <sarnold> but yes, I think that's entirely plausible
14:58 <sarnold> cpaelzer: *yes*
14:58 <cpaelzer> ok, looking for next week then
14:58 <sarnold> even rough rust feels like a huge improvement over the best shell
14:58 <cpaelzer> nothing else concerning in those lists
14:58 <cpaelzer> move on?
14:58 <sarnold> Internal link
14:58 <sarnold> - ensure your teams items are prioritized among each other as you'd expect
14:58 <sarnold> - ensure community requests do not get stomped by teams calling for favors too much
14:58 <sarnold> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
14:58 <sarnold> nullboot is still sadly neglected
14:58 <sarnold> editorconfig-core is still slightly blocked on my concerns that it's handing untrusted regex inputs directly to pcre
14:59 <sarnold> mark has been working on that, and his priorities shift wildly
14:59 <athos> :)
14:59 <sarnold> and fdk-aac appears to be pleasingly low priority and filed early for next cycle :D
15:00 <sarnold> #topic Any other business?
15:00 <cpaelzer> nothing from me
15:00 <sarnold> hmm, looks like we lost the meeting bot
15:00 <didrocks> nothing either
15:00 <sarnold> or .. maybe it doesn't do anything? heh
15:01 <sarnold> nothing from me, anyway :)
15:01 <sarnold> okay then, without further peeps..
15:01 <sarnold> #endmeeting