=== cpaelzer_ is now known as cpaelzer === ebarretto_ is now known as ebarretto === mIk3_09 is now known as mIk3_08 [14:29] o/ [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 [14:48] Meeting ended at 14:48:35 UTC. Minutes at https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-09-07-14.29.moin.txt [14:48] thanks cpaelzer, all :) [14:48] thanks everyone! [18:07] ping diddledani