[14:30] <cpaelzer> OMW, just a sec
[14:31] <slyon> \o
[14:31] <didrocks> o/
[14:32] <sarnold> good morning
[14:33] <cpaelzer> #startmeeting Weekly Main Inclusion Requests status
[14:33] <meetingology> Meeting started at 14:33:22 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[14:33] <meetingology> Available commands: action, commands, idea, info, link, nick
[14:33] <cpaelzer> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage
[14:33] <cpaelzer> hello MIR party people
[14:33] <cpaelzer> a few have already said hello before I started the logging, so we can start right away
[14:34] <cpaelzer> #topic current component mismatches
[14:34] <cpaelzer> Mission: Identify required actions and spread the load among the teams
[14:34] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[14:34] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[14:34] <cpaelzer> nothing new in non-proposed
[14:34] <slyon> nothing new AFAICT.
[14:34] <slyon> is python-jsonschema already handled?
[14:34] <cpaelzer> lintian continue trying to grow the biggest possible tree :-)
[14:35] <slyon> wrt. lintian graham started the work on the debian-perl MIRs and i'm currently working with olivier to resolve the libregexp-wildcards autopkgtest
[14:35] <cpaelzer> slyon: last week jamespage said he will have a look
[14:35] <slyon> the discussion with the Debian mantainer was negative, so we'll stick with libregexp-wildcards-perl
[14:35] <slyon> ok
[14:35] <cpaelzer> ok wildcards it will be
[14:36] <cpaelzer> then IIRC just add the automated perl autopkgtest
[14:36] <cpaelzer> and it should be ready to go
[14:36] <slyon> ack
[14:36] <sarnold> I lost scrollback so I'm not sure if we've discussed python-jsonschema and its children or not
[14:36] <cpaelzer> jamespage: coreycb: we will continue to leave python-jsonschema  -> webcolors / rfc3987 to you then
[14:36] <cpaelzer> sarnold: yes jamespage said he'll take a look
[14:36] <sarnold> \o/
[14:36] <cpaelzer> might as well be ongoing already without us being aware of details
[14:36] <cpaelzer> next ...
[14:37] <cpaelzer> #topic New MIRs
[14:37] <cpaelzer> Mission: ensure to assign all incoming reviews for fast processing
[14:37] <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:37] <cpaelzer> wpe ... again?
[14:37] <sarnold> finished :D
[14:37] <cpaelzer> oh back from security - nice
[14:37] <cpaelzer> let us checkt he right next state
[14:38] <slyon> nice, double ACK
[14:38] <cpaelzer> both got a security ack
[14:38] <coreycb> cpaelzer: are those in excuses?
[14:38] <cpaelzer> coreycb: they are in https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[14:38] <cpaelzer> so they should as well be in excuses I guess
[14:38] <coreycb> thanks
[14:39] <cpaelzer> hmm
[14:39] <cpaelzer> they are not
[14:39] <cpaelzer> odd
[14:39] <cpaelzer> coreycb: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-jsonschema
[14:40] <sarnold> so, should we change both from new -> in progress? or is there a better next step?
[14:40] <cpaelzer> bunch of test issues still
[14:40] <slyon> sarnold: yes. In progress would be the correct status
[14:40] <coreycb> I was working through jsonschema issues with sahara yesterday so maybe similar
[14:40] <cpaelzer> yes coreycb
[14:40] <slyon> for the desktop team to pull the trigger and upload the change that pulls it into main
[14:40] <cpaelzer> ok back to wpe then
[14:41] <cpaelzer> both mostly missed tests
[14:41] <cpaelzer> which got flagged as recommended todo
[14:41] <cpaelzer> Desktop team has filed upstream bugs to add tests in the first place
[14:41] <didrocks> which is an issue with a lot of desktop packages TBH, upstream lack testing spirit
[14:41] <cpaelzer> and tests it (once merged) as part of high level tests where this lib is used
[14:42] <cpaelzer> so I guess this is actually ready for promotion if the team has subscribed already
[14:43] <didrocks> no team subscription, but I think we can let seb128 who will probably handle the promotion, doing both
[14:43] <slyon> should we assign it to seb then?
[14:43] <didrocks> yeah, that would make sense
[14:44] <cpaelzer> I have done so
[14:44] <cpaelzer> and added a clarifying update
[14:44] <cpaelzer> thereby new bugs are depleted
[14:44] <cpaelzer> going on
[14:44] <cpaelzer> #topic Incomplete bugs / questions
[14:44] <cpaelzer> Mission: Identify required actions and spread the load among the teams
[14:44] <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:44] <cpaelzer> wildcards we already mentioned above
[14:45] <slyon> vulkan-tools got a security NACK
[14:45] <cpaelzer> see it
[14:45] <cpaelzer> interesting
[14:45] <cpaelzer> not seen one in a while
[14:45] <cpaelzer> I'll read that later once (if?) I have time
[14:46] <cpaelzer> all other updates are older - or is the lintian -*-perl one new still ...
[14:46] <didrocks> seems it’s really on the lack of maintainance
[14:46] <slyon> no, lintian -*-perl just got a tracking update
[14:46] <cpaelzer> no update substantial in the lintian*perl bug
[14:47] <cpaelzer> #topic MIR related Security Review Queue
[14:47] <cpaelzer> Mission: Check on progress, do deadlines seem doable?
[14:47] <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:47] <cpaelzer> Internal link
[14:47] <cpaelzer> - ensure your teams items are prioritized among each other as you'd expect
[14:47] <cpaelzer> - ensure community requests do not get stomped by teams calling for favors too much
[14:47] <cpaelzer> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
[14:47] <cpaelzer> sarnold: I need https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1942394 in that board to prioritize it
[14:47] <slyon> cpaelzer: actually the vulkan NACK seems to be for Bionic only
[14:47] <sarnold> cpaelzer: ack!
[14:47] <slyon> others are still TDB
[14:48] <cpaelzer> slyon: yeah, but that is fine
[14:48] <cpaelzer> slyon: (for here) we only need to identify things we can and should act on
[14:48] <slyon> okay
[14:48] <slyon> so that's back to your team to decide how to proceed
[14:48] <cpaelzer> slyon: vulkan you mean - yeah
[14:48] <slyon> yes
[14:48] <cpaelzer> sarnold: that is the outcome of all our rust talk
[14:48] <sarnold> cpaelzer: https://warthogs.atlassian.net/browse/SEC-1214
[14:49] <cpaelzer> sarnold: it was given an ok on the MIR review, we work on the recommended TODOs already
[14:49] <cpaelzer> thanks
[14:49] <cpaelzer> bumped and commented
[14:50] <sarnold> unfortunately, chrisccoulson wasn't able to get to nullboot before he went on PTO, it'll be a while before that one can get some traction
[14:50] <cpaelzer> we have ~3 weeks to feature freeze
[14:50] <cpaelzer> if you see any of those tagged for FF being expected to be a miss could you let us know next week
[14:50] <sarnold> but iwd, ell, wpe*, have made progress; vulkan-tools NAK, ipmitool is very nearly done (NAK)
[14:50] <cpaelzer> then we can file FFE bugs for them
[14:51] <cpaelzer> and in general - I really do see and appreciate the steady security review progress nowadays
[14:51] <sarnold> amazing how time flies :( yeah, sounds like a good idea
[14:51] <cpaelzer> \o/
[14:51] <cpaelzer> ok next is AOB
[14:51] <cpaelzer> #topic Any other business?
[14:51] <cpaelzer> #endmeeting
[14:51] <meetingology> Meeting ended at 14:51:42 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-08-02-14.33.moin.txt
[14:51] <cpaelzer> wow
[14:51] <sarnold> heh
[14:51] <cpaelzer> that was too much copy and paste
[14:51] <sarnold> eager to head out? :)
[14:51] <cpaelzer> tell me you have a topic and I'll re-open another one
[14:52] <didrocks> no business allowed :)
[14:52] <sarnold> I actually do ..
[14:52] <didrocks> nothing for me
[14:52] <slyon> haha, nothing from my side
[14:52] <cpaelzer> nothing for me either
[14:52] <cpaelzer> ok and jamespage + joalif are not around today
[14:52] <cpaelzer> well then I'm lucky with my mistake
[14:52] <cpaelzer> enjoy your days please!
[14:52] <slyon> no wait,
[14:52] <cpaelzer> arre
[14:52] <slyon> sarnold: had something
[14:52] <sarnold> I'd like to plant the seed of an idea if there'd be gains in replacing the giant flowchart/state diagram of doom with something more like the kernel team SRU workflow
[14:52]  * didrocks notices cpaelzer ignores sarnold
[14:52] <cpaelzer> too much scrolling here
[14:52] <sarnold> here's a nice example bug https://bugs.launchpad.net/kernel-sru-workflow/+bug/1983335
[14:52] <didrocks> maybe this is way the meeting was closed prematurely :p
[14:52] <cpaelzer> #startmeeting Weekly Main Inclusion Requests status - bonus
[14:52] <meetingology> Meeting started at 14:52:55 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[14:52] <meetingology> Available commands: action, commands, idea, info, link, nick
[14:53] <sarnold> I'd like to plant the seed of an idea if there'd be gains in replacing the giant flowchart/state diagram of doom with something more like the kernel team SRU workflow
[14:53] <sarnold> here's a nice example bug https://bugs.launchpad.net/kernel-sru-workflow/+bug/1983335
[14:53] <cpaelzer> I missed an "Any other business"
[14:53] <cpaelzer> #topic Any other business?
[14:53] <sarnold> with the different phases of the review spelled out, individuals or teams assigned to each, status indicators on each..
[14:53] <didrocks> oh, basically, all stages in the bug targets?
[14:54] <cpaelzer> has anybody been in volved in creating this and can advise us?
[14:54] <slyon> would be more of a linear process
[14:54] <sarnold> I think it'd complicate things like bionic vulkan-tools, but I think it would have other simplifying efforts
[14:54] <cpaelzer> mutli-release reviews would become multiple bugs
[14:54] <sarnold> but the transition effort might cost more than any of us can afford
[14:54] <didrocks> yeah, I wonder how unlinear would work out, see if we can serialize that to a stack rollbacking to top if needed with higher priority
[14:54] <cpaelzer> which is ok as we mostly review one and then sub-check differences for the others
[14:54] <sarnold> and multi-package reviews might be harder to organize
[14:55] <slyon> right, like all the *-perl packages which we can squash into a single bug
[14:55] <sarnold> we in the security team were working on prepping some metrics and just finding it hard to *count* how many mirs in what states we had..
[14:55] <sarnold> iirc what we had to do launchpad scraping took an hour to execute every week
[14:55] <slyon> but those are still handled individually, so having a separat bug for each of them should still be manageable
[14:55] <cpaelzer> sarnold: and you tihnk counting would be better with this?
[14:56] <cpaelzer> the scraping I mean
[14:56] <sarnold> cpaelzer: well, it's hard to say; in the end we decided to scrap our launchpad scraping and move to jira, but, uh, we found earlier today that relying upon jira isn't without flaws too
[14:56] <cpaelzer> this sounds like workflow optimization which is a thing
[14:57] <cpaelzer> but most likely not our task or duty
[14:57] <sarnold> perhaps, but it is something most of us touch
[14:57] <sarnold> and making the things we touch often a bit nicer has rewards :)
[14:57] <cpaelzer> there might be new work to describe and process workflows, which then I think would provide the stage to renew
[14:57] <sarnold> whether or not this is nicer is another question
[14:57] <cpaelzer> sarnold: I think it comes down to someone finding the time to make a POC on launchpad to show it
[14:58] <sarnold> ah, good point. I hadn't considered that approach, heh
[14:58] <cpaelzer> which I think starts with findin who did it in kernel
[14:58] <cpaelzer> I guess it can all be LP API
[14:58] <cpaelzer> when we consume a new MIR we'd run a tool which adds the stages
[14:58] <cpaelzer> and then assign the review as one stage
[14:59] <cpaelzer> I'm open to discuss/check such a POC but currently consider myself unable to create it
[14:59] <cpaelzer> thanks for birnging the idea up though
[14:59] <cpaelzer> it seems interesting indeed
[14:59] <cpaelzer> having a hard stop now
[14:59] <sarnold> thanks :D
[14:59] <cpaelzer> any other other business?
[14:59] <sarnold> that's it
[14:59] <slyon> nope
[14:59] <didrocks> nothing else
[14:59] <cpaelzer> ok
[14:59] <cpaelzer> then again
[14:59] <cpaelzer> #endmeeting
[14:59] <meetingology> Meeting ended at 14:59:56 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-08-02-14.52.moin.txt
[15:00] <cpaelzer> thank you all
[15:00] <didrocks> thanks!
[15:00] <slyon> thanks cpaelzer, all!
[15:00] <sarnold> thanks cpaelzer, all :)
[19:00]  * vorlon waves
[19:00] <rbasak> o/
[19:01] <vorlon> good news, everyone! I'm finally logged into the wiki!
[19:01] <vorlon> (though afaik the root issue is still not fixed)
[19:05] <vorlon> waiting to start the meeting until we have quorum
[19:10] <vorlon> rbasak: anything you want to discuss off-book?
[19:13] <rbasak> We need to handle the "New Official Flavor Process Issues" thread
[19:15] <vorlon> from 1-on-1 conversation it sounded like you were planning to take a stab at the revisions, is that correct?
[19:16] <vorlon> fwiw while I can see room for improvement in the doc in terms of ordering / structure of the sections so it's easier to follow, I have a difficult time fulfilling Eickmeyer's request for a "step-by-step" process doc because most of these things can and should happen in parallel
[19:17] <rbasak> I don't think I'm qualified to go into the specifics. But it seems to me that this is mainly a mismatch of expectations rather than really a lack of documentation. Particularly because a new flavor is such a rare event, realistically I think the docs will always be out of date.
[19:17] <rbasak> Instead, I think we need to focus on communication. So the key thing is to document that potential flavors should get in touch.
[19:17] <rbasak> And outline how that is to be done.
[19:18] <rbasak> It sounded like Erich would be OK with this.
[19:18] <vorlon> ok
[19:19] <rbasak> Of course we should improve the docs when we have specific things that obviously should be fixed.
[19:19] <vorlon> you still good to take the first pass at that?
[19:19] <rbasak> Sure.
[19:20] <vorlon> thanks
[19:20] <vorlon> anything else?  otherwise since we're not looking quorate I'm going to go work on an ubuntu-release-upgrader SRU
[19:22] <rbasak> I continue to work on the third party repository task.
[19:22] <rbasak> I don't think there's anything else. Thanks!
[19:22] <vorlon> thank you!