14:31 <cpaelzer> #startmeeting Weekly Main Inclusion Requests status
14:31 <meetingology> Meeting started at 14:31:50 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
14:31 <meetingology> Available commands: action, commands, idea, info, link, nick
14:31 <cpaelzer> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage
14:32 <didrocks> hey cpaelzer
14:32 <cpaelzer> #topic current component mismatches
14:32 <cpaelzer> Mission: Identify required actions and spread the load among the teams
14:32 <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
14:32 <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
14:32 <cpaelzer> nothing new in there
14:32 <cpaelzer> as I said, the last few calm weeks :-)
14:32 <slyon> o/
14:32 <cpaelzer> wb slyon
14:32 <cpaelzer> #topic New MIRs
14:32 <cpaelzer> Mission: ensure to assign all incoming reviews for fast processing
14:32 <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:33 <sarnold> good morning
14:33 <sarnold> oh my
14:33 <cpaelzer> so much for calm
14:33 <cpaelzer> but hey I've wanred about that a few weeks ago
14:34 <slyon> haha that's plenty of ruby MIRs
14:34 * didrocks removes his hand from the alarm button then
14:34 <cpaelzer> to be fair
14:34 <cpaelzer> it is a lot of very small usually easy packages
14:34 <sarnold> o/~ to be faaiir o/~
14:34 <cpaelzer> instead of a single super massive one
14:34 <cpaelzer> hehe
14:34 <cpaelzer> ok let us talk about the non-pcs one first
14:34 <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/libgit2/+bug/1990655
14:35 <didrocks> I haven’t noticed that slyon answered, the status is wrong though
14:35 <cpaelzer> that is the other known "there will be more" case by schopin
14:35 <didrocks> I need to have a reread and asses on libgit2, I will do that
14:35 <didrocks> (tomorrow probably)
14:35 <cpaelzer> ok, so I'll re-assign it to you for now didrocks
14:36 <cpaelzer> and depending on the outcome it goes to ack/nack/security next
14:36 <didrocks> yep
14:36 <cpaelzer> now around PCS
14:37 <cpaelzer> this was all meant to be doen in 22.10 but the dependency tree exploded on us
14:37 <cpaelzer> as you can see
14:37 <cpaelzer> I've asked to at least provide it very early for 23.04 because the item will move there
14:37 <cpaelzer> let us first distribute the "easy" ones - which are the 14 ruby-* cases
14:38 <cpaelzer> how about round robin them between the four of us being joalif didrocks slyon and myself ?
14:38 <joalif> yup
14:38 <cpaelzer> that would be 3 or 4 of them for each of us
14:38 <didrocks> yeah, please note I have another pending, failing to trying to get one assigned and no time for review
14:38 <didrocks> but at least, for those, before 23.04 opens, that should be doable
14:38 <cpaelzer> yep
14:38 <slyon> yes, though I might not be able to get all of them reviewed by next week.
14:39 <cpaelzer> hehe
14:39 <cpaelzer> that is totally fine
14:41 <cpaelzer> ok that set is done
14:41 <cpaelzer> you can reload the list now that the view is clearer
14:41 <sarnold> wow :)
14:41 <cpaelzer> we have pcs itself, two python* and "thin"
14:42 <cpaelzer> I guess in complecity this is (descending) pcs > tornado (but easier as it was in main before) > thin > dacite
14:42 <cpaelzer> this is again 4
14:42 <cpaelzer> one each?
14:42 <cpaelzer> any preference?
14:43 <cpaelzer> since I'm the manager of the team driving it I'd prefer not to do pcs itslef for political reasons
14:43 <cpaelzer> other thna that I'm happy on any of them
14:43 <slyon> OK, maybe something in the middle for me thin or tornado
14:43 <cpaelzer> ok tornado it will be
14:43 * didrocks picks randomly a python one, let’s take python3-dacite
14:44 <cpaelzer> joalif: are you ok to take PCS itself or does that make you cursing my name for the rest of the day?
14:44 <joalif> LOL
14:44 <joalif> cpaelzer: that's ok :)
14:44 <cpaelzer> to be clear - on this barrage no one expects a return of all next week
14:44 <cpaelzer> aim for 1-2 per week and we should be good
14:45 <didrocks> sounds good to me, let’s hope we don’t get the cargo stuff at the same time :)
14:46 <cpaelzer> we knew both will come
14:46 <cpaelzer> and one had to be earlier
14:46 <cpaelzer> if cargo comes next week it will just enqueue and still be ok
14:46 <cpaelzer> at the intended 1-2 per week that will still be very early in the 23.04 cycle
14:46 <didrocks> yes
14:46 <cpaelzer> and then sarnold knows his queue early on and can call for addition reviewers on security
14:46 <cpaelzer> #topic Incomplete bugs / questions
14:46 <cpaelzer> Mission: Identify required actions and spread the load among the teams
14:47 <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:47 <cpaelzer> libgit (we talked) and tuned (old)
14:47 <cpaelzer> nothing to discuss here IMHO
14:47 <didrocks> yeah, tuned still has no response…
14:47 <cpaelzer> oh well 27th Sept ??
14:47 <cpaelzer> yeah that was you incompleting it
14:47 <cpaelzer> ok
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:48 <cpaelzer> no surprises here
14:48 <cpaelzer> sarnold: now that the plan for 23.04 slowly gets real - how about those smartcard things there?
14:48 <cpaelzer> will they be back on the roadmap?
14:48 <sarnold> I don't think much was done in the last week; mark is workingo n putting together a fuzz test harness for editorconfig-core
14:49 <cpaelzer> was that after you tried to say no
14:49 <sarnold> cpaelzer: heh, that's a good question; I think we have a meeting on our agenda with desktop team to see if that's still desired
14:49 <cpaelzer> and then realized it is already in the archive (bundled)
14:49 <cpaelzer> sarnold: is that a breakout session on one of the sprints?
14:49 <sarnold> cpaelzer: it should eb, yeah, thanks for the reminder, I'll doublecheck it :)
14:50 <cpaelzer> sarnold: while checking (I couldn't find it) could you ask for my name to be added to the invitee list please?
14:50 <sarnold> it's not great for editorconfig to be bundled into one program, but at least that limits the scope of flaws to whoever runs that one program, not all the dozen editors that use it
14:50 <sarnold> will do!
14:50 <cpaelzer> thanks
14:50 <cpaelzer> and that is an interesting insight into potential benefits of bundled sources :-)
14:50 <sarnold> yes :)
14:50 <cpaelzer> oh we forgot
14:50 <cpaelzer> Internal link
14:51 <cpaelzer> - ensure your teams items are prioritized among each other as you'd expect
14:51 <cpaelzer> - ensure community requests do not get stomped by teams calling for favors too much
14:51 <cpaelzer> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
14:51 <cpaelzer> well I forgot
14:51 <cpaelzer> now we
14:52 <cpaelzer> ncie confusion
14:52 <cpaelzer> smartcard has a pcscd
14:52 <sarnold> yes :(
14:52 <cpaelzer> and we now entered pcs and pscd for HA
14:52 <cpaelzer> not to be mistaken for pcscd
14:52 <cpaelzer> arr
14:52 <cpaelzer> anyway, next agenda entry
14:52 <cpaelzer> #topic Any other business?
14:52 <sarnold> nothing here
14:52 <cpaelzer> none from me, except thanking you for spreading the pcs load
14:53 <didrocks> I have one
14:53 <slyon> didrocks: did you already have a chance to look into bug #1991508
14:53 <didrocks> so, I have not yet fully check for https://bugs.launchpad.net/bugs/1991508
14:53 <didrocks> slyon: this is what I told before, I haven’t the time to start it
14:53 <didrocks> however, this is another case of new hardware support
14:53 <slyon> I was asked by Foundations to push for this as it seems to be required to build usable LiceeRV 22.10 images for the release
14:53 <didrocks> with no test
14:54 <didrocks> slyon: well, TBH, that request should have got scheduled way before FF :)
14:54 <didrocks> so, there is no testplan either
14:54 <didrocks> (I find that a lot of MIRs are too easily filled without fulfilling any test requirement)
14:54 <didrocks> I feel that at least, someone has access to the hardware somewhere
14:54 <didrocks> and there should be a written testplan
14:54 <cpaelzer> It ends in the usual "this should at least be a compromise - what testing could you offer" sitation
14:54 <slyon> I think the hardware is available at my team mates... but it would require a manual test plan, right?
14:54 <didrocks> what do people think?
14:55 <cpaelzer> yes a manual test plan and proof that it is executable (e.g. a sample log) is much better than <nothing>
14:55 <didrocks> yeah, and I am a little bit unhappy TBH that it’s the 3rd MIR in a row where the testing requirement is simply discared
14:55 <didrocks> (not only Foundation, but cross team)
14:56 <didrocks> I’m wonder how we can emphasize "If you don’t say what’s your plan on this, this is not even something we are considering"
14:56 <cpaelzer> yep, but each time we got at least something out of insisting which is better than just doing nothing
14:56 <cpaelzer> ack on that didrocks
14:56 <cpaelzer> people should try to comply without us rejecting it first to force it
14:56 <didrocks> yeah, it’s just that maybe the test is no clear enough? Should we use bold/scary message on the template? :p
14:56 <slyon> ack on that, indeed
14:57 <cpaelzer> didrocks: I'm happy to make it more scary, but I do not have great words for it in cache atm
14:57 <sarnold> there is a comment in the description, "we commit to install and test this package for each new kernel that would be released, which is enough to make sure it still works"
14:57 <cpaelzer> whoever gets to it is welcomed to throw a PR at https://github.com/canonical/ubuntu-mir
14:57 <didrocks> sarnold: right, but this is not a testplan, written down
14:57 <sarnold> ahh
14:57 <didrocks> and what if the person writing this has this somewhere on his head and leave?
14:57 <didrocks> hence writing is better :)
14:58 <slyon> didrocks: do you see any chance this licheeRV MIR could be resolved ahread of release if a testplan is provided in a timely manner?
14:58 <slyon> (i.e. today/tomorrow?)
14:58 <cpaelzer> I mean what ar ewe trying to do here a) keep ubuntu great and b) ensure teams are not digging their own grave - I think it is helpful (and not mean) to be more explicit what/why a test plan is expected
14:58 <didrocks> slyon: as you are in touch with whoever is pushing this to write the testplan? I still hope to be able to review it in parallel before EOW
14:58 <didrocks> I can’t commit for today/tomorrow unfortunately, as I’m already max out
14:58 <cpaelzer> didrocks: slyon: is this looking like it also needs a round of security?
14:59 <didrocks> doesn’t look like it (from the description)
14:59 <cpaelzer> it is a kernel module after all right?
14:59 <didrocks> right
14:59 <slyon> EOW should be fine, I guess. I'm in touch with Alex and Heinrich and will ask them to provide a testplan ASAP
14:59 <cpaelzer> ok, I'm sure you'll make the right call didrocks
14:59 <cpaelzer> and slyon will get the team crunching on completing this to be acceptable
14:59 <didrocks> kernel module, I will have to look how scary the code is
14:59 <cpaelzer> ok
14:59 <cpaelzer> any other - other topics?
14:59 <didrocks> slyon: sounds good, thanks!
14:59 <slyon> ok, thank you!
14:59 <joalif> i have one
14:59 <joalif> i'm reviewing libssh2
15:00 <cpaelzer> I'm slightly disctracted by other meetings now- but go joalif
15:00 <joalif> https://bugs.launchpad.net/ubuntu/+source/libssh2/+bug/1991650
15:00 <slyon> my other (parallel) meeting just ended :)
15:00 <cpaelzer> what is the question there joalif?
15:00 <joalif> libssh with same functionality in main, however chopin's argument "Regarding the feature duplication between libssh1 and libssh2, the Rust bindings for the latter are well-maintained and see substantial usage, whereas the former are barely used..Given that FFI bindings are one of the trickiest area of Rust in terms of unsafe code, I believe it safer not to try and port cargo to libssh1."
15:00 <joalif> sounds ok to me
15:01 <joalif> what do you think ?
15:01 <cpaelzer> to me that is a reasonable explanation why duplication is needed, although it makes me sad that we have to have two
15:01 <cpaelzer> let me check why the deps I knew have changed ...
15:01 <sarnold> I'm not sure they're as 'duplicate' as their names would sound, https://www.libssh2.org/libssh2-vs-libssh.html
15:02 <cpaelzer> oh they are not "the same"
15:02 <didrocks> puzzling
15:02 <schopin> They're similar enough that I thought justification was warranted :)
15:03 <joalif> yup, btw great work on MIR bug schopin
15:03 <sarnold> good instinct :)
15:04 <cpaelzer> what is holding libssh in main?
15:05 <cpaelzer> maybe they could switch to libssh2 as well?
15:05 <cpaelzer> oh I see, curl and cryptosetup and a few - hmm maybe not
15:05 <schopin> curl actually links against libssh2 by default upstream
15:05 <cpaelzer> I'm leaning to "it was tried to not duplicate too much => ok"
15:06 <cpaelzer> schopin: I was only looking at revdeps
15:06 <cpaelzer> maybe once libssh2 is in we could do a check which could/would check
15:06 <cpaelzer> qemu would be ok to change IIRC
15:06 <cpaelzer> you say curl as well
15:06 <cpaelzer> libvirt would be ssh2 compat as well
15:07 <schopin> I'll put that as a roadmap idea for next cycle :)
15:14 <cpaelzer> thanks schopin
15:14 <cpaelzer> and by that and no other comment
15:14 <cpaelzer> let us close this meeting for today
15:14 <cpaelzer> thank you all!
15:14 <sarnold> thanks cpaelzer, all :)
15:14 <cpaelzer> #endmeeting