14:31 #startmeeting Weekly Main Inclusion Requests status 14:31 Meeting started at 14:31:20 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology 14:31 Available commands: action, commands, idea, info, link, nick 14:31 ddstreet doko didrocks sarnold jamespage - hello 14:31 hey 14:31 #topic Review of previous action items 14:32 ack lemme grab coffee then i'll update with a new pastebin 14:32 we have pushed the definnition of the rule changes to the mailing list 14:32 I think we've made progress there 14:32 * doko hides, haven't done adsys yet 14:32 all agree on a change being worthwile 14:32 * didrocks looks at doko :) 14:32 we are just polishing the words itself 14:32 I'd suggest that ddstreet and I drive this into conclusion with what is on the mails already 14:32 any opposing voices before we decide to do to? 14:33 I've not seen anything in the last 11.5 hours or so.. 14:33 did I miss any "interesting" updates to the text? :) 14:33 ddstreet: had nicer words to my suggestion to make the "commit to testing" a bit harder 14:34 and I have replied to the discussion that we might want to see test scripts/docs and a sample log 14:34 just that it is proven to exist and not just an intent 14:34 we will get a new pastebin later this meeting and then do a vote on it 14:34 I'll go through the normal agenda now 14:34 oh excellent, sometimes I have great trouble spotting the actual test execution 14:34 #topic current component mismatches 14:35 #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg 14:35 #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg 14:35 usually I say nothing new, then sarnold tells me what I have missed 14:35 IMHO nothing new ... 14:35 shall we swap places today? I see nothing new 14:35 ok sorry back with coffee now 14:35 no ddstreet 14:35 hehe 14:35 the rest will be just as fast today 14:35 #topic New MIRs 14:35 #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:35 empty 14:35 yeah going fast today! 14:36 the one incoming last week I have copleted 14:36 doko: already admited to be aware but late on adsys 14:36 #topic Incomplete bugs / questions 14:36 #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:36 nothing new here 14:36 #topic Any other business? 14:36 well, now ddstreet if you had the time to complete a new pastebin we could vote 14:36 nothing for me 14:37 nothing for me 14:37 I have a pre-discussion to do - which is about the current process forces a bit of "the first being the victim" 14:37 cpaelzer ok https://pastebin.canonical.com/p/CZnNtWkGbK/ 14:38 that means that e.g. the first rust package that will have to go into main will have to own 95% of the package std-libs 14:38 crap that's canonical pastebin, lemme get an uubntu one 14:38 ok let me continue on that after we've hadnled the paste of ddstreet 14:38 https://pastebin.ubuntu.com/p/tpyKDPT7r4/ 14:38 I like it 14:38 I'd also extend the check template to consider that 14:39 yes 14:39 agreed 14:39 I'm not formally asking for votes 14:39 the time I need to check meetinology syntax will be wasted :-) 14:39 +^ from me 14:39 doko says yes as well 14:39 ddstreet: has suggested it 14:39 sarnold: / ddstreet - what about you ? 14:39 yes +1 from me 14:39 sometimes autopkgtests are the thinnest of tests.. 14:40 yep 14:40 sarnold: but on MIR review we look if they are Kindergarden and might reject it 14:40 this is just about the excuse of "can't be done at biuld/autopkgtest because of special HW" 14:40 .. while I've never seen anything remotely looking like .. lazyness? deviousness? from any of my colleagues, ever, I do slightly worry that a five-line autopkgtest might be enough to 'absolve' a team from helping to test something 14:42 telling just how good a test suite is is pretty difficult to do, so I don't have any awesome answers, but maybe adding a "non-trivial" around line 5 or 6 would help me :) 14:42 I think the proposal here makes the rules better 14:42 "substantive"? 14:42 added non-trivial 14:42 it's true, but sometimes even just a basic sanity check is better than nothing, e.g. for needrestart i required some test, but all that could be done at first was pretty basic https://bugs.launchpad.net/ubuntu/+source/needrestart/+bug/1907422 14:42 Launchpad bug 1907422 in needrestart (Ubuntu) "[MIR] needrestart + dependencies" [Undecided, Fix Released] 14:42 that is easy and reasonable 14:43 I think people can understand non-trivial and agree on the term :) 14:43 yes 14:43 I'd be ok to hit save on the wiki 14:43 we overall seem to be +1 14:43 excellent, thanks 14:43 +1 :D 14:43 all requested amends are done 14:44 thanks everyone 14:44 let me quickly complete my former thought 14:44 thanks 14:44 just to plant the seed not to exhaustively discuss it today 14:44 that means that e.g. the first rust package that will have to go into main will have to own 95% of the package std-libs 14:44 usually foundations would be toolchain/stdlib 14:44 so I wonder (especially @doko) how we'd want to do that 14:45 how was it with golang 14:45 should I just talk with Matt 14:45 are there other suggestions 14:45 full-disclosure: I have a very trivial, but rust based package coming 14:46 so I'm interested to NOT own too many rusty things not close to what I'm actually trying to use/support 14:46 If there are immediate thought let me know, otherwise let this echo a bit 14:46 and in next weeks actions section we cna check what we think about it 14:46 the issue with rust is that you still have a lot of breaking changes between releases, making other packages not building, correct? (my info on rust are now very rusty, like multiple years old :p) 14:47 yeah, even though they've got the 'semver' idea of trying to clearly label breaking changes, that's only as good as the human updating the version number, and of course some folks just plain don't care to maintain older packages.. 14:48 I have the impression that they're better about it than the golang folks but perhaps not as good as highly-disciplined C projects 14:49 well, on golang, you don’t have that problem with golang itself and the stdlib (basically since the V1 and compatibility promise), the issue is then more about other libraries that don’t use semver, and so, you "only" impact a small set of reverse deps 14:49 but yeah, the first one who needs an update on one of those would pay the price of it as cpaelzer says 14:50 right now the package is trivial and I'm trying to keep the rust move until after 22.04 14:50 this README has some breadcrumbs on more painful rust crate version updates https://github.com/dtolnay/semver-trick 14:50 but then upstream switched and as soon as there is a hard dep on the new things I've a problem 14:50 thanks for the links and thoughts 14:50 "During the most recent libcpocalypse, Servo found themselves coordinating an upgrade of 52 libraries over a period of three months" 14:51 I'd still suggest that to some extend that is more case of "foundations gets half a head-count" instead of random-team-will-own rust 14:51 as much as I like rust, I'm worried that some day the whole ecosystem is going to jam into one solid ball that can't be shifted 14:51 cpaelzer: hah, I was thinking more "we need a dedicated golang team and a dedicated rust team" 14:51 you are not making me feel better about is sarnold 14:51 thanks for the pre-thoughts on this everyone 14:52 alas I don't have a line item to spend :) 14:52 I guess we can conclude for today 14:52 thanks! 14:52 thanks cpaelzer, all :) 14:52 * didrocks thought that sarnold was clearly committing… :) 14:52 thanks everyone 14:52 #endmeeting