[14:30] <cpaelzer> hello
[14:30] <cpaelzer> #startmeeting Weekly Main Inclusion Requests status
[14:30] <meetingology> Meeting started at 14:30:46 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[14:30] <meetingology> Available commands: action, commands, idea, info, link, nick
[14:30] <cpaelzer> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe )
[14:30] <slyon> o/
[14:30] <cpaelzer> Not sure if everyone made it back from the sprint yet
[14:31] <eslerm> good morning o/
[14:31] <dviererbe> Hello o/
[14:31] <cpaelzer> but in case you did - hello o/
[14:31] <jbicha> hi, I'll be filing the MIRs related to transmission soon
[14:31] <cpaelzer> ok, good to know ahead of time jbicha
[14:31] <cpaelzer> let us see if syncs brought us something already
[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:31] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[14:32] <cpaelzer> transmission (as mentioned by jbicha)
[14:32] <cpaelzer> jaraco.text was there last cycle and is still on openstack
[14:32] <slyon> policykit-1 -> duktape seems known (didn't we resolve that in the past?
[14:32] <joalif> o/
[14:32] <cpaelzer> jamespage: in case you read this now or later, what is the mantic minotaur plan for dependencies of jaraco ?
[14:32] <didrocks> hello
[14:32] <cpaelzer> oh, one more thing
[14:32] <cpaelzer> I have went backwards on duktape IIRC
[14:33] <cpaelzer> it is still seen in component mismatch proposed right now
[14:33] <cpaelzer> I guess that is meant to land soo, was that ready - if not what was yet open?
[14:33] <jamespage> cpaelzer: unsure - I need to sync with coreycb and the ubuntu-ceph team to figure that out
[14:33] <cpaelzer> ok jamespage, do that and get back to us
[14:33] <jamespage> but I'll find out and return with news...
[14:33] <cpaelzer> I just want to avoid it hangs in mismatches for many more months
[14:33] <jamespage> yep me too
[14:34] <jbicha> cpaelzer: I believe Desktop still has a required autopkgtest TODO for duktape
[14:34] <cpaelzer> yes, there were some open tasks
[14:35] <cpaelzer> that very much could be one
[14:35] <cpaelzer> jbicha: do you know if that task of getting it ready is on the roadmap or anyones desk?
[14:35] <slyon> So I think duktape should be marked "Incomplete" to reflect that?
[14:35] <cpaelzer> It was incomplete after my review
[14:35] <jbicha> cpaelzer: duktape is on Desktop's roadmap to try to get done within the next few weeks
[14:35] <cpaelzer> went to security
[14:36] <cpaelzer> and they marked it "ok" after their ack
[14:36] <cpaelzer> incomplete is indeed the right status, thanks for suggesting slyon
[14:36] <cpaelzer> thanks jbicha, so in some near future Desktop will come back , call it ready, we will look again and then it can move
[14:36] <cpaelzer> sounds reasonable
[14:36] <jbicha> 👍
[14:38] <cpaelzer> status fixed
[14:38] <slyon> thx!
[14:38] <cpaelzer> ok, next
[14:38] <cpaelzer> #topic New MIRs
[14:38] <cpaelzer> Mission: ensure to assign all incoming reviews for fast processing
[14:38] <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:39] <cpaelzer> nothing there yet
[14:39] <cpaelzer> next
[14:39] <cpaelzer> #topic Incomplete bugs / questions
[14:39] <cpaelzer> Mission: Identify required actions and spread the load among the teams
[14:39] <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:39] <cpaelzer> no recent updates
[14:39] <cpaelzer> the sprint and recent release made things rather easy :-)
[14:40] <cpaelzer> #topic Process/Documentation improvements
[14:40] <cpaelzer> Mission: Review pending process/documentation pull-requests or issues
[14:40] <cpaelzer> #link https://github.com/canonical/ubuntu-mir/pulls
[14:40] <cpaelzer> #link https://github.com/canonical/ubuntu-mir/issues
[14:40] <cpaelzer> We have my PR, but I'd postpone that to the AOB section at the end
[14:40] <cpaelzer> it is meant to trigger discussion and bikeshedding, that asks for the open-end section of the meeting
[14:40] <cpaelzer> #topic MIR related Security Review Queue
[14:40] <cpaelzer> Mission: Check on progress, do deadlines seem doable?
[14:40] <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:40] <cpaelzer> Internal link
[14:40] <cpaelzer> - ensure your teams items are prioritized among each other as you'd expect
[14:41] <cpaelzer> - ensure community requests do not get stomped by teams calling for favors too much
[14:41] <cpaelzer> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
[14:41] <cpaelzer> We have discussed about them just before the sprint
[14:41] <cpaelzer> a few things in there, related to cargo and heif
[14:41] <slyon> (where cargo should be high priority and heif best effort)
[14:41] <cpaelzer> I haven't seen sarnold or eslerm today to ask about openscap/smartcards if they got new focus
[14:41] <cpaelzer> slyon: that prio isn't reflected
[14:41] <cpaelzer> but we can fix it up
[14:42] <eslerm> cargo discussion at the sprint was productive, unblocked our dependency concerns
[14:42] <cpaelzer> libgit2 was related to cargo right?
[14:42] <slyon> cpaelzer: yes, so is http-parser
[14:42] <slyon> I've set those to "high" priority on the board
[14:42] <eslerm> iirc, smartcards were removed a cycle or two ago since desktop was no longer owning them
[14:43] <cpaelzer> I see the "high" so year, you are good
[14:43] <cpaelzer> sorry for the noise
[14:43] <eslerm> previously, we needed hardware for testing and at least one package needed significant work
[14:43] <cpaelzer> eslerm: ok, so no comeback of them yet
[14:43] <cpaelzer> thanks
[14:43] <eslerm> yes, unless desktop wants them
[14:43] <cpaelzer> yep
[14:43] <cpaelzer> #topic Any other business?
[14:43] <eslerm> it would be nice to support them
[14:44] <cpaelzer> from me, get the discussion on https://github.com/canonical/ubuntu-mir/pull/17 going
[14:44] -ubottu:#ubuntu-meeting- Pull 17 in canonical/ubuntu-mir "add re-reviews to the MIR process" [Open]
[14:44] <didrocks> thanks for tackling this cpaelzer!
[14:44] <eslerm> ^
[14:44] <slyon> +1!
[14:44] <cpaelzer> yw, it isn't perfect but a start
[14:44] <cpaelzer> Question #1 I have is on preference of how to express the rules
[14:45] <cpaelzer> right now I have copied the template and modified it
[14:45] <cpaelzer> pro: readable
[14:45] <cpaelzer> con: duplication / redundancy
[14:45] <slyon> I suggested to add an asterisk (*) to the TODOs/sections that are needed for re-review
[14:45] <cpaelzer> would you rather prefer to merge the "re-review" with the "review" template and flag them somehow?
[14:45] <slyon> I'm afraid the templates will diverge if handled separately
[14:45] <eslerm> imo, clarity justifies redundancy
[14:45] <didrocks> +1 on slyon's proposal
[14:46] <cpaelzer> +1 on slyon's suggestion - at least let me do that and then we can have a look
[14:46] <cpaelzer> I haven't seen that yet
[14:46] <slyon> the asterisk shouldn't affect clarity too much and we can give a nice explanation about the * below the template
[14:46] <dviererbe> I think a copy would be fine, because the template is much more often copied that edited, but I also like the * Idea
[14:46] <cpaelzer> We already filter out the RULE: sections
[14:46] <eslerm> slyon: that makes sense
[14:46] <cpaelzer> I think the same way we can restrict to only or without those
[14:46] <cpaelzer> one question though
[14:47] <cpaelzer> there are things which "ONLY" apply to re-review
[14:47] <cpaelzer> would you be ok with "*** TODO: ..." for those?
[14:47] <slyon> "Then potentially having a new [Re-review*] section below for stuff that's only relevant for re-reviews. And giving an explanation about the * below, too (as usual)."
[14:47] <cpaelzer> oh that is nice
[14:47] <didrocks> but those are the exceptions, correct? I guess a dedicated marker is fine
[14:47] <cpaelzer> thanks for having better ideas on the layout
[14:47] <cpaelzer> ok, I'll overhaul with that in mind for next week
[14:48] <cpaelzer> dviererbe: I've seen your question as well
[14:48] <cpaelzer> dviererbe: it is meant to be a continuous effort
[14:48] <cpaelzer> dviererbe: but no high hopes please
[14:48] <dviererbe> thanks sylon also answered that in the github isue
[14:48] <cpaelzer> dviererbe: the amount we can do is <<< things in main
[14:48] <cpaelzer> so it will be slow
[14:49] <cpaelzer> ok, the TL;DR is
[14:49] <cpaelzer> 1. you are all generally +1 as you love Ubuntu with quality as much as I do
[14:49] <cpaelzer> 2. I'll integrate all your good feedback
[14:49] <cpaelzer> 3. I'll reset this PR to needs review
[14:49] <cpaelzer> from there we can work on GH and talk again here next week
[14:49] <cpaelzer> that is ok for me for today
[14:49] <slyon> sounds great, thanks!
[14:50] <didrocks> sounds good :)
[14:50] <joalif> sounds good :)
[14:50] <eslerm> thanks cpaelzer
[14:50] <dviererbe> thanks for all the work!
[14:50] <cpaelzer> ok, there was nothing else
[14:50] <cpaelzer> closing this ....
[14:50] <cpaelzer> thank you all!
[14:50] <eslerm> o/
[14:50] <cpaelzer> #endmeeting
[14:50] <meetingology> Meeting ended at 14:50:27 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-05-09-14.30.moin.txt
[14:50] <didrocks> thanks!
[14:50] <joalif> thanks cpaelzer all :)