14:29 <cpaelzer> #startmeeting Weekly Main Inclusion Requests status
14:29 <meetingology> Meeting started at 14:29:49 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
14:29 <meetingology> Available commands: action, commands, idea, info, link, nick
14:30 <cpaelzer> hi ddstreet jamespage sarnold doko didrocks
14:30 <cpaelzer> I feel I'd have forgotten someone ...
14:30 <didrocks> hey
14:30 <jamespage> o/
14:30 <cpaelzer> let me know if I did
14:30 <cpaelzer> #topic Review of previous action items
14:30 <cpaelzer> We ahve concluded the modification to the testing-requirements last week
14:31 <cpaelzer> the wiki was updated right away
14:31 <cpaelzer> that is done
14:31 <cpaelzer> Furthermore I have asked all of you to think about rust, if there is anything in particular let me know in the final "other business" section
14:31 <sarnold> good morning
14:31 <cpaelzer> if not I can already tell you that I started a discussion about it with various people in foudntations that are close to rust
14:32 <cpaelzer> ok, let us get the MIR status going and see if we have open work
14:32 <cpaelzer> #topic current component mismatches
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> libnet-snmp-perl is ready and promotable which allows amavisd-new to pass
14:32 <cpaelzer> see https://bugs.launchpad.net/ubuntu/+source/libnet-snmp-perl/+bug/1936970
14:32 <ubottu> Launchpad bug 1936970 in libnet-snmp-perl (Ubuntu) "[MIR] libnet-snmp-perl as a dependency of amavisd-new" [Undecided, Fix Committed]
14:33 <cpaelzer> didrocks: you did the review, could you maybe resolve that later?
14:33 <cpaelzer> by promoting the package
14:33 <didrocks> cpaelzer: sure, will do
14:33 <cpaelzer> thanks in advance
14:34 <cpaelzer> the rest seems to be the usual set of known cases and false positives
14:34 <cpaelzer> what is the expectation on https://bugs.launchpad.net/ubuntu/+source/python-cheroot/+bug/1930111
14:34 <ubottu> Launchpad bug 1930111 in cherrypy3 (Ubuntu) "[MIR] new dependencies of cherrypy3: jaraco.collections, jaraco.classes, jaraco.text, python-cheroot, python-jaraco.functools, python-tempora, python-portend, zc.lockfile" [Undecided, In Progress]
14:34 <cpaelzer> it seems assigned to security
14:34 <jamespage> looking
14:35 <cpaelzer> @jamespage is the expectation for this in this cycle or anytime later?
14:35 <jamespage> from my perspective its not critical for this release - ceph dash works fine with the current version
14:36 <jamespage> however that does level the cherrypy3 sync/merge from debian dangling
14:36 <cpaelzer> ok, good to know
14:36 <cpaelzer> indeed
14:36 <jamespage> so it may have wider unable to sync/merge impacts than I'm aware of
14:36 <cpaelzer> sarnold: how full/long do the queues look these days?
14:37 <sarnold> cpaelzer: only egl-wayland has been finished in recent times..
14:37 <cpaelzer> well, that is better than nothing
14:37 <cpaelzer> just asking for cherrypy3 to manage expectations
14:37 <cpaelzer> not to put pressure on you
14:38 <sarnold> openstack team wants octavia, python-cheroot; server team wants fence-agents, telegraf; foundations / server wants busybox (conversation here); desktop wants libbluray, security team wants a raft of smartcard packages
14:38 <cpaelzer> ok, quite a list indeed
14:38 <didrocks> (and desktop wants adsys, which is still not reviewed after a month and half :/ and that, without counting security team review time)
14:39 <cpaelzer> doko: ^^
14:39 <cpaelzer> let me be a bit offensive here doko would it help to ping mclemenceau_ (which we hereby do) to get some other things off your back to get adsys processed) ?
14:39 <cpaelzer> ok thanks sarnold
14:40 <cpaelzer> enough for this section I think
14:40 <cpaelzer> ok, we can short-cut the next two sections - no new inbound MIRs and no recent updates except https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1942394 which belongs to the rust topic that I already mentioned
14:40 <ubottu> Launchpad bug 1942394 in mdevctl (Ubuntu) "[MIR] mdevctl 1.0.0 (rust switch)" [Undecided, Incomplete]
14:40 <cpaelzer> which gets us to
14:40 <cpaelzer> #topic Any other business?
14:40 <cpaelzer> as I mentione I think of rust* a lot recently
14:40 <cpaelzer> I'm playing with the thought of ammending the MIR rules for the common concept in (go/rust) these
14:41 <cpaelzer> the point is that way too often the libs are super small and not really testable non-superficially on their own
14:41 <cpaelzer> if they have e.g. unit-tests they are run at build time anyway
14:41 <cpaelzer> but I wondere if for those cases we would want to ammend the rules to require the testing on the solution level
14:42 <cpaelzer> so if package FOO is MIRed providing an actual use case, then that/those use-case(s) shall be tested - thereby excercising the libs in that scope
14:42 <cpaelzer> if later package BAR comes in it might excercise other paths and thereby should also be reuqired to test, even if some dependencies are in main already
14:42 <cpaelzer> many of those libs are automatically packaged
14:43 <cpaelzer> and keeping the testing on the solution level would help a lot
14:43 <cpaelzer> that much as a current brain-dump
14:43 <cpaelzer> if there are opinions now let me know, otherwise I might come by at some point suggesting a rule change with something like that
14:43 <didrocks> I agree with this, the most important testing is always IMHO the integration tests from an user perspective, then the rest is more for "developers" to debug and exercise their code (and corner cases. As long as the solution is great in term of testing, it will test the library as well. Also, it will only test the interesting part (for that solution) of that lib, and will be more focused
14:44 <didrocks> And if you start depending on a particular lib, even not really tested, well, you own the responsability of that lib behaviour on the solution level anyway…
14:44 <cpaelzer> ok good to hear that I'm not fully off with my thought
14:44 <sarnold> you've been far more productive thinking about this than I have; the closest I've come is a general feeling that we really ought to have someone or two on board who just loves updating deps in rust applications, handling the breakage, reporting breaks upstreams, etc
14:44 <cpaelzer> I'll ahve to review the other MIR rules if there are also others that make more sense on that level
14:45 <sarnold> (same also goes for golang)
14:46 <cpaelzer> I'm pushing for it at foundations, but that is separate to streamlining the rules to be "more doable"
14:46 <cpaelzer> it = more resources for them
14:46 <cpaelzer> and I have dived into dynamic libs for rust which was a nice learning experience but won't help us
14:46 <cpaelzer> ok, that might be it for today
14:47 <cpaelzer> anything else
14:47 <sarnold> nothing from me
14:47 <didrocks> nothing either
14:48 <cpaelzer> ok then
14:48 <cpaelzer> let me close for today then
14:48 <cpaelzer> thank you all
14:48 <cpaelzer> #endmeeting