[14:32] good morning [14:32] hey sarnold [14:32] cpaelzer: joalif: jamespage: around by any chance? [14:33] ok, let’s co-host the meeting and go over the list sarnold and I :) [14:33] then people can join [14:34] #startmeeting Weekly Main Inclusion Requests status [14:34] Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage [14:34] Meeting started at 14:34:00 UTC. The chair is sarnold. Information about MeetBot at https://wiki.ubuntu.com/meetingology [14:34] Available commands: action, commands, idea, info, link, nick [14:34] #topic current component mismatches [14:34] Mission: Identify required actions and spread the load among the teams [14:34] #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [14:34] #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg [14:34] o/ [14:34] sarnold was quicker than I getting the wiki page :) [14:34] lintian was false-positive, IIRC? [14:34] hey jamespage, didrocks :) [14:35] esmtp too [14:35] sorry, late [14:35] hey jamespage, cpaelzer [14:35] hey cpaelzer :) [14:35] sounds like we are ok on c-m-p and c-m? [14:35] reading backlog and thanks sarnold for driving [14:36] yeah, I think they look good \o/ [14:36] #topic New MIRs [14:36] Mission: ensure to assign all incoming reviews for fast processing [14:36] #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] ah, there has been some updates on tune, let’s look [14:37] ok we got an explanation on tuned [14:37] tuna was removed for now [14:37] do we have all answers we waited for now? [14:37] we also got the separataiton from tlp/gamemode [14:37] sorry for all the wrong extra characters above :-/ [14:38] oh very nice, that's a good explanation of unique and new features [14:38] indeed [14:38] yeah, no feedback on the lack of automated tests though [14:38] but I can have a look at do the usual MIR review [14:38] so "new version" and "add tests" will be requirements of the review by didrocks I guess [14:38] buth we can go on [14:38] ah nice :) [14:38] -h [14:39] ah sorry, misread you [14:39] ok, so do we agree that this can go back to "new + assigned to didrocks" ? [14:39] thought the new version was adding tests :) [14:39] yeah [14:39] doing so [14:39] no not yet, sorry [14:39] but it will have to some day before this completes [14:39] ok, bug status updated [14:39] okay, so what steps are we expecting Joseph to take before didrocks starts in on it? [14:40] I think none [14:40] I’m starting in parallel [14:40] and wrote about lack of tests/new version again: https://bugs.launchpad.net/ubuntu/+source/tuned/+bug/1988066/comments/11 [14:40] we can let him know that autopkgtests and a version update will be requirements of the reivew result [14:40] Launchpad bug 1988066 in tuned (Ubuntu Jammy) "[MIR] tuned" [High, Confirmed] [14:41] so that we hopefully won’t block on it [14:41] great! nice comment [14:41] ack [14:41] #topic Incomplete bugs / questions [14:41] Mission: Identify required actions and spread the load among the teams [14:41] #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] I mentioned ccid and others last week [14:42] the ccid and related is sadly just ray finding greening pastures :( [14:42] we know they are postponed for now [14:42] libqrtr-glib is a challenging case, for discussion in prague, I think? [14:42] did anyone read through the updated test plan? [14:43] looks like it’s directly in the bug description [14:43] with "Our Desktop and oem teams don't have access to compatible hardware at the moment to go through the testplan. [14:43] " [14:43] which is fine [14:43] so I feel this is a reasonable update [14:43] we got as much as they can do, and they are willing to continue working with other teams to improve the situation [14:44] do we think that a testplan on a bug report is going to be useful later in time? [14:44] I feel it will go into $launchpad_limbo [14:44] at least, on the wiki, it’s a better place, no? [14:45] 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] you have my feeling, but I’m not going to block on this further [14:46] 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] 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] Eventually they will own the pain, we have forced them to work on reducing the pain [14:47] 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] (who will remember a test is in a bug with a fixed released status?) [14:47] 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] agreed [14:48] so will there be a testflinger device early 2023 that sarnold could also use and a doc how to test [14:48] yes => gerat [14:48] no => not so great [14:48] the question is how long do we block on it [14:48] as I said I have no great idea yet how to gain this last little bit of confidence [14:48] the team (desktop in this case) can sign up for their own pain [14:49] but as said above, how about security [14:49] 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] me neither; we can of course lean on the desktop team in the event it becomes necessary [14:49] that sounds like what I asked for [14:49] cpaelzer: it reminds me a bit of the golang vendoring conversations.. [14:50] yep [14:50] good point [14:50] and unity scopes didn't go great.. [14:50] 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] 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] very helpful bot :) it sent me an email this morning! :) [14:51] see, how pleasing :p [14:51] yep [14:51] we also act on pings for e.g. our rocks images - similar situations [14:51] chances are pretty good this thing won't need a security update in the short term [14:51] so gambling on it now is liable to have mostly upsides [14:51] ok, if you add something liek the comment above sarnold - then I think we can ack them under the aforementioned conditions [14:52] 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] agreed [14:53] and we understand that pessimism is from lessons-leaned :-) [14:53] I'll add such a comment to the bug later today, I think we can move on? [14:54] yes [14:54] thanks [14:54] #topic MIR related Security Review Queue [14:54] Mission: Check on progress, do deadlines seem doable? [14:54] #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] Internal link [14:54] - ensure your teams items are prioritized among each other as you'd expect [14:54] - ensure community requests do not get stomped by teams calling for favors too much [14:54] #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 [14:54] I'm biting my nails waiting for mdevctl, seeing you set the status to working this morning made me happy [14:55] heh, that was part of our mir priorities meeting, I noticed belatedly that I never moved the jira status :( [14:55] Do you have any uplifting interim info on that sarnold? [14:55] but the good news of that is that I had started on it ages back.. [14:55] (unsure how "good" this is sounding, like many problems ahead? :p) [14:55] hehe [14:55] 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] yep [14:56] 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] as I brought it up initially - a great example for discussing rust rules, but actually a good case [14:56] sarnold: as long as time does not run out, do what you have to [14:57] athos: will be around for questions if you have any [14:57] woot! [14:57] but due to time running out, could we have that completed either way until this meeting next week? [14:57] 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] I'd not want to cross with the release team too much in the last week promoting this [14:57] yeah, we've already given them reason to be cranky recently.. heh [14:57] sarnold: but still, better thna shell I guess [14:57] but yes, I think that's entirely plausible [14:58] cpaelzer: *yes* [14:58] ok, looking for next week then [14:58] even rough rust feels like a huge improvement over the best shell [14:58] nothing else concerning in those lists [14:58] move on? [14:58] Internal link [14:58] - ensure your teams items are prioritized among each other as you'd expect [14:58] - ensure community requests do not get stomped by teams calling for favors too much [14:58] #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 [14:58] nullboot is still sadly neglected [14:58] editorconfig-core is still slightly blocked on my concerns that it's handing untrusted regex inputs directly to pcre [14:59] mark has been working on that, and his priorities shift wildly [14:59] :) [14:59] and fdk-aac appears to be pleasingly low priority and filed early for next cycle :D [15:00] #topic Any other business? [15:00] nothing from me [15:00] hmm, looks like we lost the meeting bot [15:00] nothing either [15:00] or .. maybe it doesn't do anything? heh [15:01] nothing from me, anyway :) [15:01] okay then, without further peeps.. [15:01] #endmeeting [15:01] Meeting ended at 15:01:41 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-09-20-14.34.moin.txt [15:01] thanks cpaelzer, didrocks :) [15:02] thank you all! [15:02] thanks sarnold for hosting, and all! [15:04] sarnold: Desktop was thinking about trying to bundle editorconfig-core in gnome-text-editor 43 (because it already exists in the current 42) [15:05] we wouldn't want to keep that for 23.04 but in case we run out of time now… [16:39] jbicha: yeah, it's not ideal :( but gnome-text-editor feels less likely to be part of a 'git clone http://github.com/evil/evil.git ; cd evil ; $EDITOR README' exploit chain