=== lan3y is now known as Laney === Laney is now known as laney === WaVeR` is now known as WaVeR [14:32] good morning [14:33] hello o/ [14:34] I think c_paelzer is out at a sprint. So maybe I can run the meeting again. [14:34] #startmeeting Weekly Main Inclusion Requests status [14:34] Meeting started at 14:34:33 UTC. The chair is slyon. Information about MeetBot at https://wiki.ubuntu.com/meetingology [14:34] Available commands: action, commands, idea, info, link, nick [14:34] Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage [14:34] #topic current component mismatches [14:34] Mission: Identify required actions and spread the load among the teams [14:34] #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [14:34] #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg [14:35] -release looks all fine [14:35] I'm loving the new 'known false positives' bug :) [14:35] :) [14:36] -proposed: libwacom -> python-libevdev is a new component mismatch.. [14:36] the source is a desktop package, so I'd like to ask didrocks to investigate [14:36] (who apparently isn't here today, so maybe postpone to next week) [14:37] that's getting mighty close to feature freeze [14:38] right. but I think promotions to main are usually not cosidered feature freeze critical (unless they explicitly are for enabling new features, of course) [14:39] inetutils looks interesting, never saw such mismatch before (dependency on itself)... [14:39] it seems to be related to telnet, which is a foundations package, so I'll try to investigate what's going on there. [14:39] oh wow, heh I missed that.. [14:40] also gsasl -> libgssglue seems new, it's foundations, too. I'll ask jawn-smith about that, who did the other mutt related MIRs [14:40] #topic New MIRs [14:40] Mission: ensure to assign all incoming reviews for fast processing [14:41] #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:41] we have bug #1986591 [14:41] Bug 1986591 in fstrm (Ubuntu) "[MIR] fstrm" [Undecided, New] https://launchpad.net/bugs/1986591 [14:41] sarnold: you had some opinion on this apparently? [14:42] slyon: mostly I wanted to push back against adding these packages to main in focal [14:42] slyon: as far as I know there's no business demand for this feature; I'm completely fine with community-driven feature requests, but doing a ton of work for it on a two year old release doesn't seem productive to me [14:43] I agree. And I think we should postpone this to next week, too. So we can discuss the case with more MIR team members. [14:43] so, leaving it open and moving on. [14:43] #topic Incomplete bugs / questions [14:43] Mission: Identify required actions and spread the load among the teams [14:43] #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:44] bug #1963707 is still pending the "hw available for testing?" question [14:44] Bug 1963707 in libqrtr-glib (Ubuntu) "[MIR] libqrtr-glib" [Low, Incomplete] https://launchpad.net/bugs/1963707 [14:44] aha, nice, I wondered why it was back :) [14:45] bug #1909665 is still incomplete (does not have a MIR template). It should probably be assigned to whoever is working on this [14:45] Bug 1909665 in lua5.4 (Ubuntu) "[MIR] ibus-libpinyin dependencies" [Low, Incomplete] https://launchpad.net/bugs/1909665 [14:45] lua transition, is that a foundations thing? [14:46] no. it's server [14:47] at least lua5.3 is subscribed to ~ubuntu-server [14:48] okay, having read more of the bug I think you're right, ubuntu-server, and it feels like they're pretty close :) [14:48] yes. so let's keep it open until ready, maybe next week. [14:49] comment #13 does suggest it might be a few months -- is it fine to leave it in this list until then? or should we move it to ubuntu-server so they don't lose track of it? [14:49] I don't want to be hectoring about it :) but I also would hate for it to be overlooked when it feels close [14:49] sarnold: that's a good idea! We should assign ubuntu-server [14:50] done [14:50] thx [14:50] bug #1986592 is incomplete. I'll assign it to the reporter, to make it disappear from our list until ready [14:50] Bug 1986592 in openconnect (Ubuntu) "[MIR] network-manager-openconnect, openconnect" [Undecided, Incomplete] https://launchpad.net/bugs/1986592 [14:50] good idea [14:50] I have stronger opinions here [14:50] we do not need every single popularly used vpn in main [14:52] sarnold: could you put that as a comment into the LP bug report? [14:52] openconnect sounds like it may be better than the proprietary stuff it is meant to replace, but it almost always interops with horrible old proprietary junk that's a decade behind the times, or more [14:53] to start a discussion before the reporter puts lots of effort in preparing the MIR templates [14:54] #topic MIR related Security Review Queue [14:54] Mission: Check on progress, do deadlines seem doable? [14:54] #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:55] sarnold: any news on the security reviews? [14:55] mark esler has been an absolute machine chewing through MIRs :) I'm feeling so much better about this list today than eg two weeks ago [14:56] I'm concerned about nullboot; chrisccoulson's time is limited and in very high demand [14:56] anything we can help with wrt nullboot? to speed things up? cc juliank ^ [14:56] all the smart-card related packages are shared security/desktop, and so long as our security certifications team is short-staffed I can't imagine those getting traction [14:58] nothing comes to mind; I'll ask chris when he thinks he might be able to get to it, but as usual, there's almost always a steady-stream of high-priority Interrupt-Driven sorts of needs.. [14:59] slyon: I asked about hardware for libqrtr-glib. I don't think the desktop team has access to this hardware directly. We need to check with Canonical's hardware certification team [14:59] jbicha: thanks for the update. we'll keep tracking the bug as "Incomplete" until there is a testing opportunity [15:01] sarnold: wrt nullboot: I cannot find a definitive deadline in the MIR report. but it seems to be entangled with enabling FDE functionallity, which might bring up some discussions during the next sprint [15:01] definintely :) [15:01] #topic Any other business? [15:01] none here [15:02] we had very little attendence during today's meeting, which is sad :( [15:02] thanks for being here and updating things with me sarnold! [15:02] #endmeeting [15:02] Meeting ended at 15:02:41 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-08-16-14.34.moin.txt [15:02] thanks slyon :) [15:03] oh, heh, the meeting actually has properly declined notes from folks who didn't show (as well as folks who can't show :) [15:03] indeed! I didn't see that before :) [15:04] and it's summer time, people might be on vacation [15:04] *nod* [15:08] slyon: we're shipping nullboot to CVM already I think, would be good to get it done [15:08] slyon: chris wrote all security bits of it, so he can't really review it I suppose [15:09] lol [15:09] while that's a strong vote in favor of it being done right, that also complicates finding someone to review this :) [15:10] you could say chris reviewed the bits already :D [18:54] cyphermox: hi, are you here today? :) [19:00] o/ [19:00] * vorlon waves [19:00] sil2100 is OoO today and declined the meeting in his google calendar, so I think we're dependent on cyphermox's IRC client being a pointer to an actually present cyphermox for us to be quorate [19:05] cyphermox_: hi? [19:05] Hi [19:05] hurray [19:05] Almost there, on my phone [19:09] Are we quorate? I do not have access to backlog [19:10] cyphermox_: just rbasak, vorlon, and you :) [19:10] Oh yay [19:10] #startmeeting [19:10] Meeting started at 19:10:23 UTC. The chair is vorlon. Information about MeetBot at https://wiki.ubuntu.com/meetingology [19:10] Available commands: action, commands, idea, info, link, nick [19:10] #topic Action review [19:11] ACTION: (everyone) review the Ubuntu Backports Team Charter for ratification [19:11] Still pending I think. [19:12] I recently stumbled across this in one of my browser tabs; I guess this is still a current action we need to follow through on, so carry-over [19:12] ACTION: (everyone) formal ratification of third party seeded snap security policy (finalize wording on the Google Doc) [19:12] rbasak: is that an accurate current action, I think we were waiting for you to finalize drafting? [19:12] #action (everyone) review the Ubuntu Backports Team Charter for ratification [19:12] ACTION: (everyone) review the Ubuntu Backports Team Charter for ratification [19:14] I did have a draft that I proposed quite a long time ago to the ubuntu-backports@ list, but haven't really had a response. [19:14] I'll need to take it up with the backporters team to find a solution. [19:15] rbasak: sorry, I was asking about the snap security policy ratification [19:15] Oh. Right. I'm still working on that. I have been making some progress in the doc. [19:15] should I replace this action with one for you? [19:15] Sure [19:15] Assuming everyone is happy with the rest of the doc? [19:16] #action rbasak to finalize third-party seeded snap security policy [19:16] ACTION: rbasak to finalize third-party seeded snap security policy [19:16] I'm working on analysing/assessing/speaking to stakeholders of existing snaps [19:16] I was happy with the doc last I looked :) cyphermox_ had you reviewed it recently? [19:16] Yes, I was happy with it as well [19:17] excellent [19:17] ACTION: vorlon to circle around with store, snapcraft, et all, and revise the snap source revision policy to be more clear with regards to rebuildability and GPL compliance. (rbasak, 19:06) [19:18] I've been postponing this until the draft is finalized because I think it will be subsumed; I'll carry over [19:18] #action vorlon to circle around with store, snapcraft, et all, and revise the snap source revision policy to be more clear with regards to rebuildability and GPL compliance. [19:18] ACTION: vorlon to circle around with store, snapcraft, et all, and revise the snap source revision policy to be more clear with regards to rebuildability and GPL compliance. [19:18] 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:18] sil2100 not here so carrying over [19:18] #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:18] 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:18] ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification [19:18] rbasak: still current? [19:19] Yes that's on me still [19:19] #action rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification [19:19] ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification [19:19] ACTION: cyphermox to follow up with the CC regarding the TB nominations and election [19:19] cyphermox: ? [19:21] cyphermox: are you still on point for talking to the CC about TB elections? [19:21] Yes [19:21] I had, but I guess we'll need to contact again [19:22] ok [19:22] #action cyphermox to re-ping the CC regarding the TB nominations and election [19:22] ACTION: cyphermox to re-ping the CC regarding the TB nominations and election [19:22] that's it for previous actions [19:22] #topic Definition of our third party repository policy. See https://docs.google.com/document/d/1apUKR4gtOrfPGCWmtoebaQUhoy-fG8Cyo3VKJyhnpD0/edit [19:23] that's on the agenda, but is covered by the previous carry-over action for rbasak [19:23] so I don't think we need to discuss this? [19:23] Yeah it's the same item [19:23] #topic Scan the mailing list archive for anything we missed (standing item) [19:24] "New Official Flavor Process Issues" [19:24] I think this is on me from the last meeting, and I've been working on this. [19:24] #link https://lists.ubuntu.com/archives/technical-board/2022-July/002648.html [19:24] I see you just shared a google doc with me, thanks for that [19:24] I've shared a draft with the TB and Release Team admins (vorlon and sil2100) [19:25] Also for ItzSwirlz and Eickmeyer [19:25] I'd welcome it being shared with other members of the release team if you think it's far enough along to do so, more eyes -> shallow bugs etc [19:26] (I need a Google account address for Eickmeyer) [19:26] (to make me less of a bottleneck) [19:26] Sure - I just need the addresses. The Canonical members I can find. [19:26] Any other release team members interested, please give me addresses. [19:27] currently all active release team members are Canonical employees, unfortunately :/ [19:27] (tumbleweed dips in and out occasionally) [19:27] Not laney [19:27] he's a member of the launchpad team but not active so I don't think it's worth chasing him on this [19:27] Oh, "active" [19:28] But I don't have a list of active members [19:28] right, I'm saying if you grab the canonical folks on there it's close enough [19:28] I've just added everyone I have addresses for as it's not up to me to say who is active and who isn't. [19:29] thanks [19:29] #link https://lists.ubuntu.com/archives/technical-board/2022-August/002661.html [19:29] there's also this, which is an invitation for TB members to go to Prague in November [19:29] I will be in Prague the week prior, but not able to stick around for the Ubuntu Summit [19:29] I will be there. [19:30] rbasak: for the summit? [19:30] I believe sil2100 will also be there. [19:30] Yes [19:30] ah, nice [19:30] cyphermox: do you want to go? :) [19:30] anyway we don't have to settle that here [19:30] Yeah i think so [19:31] cyphermox_: nice! I guess you will follow up with Mauro then? [19:31] I'll need to look into it [19:31] Yes I will [19:31] \o/ [19:31] fwiw from earlier, I had reached out to the CC as well on various elections coming up, I will reping them as well. [19:32] Fallen: excellent, thank you (and hello!) [19:32] Cool [19:32] o/ [19:32] #topic Check up on community bugs (standing item) [19:32] https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard is empty [19:33] #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) [19:33] that looks to be sil2100, with cyphermox_ as backup [19:34] Sounds good to me and I shall have my IRC solider before then [19:34] #agreed next chair: sil2100, backup: cyphermox_ [19:34] AGREED: next chair: sil2100, backup: cyphermox_ [19:34] #topic AOB [19:34] teh one thing I thought might be AOB was actually covered wrt the mailing list review [19:35] Great. Thanks for chairing! [19:35] we do have Fallen here who is Canonical's new manager of the Community Team [19:35] not sure if he has anything he wants to ask us today, as he was looking to connect :) [19:36] I've gone through my notes and I think I have a good start to get things rolling. I do have a few things I could chat about [19:37] we can probably adjourn the meeting and stick around to chat? [19:37] My first question might be answered, I was wondering how the TB tracks their larger projects - does this happen via the LP link in ubuntu-community? [19:37] Sure! [19:37] #endmeeting [19:37] Meeting ended at 19:37:38 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-08-16-19.10.moin.txt [19:37] cyphermox_, rbasak: thanks! [19:38] Yes, that and mailing list [19:38] Fallen: I don't recall ever using the bug link for larger TB-initiated projects, that's generally an entry point for others assigning things to us [19:38] (often administrative things, like setting up packagesets in Launchpad for the Ubuntu archive) [19:39] I think https://wiki.ubuntu.com/TechnicalBoardAgenda and the mailing list is really how things are tracked over time [19:39] Does the TB even have larger projects? [19:39] well the snap policy question has been ongoing for a while [19:39] Usually I'd expect larger projects to be done by delegated teams [19:39] Well we have some of these long term documentation things like the third parhy policy [19:39] Yes that's probably the largest thing [19:40] I suppose then the answer is that these things are tracked through action items or other standing items in our agenda [19:40] Some of these translate to huge mailing list threads [19:40] Documentation was my primary thought. Generally though I think it would be great if there is a thing we can point to to show people "this is what is currently working on" [19:41] That would be useful. [19:41] "We're working on a way to better track what we're working on" [19:43] Heh so true :D It might also help move things along a bit quicker, to me if there is a list like this it encourages me to put effort onto the council work that I volunteer on. [19:43] there was a bit of a longer-term project https://lists.ubuntu.com/archives/technical-board/2021-June/002560.html [19:43] It seems a launchpad project might be the historically correct way to do this, but I'm also open to other systems. Maybe something to think about until the next TB meeting? [19:45] I don't know how ingrained the use of ubuntu-community is or how many places there might be documentation pointing people to use that for TB bugs; but it certainly has been an issue in the past that we don't have a clean way to get launchpad email notifications for our ubuntu-community bugs [19:46] so maybe a separate LP project would be useful, with a committment to continue tracking the existing bug list and whenever we see things there, make sure folks are pointed to the new project and that we fix any documentation? [19:47] +1 [19:47] vorlon: the problem is that ordinary people can't assign an ubuntu-community bug to ~techboard [19:47] (which was the official process) [19:47] unfortunately I adjourned the meeting so we can't record actions ;P but I can post to the mailing list suggesting this, to make sure we're all on board before I go changing things in LP [19:48] rbasak: oh, was assignment the problem? ick [19:49] I would see this more as a tool for you all to track your work based on the input you receive from others on the list etc, so others directly assigning to ~techboard might actually be counterproductive. [19:49] +1 for an LP project BTW. Bugs seem like the simplest thing to do that will work, and a separate project will resolve the previous issue. [19:49] A separate project would solve this anwyY [19:50] Fallen: we know how to unassign ourselves and close bugs ;) [19:50] And we can track actual stuff that we're committing to using a Triaged state or similar. [19:50] Now we just need to bikeshed the name? [19:51] yep - on the mailing list please ;-) [19:51] Fallen: anything else? fwiw I have a soft stop in 9 minutes for lunch [19:51] Heh ok, that is fair :) Sounds great! [19:51] mm lunch [19:52] Yes, one more, we can keep it brief and continue discussion soon: I wanted to talk a bit about documentation. [19:53] One thing I'd like the community and Canonical to work on is to improve the documentation about how the community can participate. In your case, also indirectly through subgroups, this might relate to some of the perks people can recieve such as MOTU, and how to become a flavor. [19:55] improvement of documentation about official flavors is in progress thanks to rbasak, as discussed earlier [19:56] Yes, very much appreciated! If I can help round up folks to support you I'm very happy to. fwiw I'm working on getting a docs frontend up similar to https://anbox-cloud.io/docs which we can use for documentation of community facing issues. [19:57] Are there any other areas that you think would be worthwhile to improve documentation on? [19:57] (fwiw though I agree with improving the documentation, I don't foresee this making a significant difference in the throughput of flavors, both because a flavor is a significant committment over time, and because we don't have infinite capacity to incorporate official flavors into the ecosystem) [19:58] well it's not specifically under the TB's purview, but I would like for the Ubuntu community collectively to do some work on consolidating and cleaning up the wiki documentation for new contributors [19:58] I agree, and I think the capacity overhead is something we should consider, and set clear expectations on. Frustrating if someone does put in the effort, but in the end the blocking factor is that we don't believe we have the capacity overhead for it. [19:58] I think it was mentioned recently that there's still some stuff referencing bzr [19:59] Yes, that was likely me in the product sprint :) [20:00] hah [20:00] Eventually decommissioning the wiki is on my wishlist! Given we are at the hour I'll leave you to the next thing, but if there are any areas of documentation directly in the TB's purview maybe we could talk about that next time. [20:01] Fallen: cheers. thanks for the chat! [20:01] Ah, interesting, I was just wondering about that given discourse and all [20:01] Likewise, thank you for the insights! [20:02] (fwiw actually decommisioning the wiki properly would be a huge project and I'm not on board with it ;) [20:03] Oh final note, you are all very much invited to #ubuntu-community-team, my team is using this for day to day work discussions, and I've also invited the CC to join :) [20:03] I will join tomorrow when I am not on my phone