[14:29] good morning [14:29] hello [14:29] o/ [14:30] hey [14:31] hi [14:31] seems it will be only us again? [14:31] ah cpaelzer is back :) [14:31] wb! [14:31] give me a sec to start [14:31] o/ [14:31] hey joalif! [14:32] #startmeeting Weekly Main Inclusion Requests status [14:32] Meeting started at 14:32:41 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology [14:32] Available commands: action, commands, idea, info, link, nick [14:33] Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe ) [14:33] #topic current component mismatches [14:33] Mission: Identify required actions and spread the load among the teams [14:33] #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [14:33] #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg [14:33] wow [14:33] omg [14:33] wut [14:34] spamassin is assassinating us :p [14:34] the moment you zoom out and realize the thing at the top is yours [14:34] oh no :-/ [14:34] let me pass that to the team [14:34] and then we look what else is in the report [14:35] hopefully, we don’t care about the recommends and then, no big deal [14:35] I assume it's on this graph because we do care about recommends [14:35] is this MIR still valid? https://bugs.launchpad.net/ubuntu/+source/libnet-idn-encode-perl/+bug/1494890 [14:35] -ubottu:#ubuntu-meeting- Launchpad bug 1494890 in libnet-idn-encode-perl (Ubuntu) "[MIR] libnet-idn-encode-perl (b-d of libio-socket-ssl-perl)" [Undecided, Fix Released] [14:35] sarnold: yeah, I mean, just a question of removing the recommends [14:35] afterall, we have to teach users about apt install --no-install-recommends all the time :( [14:35] ahhh [14:36] ok, looking at others [14:36] libww-perl -> libhttp-cookiejar-perl [14:36] ruby-rack [14:37] ruby is a transiton to 3.0 which kanashiro[m] is on top already [14:37] ruby-rack I should say [14:37] which was even a requirement in the pcs MIR last cycle [14:37] so consider that under control [14:37] how about this www-perl? [14:37] slyon isn't here, that sounds like foundations [14:38] let me ping mclemenceau ^^ [14:38] mclemenceau: could you have someone look after the component mismatch in mantic-proposed please [14:38] woah looks like launchpad got a stylesheet refresh [14:38] did it? [14:38] indeed [14:39] libhttp-cookiejar-perl: libhttp-cookiejar-perl [14:39] [Reverse-Depends: libwww-perl (MAIN)] [14:39] mclemenceau: that is the one you could look at [14:39] everything else is known [14:39] no further action [14:40] except me finding someone to unbreak this massive tree behind spamassassin [14:40] #topic New MIRs [14:40] Mission: ensure to assign all incoming reviews for fast processing [14:40] #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:40] 4 in the queue [14:40] There is also https://bugs.launchpad.net/ubuntu/+source/boot-managed-by-snapd/+bug/2023366 [14:40] -ubottu:#ubuntu-meeting- Launchpad bug 2023366 in boot-managed-by-snapd (Ubuntu) "[MIR] boot-managed-by-snapd" [Undecided, New] [14:40] all of them we have seen before [14:40] dviererbe: that is subscribed to the wrong team [14:40] yeah, some for quite some time as I was the only available MIR reviewer around and can only take 2 by pulse [14:41] today myself and joalif can take a few if possible [14:41] so, for next pulse, I can take 2 of them (I guess cairo/pango in the order of deps, apart if someone else can parallelize those) [14:41] yup [14:41] and it is fair to limit the number per pulse or whatever cycle you plan for [14:41] technically those are new version of packages already in main but I guess you want to review them again? [14:42] dviererbe: we are the "MIR approval team" not the "Mir development team" [14:42] dviererbe: I fixed the subscription [14:42] thanks [14:42] weirdly that was the only team that popped up when I searched for mir [14:42] I'd take boot-managed-by-snap [14:42] as I'm curious by the name [14:43] didrocks: is "next pulse" today or next week or even later? [14:43] its mostly just a transitional package [14:43] cpaelzer: next week [14:43] ok [14:43] joalif: pick one of your choice please [14:43] in case one seems nicer than the other to you [14:43] i can take whatever, let's say the first one [14:44] it is important to consider the comment of seb128 [14:44] usually if this is just a foo1 to foo2 [14:44] it is a fast path [14:44] and not a full review [14:44] \o/ [14:44] we do sanity checks, ensuer the old reviews didn't say "just this time" or such [14:44] and then approve [14:44] joalif: ok you take pangomm2.48 then [14:45] yes [14:45] joalif: if your check on this confirms that it is "the same as we have, just versioned source and all is fine" [14:45] then we can next week assign the rest assuming they are similar fast paths [14:45] does that work for everyone? [14:45] sounds good to me [14:45] ok [14:46] ok, let us go on then [14:46] #topic Incomplete bugs / questions [14:46] Mission: Identify required actions and spread the load among the teams [14:46] #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:46] man that's a lot of incompletes [14:47] not that many recent though [14:47] We haven't closed incompletes for a while [14:48] I think we had some number of days to mark them invalid [14:48] yeah, we tend to focus on the happy end of the list (for good reasons :) .. but some of these oolldd things make me sad, heh [14:48] let me close all pre 2023 [14:48] I think they are incomplete and got no update for so long [14:48] it is correct for expectation management [14:48] to call them incomplete [14:49] WDYT? [14:49] yeah, it's probably fine to just blanket set them all invalid. it might be a nice reminder to the folks who might sitll be around [14:49] yeah, sounds like the correct approach to me [14:50] give me a minute [14:51] heh, argyll, updated a few months ago, opened in 2011 [14:52] I think conditinal ACK requirements like autopkgtests should be met before promotion so that we don't get into this state, but that can be specified by MIR/Security reivews going forward [14:54] dine [14:54] thanks [14:54] probably some of these are changing business needs [14:54] others might be simply overlooked TODO items that were never fulfilled [14:54] eslerm: yes, conditional ack requirements are meant to be met [14:54] ack on the chance for overlook [14:54] that was the reason we started to number them [14:54] it made it easier to track them [14:55] I need to continue in the matter of time [14:55] #topic Process/Documentation improvements [14:55] Mission: Review pending process/documentation pull-requests or issues [14:55] #link https://github.com/canonical/ubuntu-mir/pulls [14:55] #link https://github.com/canonical/ubuntu-mir/issues [14:55] I have today reviewed and merged a few [14:56] there is effort for me and dviererbe before the remaining PRs are re-reviewed here [14:56] on the issues [14:56] one is a discussion on the same topic as the re-review PR [14:56] and let me - for now - just say yes, we do not speak about resourcing yet [14:56] but we need to have in place how we think it works before I combine myself and other directors to be the meta-VP and make a decision [14:57] sarnold: are you ok to go into https://github.com/canonical/ubuntu-mir/issues/24 when there is more time left? [14:57] -ubottu:#ubuntu-meeting- Issue 24 in canonical/ubuntu-mir "More team members" [Open] [14:57] cpaelzer: yes [14:57] thanks [14:57] #topic MIR related Security Review Queue [14:57] Mission: Check on progress, do deadlines seem doable? [14:57] Some clients can only work with one, some with the other escaping - the URLs point to the same place. [14:57] #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 [14:57] #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 [14:57] Internal link [14:57] - ensure your teams items are prioritized among each other as you'd expect [14:57] - ensure community requests do not get stomped by teams calling for favors too much [14:57] #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 [14:57] nothing too surprising here [14:58] we've got MIRs assigned around, so far I think there's happy thoughts [14:58] indeed [14:58] LGTM [14:58] #topic Any other business? [14:58] o/ [14:58] the PRs and issues nowadays cover most of the usual AOB topics [14:58] seb128: have you been waiting for this and brought something new? [14:59] or just seen the highlight that happened a while ago? [14:59] no, I've topics [14:59] first is https://bugs.launchpad.net/ubuntu/+source/webp-pixbuf-loader/+bug/1979121 ... what's the status? [14:59] -ubottu:#ubuntu-meeting- Launchpad bug 1979121 in webp-pixbuf-loader (Ubuntu Jammy) "[MIR] webp-pixbuf-loader" [Undecided, New] [14:59] it is assigned to you since decembre but didn't get any activity so I wonder if it got forgotten somehow? [14:59] this is a classic fallen therough the cracks [14:59] sorry [14:59] I'll look at it [15:00] thanks [15:00] you said topicS [15:00] next? [15:00] the other topic is that I stated a discussion about symbols for c++ libraries on ubuntu-devel@ [15:00] unsure if you guys follow the list of if I should cross reference to github? [15:00] started* [15:01] link please [15:01] https://lists.ubuntu.com/archives/ubuntu-devel/2023-June/date.html [15:01] thanks [15:01] eslerm, https://lists.ubuntu.com/archives/ubuntu-devel/2023-June/042600.html [15:02] I keep hearing that the kde symbols handling is really nice stuff; I don't understand why it's not the default for all our packages [15:02] if you didn't read it yet it's probably better to discuss it another time after people had time to read [15:02] perhaps that's a better question on the list, though :) [15:03] that was mentioned, still it doesn't solve most of the issues raised [15:03] like the difference between architectures and how tedious the process is [15:03] it sounds almost as bad as debian/copyright [15:04] I'll throw some questions on the list, I don't know nearly enough about what these files provide for us [15:05] hopefully that'll keep the conversation moving :) (or cause everyone to roll their eyes at me, either way) [15:05] FYI - I'm double booked now, less focus :-/ [15:05] (I guess the biggest blocker is the multi-arch aspect with different symbols) [15:06] that's not a topic that needs to be discussed/resolved here or now, I just wanted to check if you follow devel or if I should start the same discussion as a github ticket or something [15:06] https://github.com/canonical/ubuntu-mir/issues/26 :D [15:06] -ubottu:#ubuntu-meeting- Issue 26 in canonical/ubuntu-mir "Decide if we get enough value from symbols tracking to keep doing it" [Open] [15:07] sarnold, thanks! [15:07] seb128: and thank you :D [15:07] which means we will revisit it every week [15:07] sarnold, update the title to mention c++ [15:07] until we find qorum and enough time to tihnk deep enough about it [15:07] we don't have those issues for plain C [15:07] C symbols are worth for sure [15:07] ack, done [15:07] C++ symbols would be worth if only they would work [15:07] thx [15:07] thank [15:07] s [15:08] and that was it from me for today :p [15:08] pfew :D [15:08] great [15:08] we are over time [15:08] let me close it here [15:08] and we all handle more next week [15:08] thank you! [15:08] #endmeeting [15:08] Meeting ended at 15:08:36 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-06-13-14.32.moin.txt [15:08] thanks! [15:08] bye all o/ [15:08] thanks cpaelzer, all :) [15:08] thanks cpaelzer, all :) [15:08] thank you, all! [15:23] Ack cpaelzer [15:24] thanks mclemenceau [18:59] o/ [18:59] hey! :) [19:00] o/ [19:00] o/ [19:01] * vorlon waves [19:01] looks like I'm chairing today [19:01] #startmeeting [19:01] Meeting started at 19:01:31 UTC. The chair is vorlon. Information about MeetBot at https://wiki.ubuntu.com/meetingology [19:01] Available commands: action, commands, idea, info, link, nick [19:01] #topic Apologies [19:02] looks like maybe we're all here? [19:02] apparently :) [19:02] #topic Action review [19:02] ACTION: amurray to follow up with backporters team on Mattia's draft charter proposal [19:03] is this done? is there anything further we need to do? [19:03] backporters discussed and approved this in their last meeting - https://lists.ubuntu.com/archives/technical-board/2023-June/002740.html - I think they just want a formal ack from us [19:03] We should have somewhere to document these [19:03] As we expect other teams to get some documentation too [19:04] I can take an action I guess, unless someone else wants to volunteer? [19:04] happy to let you have it [19:04] thanks rbasak :) [19:04] do you want this under https://wiki.ubuntu.com/TechnicalBoard/ ? somewhere else? [19:04] thanks rbasak! [19:05] I was going to put it there to start with [19:05] sounds like a good place to me [19:06] #action rbasak to get agreed backporter charter https://lists.ubuntu.com/archives/technical-board/2023-June/002740.html documented under https://wiki.ubuntu.com/TechnicalBoard/ [19:06] ACTION: rbasak to get agreed backporter charter https://lists.ubuntu.com/archives/technical-board/2023-June/002740.html documented under https://wiki.ubuntu.com/TechnicalBoard/ [19:06] rbasak: thanks [19:06] ACTION: seb128 to help draft an exception to the "must build on all architectures" requirement for snaps [19:06] seb128: any news? [19:06] yes [19:06] we updated the document with rbasak [19:06] I think that action item is done. [19:06] so that can be considered as done [19:06] The snap appendix needs a general cleanup but I'd like to push on with the main body first. [19:08] #done seb128 to help draft an exception to the "must build on all architectures" requirement for snaps [19:08] ACTION: seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage [19:08] how about this? [19:08] It sounded like there were still some loose ends on this? [19:09] yeah - I added a suggestion for this - there's some feedback from seb128 and kenvandine that I need to look over still [19:10] carry-over, then? [19:10] Yes please, I'm looking through it right now [19:10] #action seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage [19:10] ACTION: seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage [19:10] ACTION: sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step [19:11] sil2100: ? [19:11] vorlon: still didn't have time to finalize the docs, only the 'start' of the draft here https://wiki.ubuntu.com/OEMArchive [19:11] I know what to write, but still require some time. So sadly another carry over [19:11] #action sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step [19:11] ACTION: sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step [19:11] ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification [19:12] rbasak: ? [19:13] Carry over please, sorry [19:13] #action rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification [19:13] ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification [19:13] ACTION: the TB members have until the next meeting to review the third party repository requirements document and raise concerns [19:14] I trust that the TB members have done their homework? :) [19:14] hmm I think I failed to do this fwiw [19:14] Does the TB have any further questions or comments on the main body of the document - excluding the appendices? Can I take the current text to be the TB's draft position, for wider consultation? [19:14] I was generally fine with it during my last read through, so you can consider me being +1 on it [19:15] oh to have git diff for google docs [19:15] It is still subject to change subject to feedback of course. [19:15] But I would like to present it as the TB's starting point. [19:15] I reviewed it and I'm fine with moving forward with the main text [19:16] we (as desktop) have concerns about the appendix C - requirement A though [19:16] rbasak from the last meeting when I mentioned testing I thought we were going to add something about that as well... but I am struggling to remember the the specifics [19:16] so I think that is going to need more discussion, but as you said it's an appendix and not what we focus on atm [19:17] That rings a bell. Maybe I missed an edit. [19:17] https://irclogs.ubuntu.com/2023/05/30/%23ubuntu-meeting.html#t19:33 [19:17] maybe my fault for not recording that in the actions, sorry :/ [19:18] in the list of exceptions for specific packages, I think it should list what architectures the package is supposed to be available on. For Ubuntu desktop installer, it doesn't say *which* other arches we're missing a runtime on; and both amd64 and arm64 are important for desktop flavors. But this is also all in an appendix [19:18] otherwise, skimming the recent differences, it looks fine to me [19:18] amurray: ah yes, sorry. This is related to the process for eg. adding a new snap, right? Not about making changes to an existing one? [19:19] yes, we ended up saying that the package should have a review by some other (MIR-like) team [19:19] OK. That's also for the snap appendix, right? [19:19] I would prefer it to be in the main document as a proposed requirement [19:20] OK. Let me take an action to get that in. I think I was supposed to do it last time, like you said. [19:20] Then I'll check with you out of band. [19:20] in fact the stability point is also requirement A and not only in the appendix... [19:20] ie like an issue/bug tracker, we/I also want it to be reviewed to approve that it is "maintainable" / "testable" etc when updates need to be done [19:20] If amurray is happy with that edit, then I'll go ahead and open wider discussion. Does that sound OK? [19:21] do we want to take 'Proposed' out of the 'Proposed requirement'? [19:21] Sure, if you like. The whole thing is proposed :) [19:21] right that's what I was thinking [19:22] re stability - having a requirement that something remain stable is not the same as saying "it needs to be testable" so that if/when someone has to do an update we can have some confidence that it is not going to break on delivery to users [19:22] made that edit [19:22] seb128: it is requirement A in the main body, but I think it should remain there as the baseline, with an exception either in general or specifically for snaps under some more specific criteria. Doesn't matter which since snaps are the only approved "third party type" at the moment. [19:23] amurray: you're talking about QA? [19:23] ack [19:23] yep [19:24] I'm not sure we're in a position to be able to dictate anything about QA really, because we already delegate that to snap publishers entirely. What sort of assurance do you think we could define? [19:24] This might fit under: [19:24] Requirement C: the package maintainer agrees to maintain the package for the lifetime of the Ubuntu release. [19:25] What that means exactly, including QA, is down to them I think. [19:25] my personal preference would be that for each approved third-party package, there should be a documented test plan that can be exercised by other Ubuntu members if / when they need to make an update to the package in question [19:25] Or, maybe we could require as part of snap-MIR for some QA plan to be written down and committed to by the snap maintainer? [19:26] OK. I think that would be great to have. [19:26] But I'm concerned it might be too much friction. [19:26] I don't feel strongly about whether or not the requirement should be in there initially though. [19:27] having firefox document a test plan for their binary releases would not mean it's particularly practical for Ubuntu to reproduce it [19:27] hm, it's an interesting idea, but seeing that we don't require such things for packages we have in the archive, seems a bit 'much' [19:27] IMHO MIR process goes a bit further actually by requiring automated testing, which is de-facto a test plan. [19:28] MIR also give the alternative option of a manual testplan [19:28] it does? eew [19:28] :) [19:29] (most desktop applications don't have automated testing because we don't have a good framework to automate UI testing in our infra) [19:29] I don't think this is too much to ask - we want everyone to have confidence in whatever third-party packages they are consuming from us [19:30] my real concern here is that someday the security team will have to patch one of these snaps and we won't have a good way to test the thing at the end of that before releasing it [19:30] it's a bit unfair to require more there than what we require today for things we ship by default though no? [19:30] I wrote this down here so we don't forget it's outstanding: https://docs.google.com/document/d/1apUKR4gtOrfPGCWmtoebaQUhoy-fG8Cyo3VKJyhnpD0/edit#heading=h.v2cstw9iikqj [19:31] thanks rbasak [19:31] We also need to remember that other flavors might want to pre-install their own snaps too, and they can build out of universe - so even if in main we do have some requirements, we need to make sure that we don't go instantly over-board. But I do agree the more emphasis we can have on quality, the better [19:32] Anyway, it's certainly an idea worth thinking about [19:32] OK I think this needs some further discussion. Let me document the ideas there at least, before we try to establish consensus [19:33] So leave that with me for now. [19:33] does that need resolved before we push this out for wider discussion? [19:33] I was about to ask that. [19:33] Can we do both simultaneously? [19:33] It's fine for there to be some documented loose ends IMHO [19:33] #action rbasak to follow up on finding consensus on question of test plans for third party apps [19:33] ACTION: rbasak to follow up on finding consensus on question of test plans for third party apps [19:33] I need to restructure the docs a bit to make the status clearer [19:34] is that also an action? [19:34] But once done I think we can open wider discussion if others are OK with it. [19:34] +1 [19:34] vorlon: yes, sure [19:34] +1 [19:34] #action rbasak to restructure the third-party repo doc to make the status clearer [19:34] ACTION: rbasak to restructure the third-party repo doc to make the status clearer [19:34] are those the actions for now? [19:35] And maybe another for me to open wider discussion? [19:35] Now that you wrote that I'm not sure what the others +1'd :) [19:35] #action rbasak to open wider discussion on third-party repo policy [19:35] ACTION: rbasak to open wider discussion on third-party repo policy [19:35] :) [19:35] Everyone happy with that plan? [19:35] +1 [19:35] That's a bad question. [19:35] Any objections to that plan? :) [19:35] yes, thanks :) [19:35] sorry I mean, yes I am happy, no objection from me [19:35] :-P [19:35] excellent, moving on [19:36] #done seb128 to resend the 'core teams governance' email to the public techboard list [19:36] I'll reply shortly [19:36] per previous discussion, it's now on the rest of us to replay our responses [19:36] I don't know how soon I'll get to that on my part, so maybe an action there [19:36] I just did today, sorry for the delay but I was waiting on getting ack from people I'm quoting in the email (since there was some extract from private emails) [19:37] #action rbasak, vorlon, amurray to replay their responses to Key Ubuntu teams discussion [19:37] ACTION: rbasak, vorlon, amurray to replay their responses to Key Ubuntu teams discussion [19:37] #topic Scan the mailing list archive for anything we missed (standing item) [19:37] #link https://lists.ubuntu.com/archives/technical-board/2023-June/thread.html [19:37] nothing there which we haven't already addressed [19:38] #topic Check up on community bugs and techboard bugs [19:38] #link https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard [19:38] clear [19:38] #link https://bugs.launchpad.net/techboard [19:38] two bugs that are also both captured in our actions [19:38] #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) [19:39] I believe the rotation is chair: sil2100, backup: amurray [19:39] ACK o/ [19:40] #agreed next meeting chair: sil2100, backup: amurray [19:40] AGREED: next meeting chair: sil2100, backup: amurray [19:40] #topic AOB [19:40] anything else for today? [19:40] nothing from me [19:40] Nothing from me. [19:41] Thank you for chairing! [19:41] And thank you everyone for the productive discussion. [19:41] #endmeeting [19:41] Meeting ended at 19:41:51 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-06-13-19.01.moin.txt [19:41] thanks, all! [19:41] Thanks vorlon! Thanks everyone o/ [19:42] thanks vorlon [19:42] thanks!