14:29 #startmeeting Weekly Main Inclusion Requests status 14:29 Meeting started at 14:29:49 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology 14:29 Available commands: action, commands, idea, info, link, nick 14:30 hi ddstreet jamespage sarnold doko didrocks 14:30 I feel I'd have forgotten someone ... 14:30 hey 14:30 o/ 14:30 let me know if I did 14:30 #topic Review of previous action items 14:30 We ahve concluded the modification to the testing-requirements last week 14:31 the wiki was updated right away 14:31 that is done 14:31 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 good morning 14:31 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 ok, let us get the MIR status going and see if we have open work 14:32 #topic current component mismatches 14:32 #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg 14:32 #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg 14:32 libnet-snmp-perl is ready and promotable which allows amavisd-new to pass 14:32 see https://bugs.launchpad.net/ubuntu/+source/libnet-snmp-perl/+bug/1936970 14:32 Launchpad bug 1936970 in libnet-snmp-perl (Ubuntu) "[MIR] libnet-snmp-perl as a dependency of amavisd-new" [Undecided, Fix Committed] 14:33 didrocks: you did the review, could you maybe resolve that later? 14:33 by promoting the package 14:33 cpaelzer: sure, will do 14:33 thanks in advance 14:34 the rest seems to be the usual set of known cases and false positives 14:34 what is the expectation on https://bugs.launchpad.net/ubuntu/+source/python-cheroot/+bug/1930111 14:34 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 it seems assigned to security 14:34 looking 14:35 @jamespage is the expectation for this in this cycle or anytime later? 14:35 from my perspective its not critical for this release - ceph dash works fine with the current version 14:36 however that does level the cherrypy3 sync/merge from debian dangling 14:36 ok, good to know 14:36 indeed 14:36 so it may have wider unable to sync/merge impacts than I'm aware of 14:36 sarnold: how full/long do the queues look these days? 14:37 cpaelzer: only egl-wayland has been finished in recent times.. 14:37 well, that is better than nothing 14:37 just asking for cherrypy3 to manage expectations 14:37 not to put pressure on you 14:38 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 ok, quite a list indeed 14:38 (and desktop wants adsys, which is still not reviewed after a month and half :/ and that, without counting security team review time) 14:39 doko: ^^ 14:39 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 ok thanks sarnold 14:40 enough for this section I think 14:40 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 Launchpad bug 1942394 in mdevctl (Ubuntu) "[MIR] mdevctl 1.0.0 (rust switch)" [Undecided, Incomplete] 14:40 which gets us to 14:40 #topic Any other business? 14:40 as I mentione I think of rust* a lot recently 14:40 I'm playing with the thought of ammending the MIR rules for the common concept in (go/rust) these 14:41 the point is that way too often the libs are super small and not really testable non-superficially on their own 14:41 if they have e.g. unit-tests they are run at build time anyway 14:41 but I wondere if for those cases we would want to ammend the rules to require the testing on the solution level 14:42 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 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 many of those libs are automatically packaged 14:43 and keeping the testing on the solution level would help a lot 14:43 that much as a current brain-dump 14:43 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 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 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 ok good to hear that I'm not fully off with my thought 14:44 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 I'll ahve to review the other MIR rules if there are also others that make more sense on that level 14:45 (same also goes for golang) 14:46 I'm pushing for it at foundations, but that is separate to streamlining the rules to be "more doable" 14:46 it = more resources for them 14:46 and I have dived into dynamic libs for rust which was a nice learning experience but won't help us 14:46 ok, that might be it for today 14:47 anything else 14:47 nothing from me 14:47 nothing either 14:48 ok then 14:48 let me close for today then 14:48 thank you all 14:48 #endmeeting