14:30 #startmeeting Weekly Main Inclusion Requests status 14:30 Meeting started at 14:30:17 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology 14:30 Available commands: action, commands, idea, info, link, nick 14:30 hello o/ 14:30 o/ 14:31 Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe ) 14:31 hi everyone 14:31 o/ 14:31 #topic current component mismatches 14:31 Mission: Identify required actions and spread the load among the teams 14:31 #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg 14:31 #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg 14:32 oh lovely *-perl 14:32 you missed it last week slyon 14:32 o/ 14:32 bryce is on the big tree out of spamassassin 14:32 we haven't settled on a solution yet 14:32 good morning 14:32 haha, OK. I guess I'll investigate libio-compress-brotli-perl 14:33 slyon: you might, but IIRC matt mentioned that Steve looked at it already 14:33 ok. I'll check back with them 14:33 slyon: so ensure to not do redundant work 14:34 ruby-rack is stuck intentionally for now, kanashiro[m] is on that 14:34 everything else is known and ok 14:34 no action here 14:35 #topic New MIRs 14:35 Mission: ensure to assign all incoming reviews for fast processing 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 first of all 14:35 the easy cases 14:36 glibmm, gtkmm, cairomm are just source uploads of the same we had 14:36 so those get usually a fast sanity check if they are really the same 14:37 joalif: did one of them - and we said if this worked out as expected we will distribute the others and expect them to be quick checks 14:37 it was fairly simple 14:37 the source code didnt have extensive changes 14:37 joalif: and was it, as expected, just the same as before 14:37 good 14:37 thanks 14:38 so today let us hand out the other three 14:38 but with a low effort expectation 14:38 i can have one of them 14:38 I'm happy to take glibmm 14:38 joalif: which one was the one you handled, could you share the LP reference, so we can use it as a template? 14:38 joalif: for another - gtkmm then 14:38 slyon: cairomm ok? 14:38 sure! 14:38 I can take 2 or have 1 and then, next week another one 14:38 slyon: https://bugs.launchpad.net/ubuntu/+source/pangomm2.48/+bug/2020267 14:38 thx 14:39 the last one is https://bugs.launchpad.net/ubuntu/+source/libhttp-cookiejar-perl/+bug/2024245 14:39 that might have been the one Matt informed me about 14:39 sounds like good Friday’s material then 14:39 perl :p 14:39 happy to take it 14:39 indeed it is 14:39 well "happy…" it’s perl 14:39 so slyon the other one is new and for you 14:39 but you know what I mean :p 14:39 ack 14:39 assigned didrocks 14:40 thank you all 14:40 let us look at the incomplete 14:40 #topic Incomplete bugs / questions 14:40 Mission: Identify required actions and spread the load among the teams 14:40 #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:40 duktape I looked at 14:40 they did what we asked 14:40 and committed to do some more later (out of the recommended set) 14:41 this is ready to promote, but waits for the newly added tests to run on infra once 14:41 incomplete until then 14:41 yay new tests :) 14:41 you should be happy 14:41 the other updates have been present last week 14:41 so that is fine 14:42 #topic Process/Documentation improvements 14:42 Mission: Review pending process/documentation pull-requests or issues 14:42 #link https://github.com/canonical/ubuntu-mir/pulls 14:42 #link https://github.com/canonical/ubuntu-mir/issues 14:42 https://bugs.launchpad.net/ubuntu/+source/libcamera/+bug/1997560 also needs to be re-reviewed please 14:42 do not mind pull #17 and issue #22 - I haven't found time yet 14:42 hi seb128, thanks for the ping - having a look 14:43 slyon: that is your case, can you do that re-check? 14:43 thx, I expect that's for slyon since he did the first review 14:43 PR 23 I have requested some changes to make it more useful - waiting on dviererbe 14:43 that leaves the potentially longer open discussions 14:43 seb128: cpaelzer: I'll be looking into libcamera and comment on the bug report 14:43 thanks slyon 14:43 slyon, thanks 14:44 both by seth asking for reflection on how we work 14:44 https://github.com/canonical/ubuntu-mir/issues/24 14:44 on this, while we are all busy - I do not yet see a real shortage 14:44 we generally get things adressed in a timely manner 14:45 and the thought of more work is mostly around re-reviews which we already throttled by suggesting to fill into a constant 1-per-week load 14:45 so that would be fine 14:45 furthermore the team composition is meant to be a bit "one of each" for foundation, desktop, server, seg, ... 14:45 so adding would be ... duplicating? 14:45 I see no need for either yet 14:46 the real question in there - for now - I think is "How do we add more?" 14:46 this isn't defined 14:46 so far it has been a team discussion and team decision 14:46 this isn't a place you'd "apply" for unless you got pushed that way by a manager right? 14:46 yes, it’s mostly cooptation, and a lot of ubuntu teams are like this 14:47 or just sort of volunteered by team mates? :) (hello eslerm, dviererbe :) 14:47 I know that generally such a question "How do we add more?" in a similar "weakly defined" way is being worked on. As others like SRU and archive admins are like it 14:47 yes you might be pulled in like eslerm and dviererbe 14:47 I think I saw a similar discussion on the TB mailing list.. 14:47 but remember that in theory they are good friends but no members, if it ever comes to voting and qorum and such 14:48 slyon: yes that is what i mean 14:48 let them sort it out for an example team 14:48 that is more about Ubuntu, which MIR is not necessarily part of (this is more of Canonical), but we could use the same process, once defined 14:48 if there is a best practice out of that we might juts pick it up 14:48 is that a sufficien state for now sarnold? 14:48 we've had a few very small meetings, that raised the question.. and if we intend to get through the 2300-ish packages in main in a decade, we might need more help? 14:49 sarnold: I'd want to bother about that if/once we ever conclude on really being able to do re-reviews as a company 14:49 we will start slow with the capacity we have, see if the teams can at all follow up 14:49 and once proven worthwhile we can think about expanding 14:49 cpaelzer: okay, so leavaing that aside, you feel like the work is otherwise reasonable enough and not yet cause for concern? 14:49 yes 14:50 only the security side of things sometimes stalls :-) 14:50 but this got better since you sarnold have eslerm as buddy 14:50 and occasional meetings with two or three team members showing up is also no cause for concern? 14:50 cpaelzer: and much help from others :) 14:50 indeed 14:50 sarnold: it hasn't been blocking us that we attend as we are available (like no PTO coverage) 14:51 if it would be, I'd consider it - but since it worked fine - why make things more ocmplex 14:51 cool, thanks for the discussion; and I'm glad to hear the larger question is being asked elsewhere, too 14:51 indeed 14:51 sarnold: would you mind copy&paste and self-close your issue? 14:51 cpaelzer: good idea 14:51 my time runs out soon with a hard stop and a conflict 14:51 trying to present the next case 14:52 but mind the time 14:52 https://github.com/canonical/ubuntu-mir/issues/26 14:52 filed by sarnold but brought up by seb128 14:52 I can tell you how I feel, and you please tell me what you think - ok? 14:52 I've seen cases where - with some effort - C++ symbols were made useful 14:52 due to that I like to ask the teams to give it a shot 14:52 and I've seen cases 14:53 the libcamera MIR which is ready for re-review mentioned earlier sort of collide with that (though they are now bumping the soname with every version which might be enough for us to get away with it) 14:53 where they have tried and based on that came back to explain well why it won#t work int his case 14:53 seb128: that is a trick to get out, but yeah perma soname bump is avoiding that too 14:53 so in my mind maybe we should extend the explanation in the RULE lines 14:53 to explain that people should have a reasonable look 14:54 did we have precedence for such soname bumping in the past? 14:54 maybe with a hint where it worked well 14:54 does that mean a new libcameraN every release? 14:54 sarnold, yes 14:54 I mean.. it avoids the issue that .symobls is trying to fix, so should be acceptable from the MIR perspective? 14:54 slyon: yes, dpdk does that for example 14:54 once every year 14:54 and it was much nicer 14:54 but 14:54 we still do symbols tracking there 14:55 are we proposing bumping sonames out of cadence with upstream? 14:55 and it cought errors a few times 14:55 yes, that means some extra libcameraN transitions, but I guess there are not (yet?) too many reverse dependencies 14:55 e.g. on supposed stable updates 14:55 so even if soname gets bumped each time, for SRUs symbols tracking is helpful 14:55 real life experience 14:56 which in turn means "so bumps each time" is no reason to say "we won't do symbols tracking" 14:56 I consider a proper, "this is what I tried, this is why it fails and this is why it is feasible" statement the right way 14:56 ok. So this ^ might be a problem for the libcamera MIR, seb128 14:57 I'd not want to give a too easy option to pass on symbols, but also I acknowledge that symbols isn't a strict requirement 14:57 does that make sense? 14:57 slyon, I will follow up with a comment stating that 14:57 thanks 14:57 I think this is in line and solidify what we were asking for C++ libs, no? Just more official (give it a shot at least, try it, and assess with the result, but start with trying it) 14:57 cpaelzer: yes that makes sense. especially the SRU argument is very valid! 14:57 I still think the experience is expensive and broken 14:58 maybe your libs really are different than ours 14:58 there is no decent way to deal with the cross arch difference 14:58 as it was said multiple times, that might be fine - but it depends on the code seb128 14:58 like libcamera which synced from Debian had around 190 lines of symbols diff 14:59 one package might have that issue, explain and demonstrate 14:59 and get an ack to be without symbols 14:59 right 14:59 another package might work well 14:59 long term I still think that as a project we should aim at doing better 14:59 which is better than saying "yo do not need to bother about symbols" 14:59 also symbols don't really cover abi, they wouldn't catch a change in a structure definition 14:59 I agree to "as a project we should aim at doing better", i Just have no great option and time to work on yet 15:00 I'm +1 with the 'give it a try be be allowed to explained why it doesn't work for this project' 15:00 great 15:00 my next double concurrent meeting has started 15:00 same here 15:00 happy meeting 15:00 we were also playing with the alternative option of 'enforce the symbol on amd64, at least it's manageable and better than not having it' 15:01 would someone be ok to convert this into a PR to mention it more clearly in the RULES section? 15:01 that would indeed be better if you can get it to work 15:01 at next meeting, I would like to discuss the status of LP#1993819 15:02 it's still tedious, but it's on one arch and be handled locally so probably an acceptable tradeoff for the extra safety 15:02 eslerm: I've given it a bump to be sure we see it 15:02 thanks 15:02 yep 15:02 seb128: is this something you're actively experimenting with? or an idea being kicked around? 15:02 seb128: would you mind to throw a PR to https://github.com/canonical/ubuntu-mir 15:02 that way you can ensure the suggested change matches what you'd like 15:03 and we can check if it matches what we thought to be the outcome of this meeting 15:03 cpaelzer, I can do that yet 15:03 thanks 15:03 np! 15:03 we are over I know 15:03 so let us hope to be quick and easy on the last two agenda items 15:03 #topic MIR related Security Review Queue 15:03 Mission: Check on progress, do deadlines seem doable? 15:03 Some clients can only work with one, some with the other escaping - the URLs point to the same place. 15:03 #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 15:03 #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=[MIR]&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir 15:03 Internal link 15:03 - ensure your teams items are prioritized among each other as you'd expect 15:03 - ensure community requests do not get stomped by teams calling for favors too much 15:03 #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 15:03 that looked good recently 15:03 there's progress on many MIRs simultaneously :) it's a fun place to be 15:04 indeed sarnold 15:04 cargo will be discussed next week as eslerm requested 15:04 but overall that security queue LGTM 15:05 you even slowly but surely get to those libheif related packages 15:05 great 15:05 I'd bve happy and go on ... 15:05 #topic Any other business? 15:05 none here 15:05 none here either 15:05 nothing 15:05 nothing 15:05 same :) 15:06 these meetings start to run over more often, which isn't too bad as it shows how active and approachable we are. If it is too often we can push more discussions to e.g. GH issues 15:06 I'd close it out, thank you all 15:06 thanks cpaelzer, all :) 15:06 #endmeeting