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 * vorlon 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 * meetingology 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 * vorlon 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 * vorlon 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 * meetingology seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage 19:10 * vorlon 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 * meetingology 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 * vorlon 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 * meetingology rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification 19:13 * vorlon 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 * meetingology 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 * meetingology 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 * meetingology 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 * meetingology 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