19:01 <vorlon> #startmeeting
19:01 <meetingology> Meeting started at 19:01:31 UTC.  The chair is vorlon.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
19:01 <meetingology> Available commands: action, commands, idea, info, link, nick
19:01 <vorlon> #topic Apologies
19:02 <vorlon> looks like maybe we're all here?
19:02 <vorlon> apparently :)
19:02 <vorlon> #topic Action review
19:02 * vorlon amurray to follow up with backporters team on Mattia's draft charter proposal
19:03 <vorlon> is this done?  is there anything further we need to do?
19:03 <amurray> 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 <rbasak> We should have somewhere to document these
19:03 <rbasak> As we expect other teams to get some documentation too
19:04 <rbasak> I can take an action I guess, unless someone else wants to volunteer?
19:04 <vorlon> happy to let you have it
19:04 <amurray> thanks rbasak :)
19:04 <vorlon> do you want this under https://wiki.ubuntu.com/TechnicalBoard/ ? somewhere else?
19:04 <seb128> thanks rbasak!
19:05 <rbasak> I was going to put it there to start with
19:05 <amurray> sounds like a good place to me
19:06 <vorlon> #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 <vorlon> rbasak: thanks
19:06 * vorlon seb128 to help draft an exception to the "must build on all architectures" requirement for snaps
19:06 <vorlon> seb128: any news?
19:06 <seb128> yes
19:06 <seb128> we updated the document with rbasak
19:06 <rbasak> I think that action item is done.
19:06 <seb128> so that can be considered as done
19:06 <rbasak> The snap appendix needs a general cleanup but I'd like to push on with the main body first.
19:08 <vorlon> #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 <vorlon> how about this?
19:08 <rbasak> It sounded like there were still some loose ends on this?
19:09 <amurray> yeah - I added a suggestion for this - there's some feedback from seb128 and kenvandine that I need to look over still
19:10 <vorlon> carry-over, then?
19:10 <sil2100> Yes please, I'm looking through it right now
19:10 <vorlon> #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 <vorlon> sil2100: ?
19:11 <sil2100> vorlon: still didn't have time to finalize the docs, only the 'start' of the draft here https://wiki.ubuntu.com/OEMArchive
19:11 <sil2100> I know what to write, but still require some time. So sadly another carry over
19:11 <vorlon> #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 <vorlon> rbasak: ?
19:13 <rbasak> Carry over please, sorry
19:13 <vorlon> #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 <rbasak> I trust that the TB members have done their homework? :)
19:14 <vorlon> hmm I think I failed to do this fwiw
19:14 <rbasak> 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 <sil2100> I was generally fine with it during my last read through, so you can consider me being +1 on it
19:15 <vorlon> oh to have git diff <range> for google docs
19:15 <rbasak> It is still subject to change subject to feedback of course.
19:15 <rbasak> But I would like to present it as the TB's starting point.
19:15 <seb128> I reviewed it and I'm fine with moving forward with the main text
19:16 <seb128> we (as desktop) have concerns about the appendix C - requirement A though
19:16 <amurray> 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 <seb128> 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 <rbasak> That rings a bell. Maybe I missed an edit.
19:17 <amurray> https://irclogs.ubuntu.com/2023/05/30/%23ubuntu-meeting.html#t19:33
19:17 <seb128> maybe my fault for not recording that in the actions, sorry :/
19:18 <vorlon> 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 <vorlon> otherwise, skimming the recent differences, it looks fine to me
19:18 <rbasak> 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 <amurray> yes, we ended up saying that the package should have a review by some other (MIR-like) team
19:19 <rbasak> OK. That's also for the snap appendix, right?
19:19 <amurray> I would prefer it to be in the main document as a proposed requirement
19:20 <rbasak> 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 <rbasak> Then I'll check with you out of band.
19:20 <seb128> in fact the stability point is also requirement A and not only in the appendix...
19:20 <amurray> 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 <rbasak> If amurray is happy with that edit, then I'll go ahead and open wider discussion. Does that sound OK?
19:21 <vorlon> do we want to take 'Proposed' out of the 'Proposed requirement'?
19:21 <rbasak> Sure, if you like. The whole thing is proposed :)
19:21 <vorlon> right that's what I was thinking
19:22 <amurray> 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 <vorlon> made that edit
19:22 <rbasak> 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 <rbasak> amurray: you're talking about QA?
19:23 <seb128> ack
19:23 <amurray> yep
19:24 <rbasak> 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 <rbasak> This might fit under:
19:24 <rbasak> Requirement C: the package maintainer agrees to maintain the package for the lifetime of the Ubuntu release.
19:25 <rbasak> What that means exactly, including QA, is down to them I think.
19:25 <amurray> 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 <rbasak> 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 <rbasak> OK. I think that would be great to have.
19:26 <rbasak> But I'm concerned it might be too much friction.
19:26 <rbasak> I don't feel strongly about whether or not the requirement should be in there initially though.
19:27 <vorlon> having firefox document a test plan for their binary releases would not mean it's particularly practical for Ubuntu to reproduce it
19:27 <sil2100> 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 <rbasak> IMHO MIR process goes a bit further actually by requiring automated testing, which is de-facto a test plan.
19:28 <seb128> MIR also give the alternative option of a manual testplan
19:28 <vorlon> it does? eew
19:28 <vorlon> :)
19:29 <seb128> (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 <amurray> 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 <amurray> 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 <seb128> it's a bit unfair to require more there than what we require today for things we ship by default though no?
19:30 <rbasak> 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 <amurray> thanks rbasak
19:31 <sil2100> 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 <sil2100> Anyway, it's certainly an idea worth thinking about
19:32 <rbasak> OK I think this needs some further discussion. Let me document the ideas there at least, before we try to establish consensus
19:33 <rbasak> So leave that with me for now.
19:33 <vorlon> does that need resolved before we push this out for wider discussion?
19:33 <rbasak> I was about to ask that.
19:33 <rbasak> Can we do both simultaneously?
19:33 <rbasak> It's fine for there to be some documented loose ends IMHO
19:33 <vorlon> #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 <rbasak> I need to restructure the docs a bit to make the status clearer
19:34 <vorlon> is that also an action?
19:34 <rbasak> But once done I think we can open wider discussion if others are OK with it.
19:34 <sil2100> +1
19:34 <rbasak> vorlon: yes, sure
19:34 <amurray> +1
19:34 <vorlon> #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 <vorlon> are those the actions for now?
19:35 <rbasak> And maybe another for me to open wider discussion?
19:35 <rbasak> Now that you wrote that I'm not sure what the others +1'd :)
19:35 <vorlon> #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 <vorlon> :)
19:35 <rbasak> Everyone happy with that plan?
19:35 <seb128> +1
19:35 <rbasak> That's a bad question.
19:35 <rbasak> Any objections to that plan? :)
19:35 <amurray> yes, thanks :)
19:35 <amurray> sorry I mean, yes I am happy, no objection from me
19:35 <rbasak> :-P
19:35 <vorlon> excellent, moving on
19:36 <vorlon> #done seb128 to resend the 'core teams governance' email to the public techboard list
19:36 <rbasak> I'll reply shortly
19:36 <vorlon> per previous discussion, it's now on the rest of us to replay our responses
19:36 <vorlon> I don't know how soon I'll get to that on my part, so maybe an action there
19:36 <seb128> 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 <vorlon> #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 <vorlon> #topic Scan the mailing list archive for anything we missed (standing item)
19:37 <vorlon> #link https://lists.ubuntu.com/archives/technical-board/2023-June/thread.html
19:37 <vorlon> nothing there which we haven't already addressed
19:38 <vorlon> #topic Check up on community bugs and techboard bugs
19:38 <vorlon> #link https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard
19:38 <vorlon> clear
19:38 <vorlon> #link https://bugs.launchpad.net/techboard
19:38 <vorlon> two bugs that are also both captured in our actions
19:38 <vorlon> #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members)
19:39 <vorlon> I believe the rotation is chair: sil2100, backup: amurray
19:39 <sil2100> ACK o/
19:40 <vorlon> #agreed next meeting chair: sil2100, backup: amurray
19:40 <meetingology> AGREED: next meeting chair: sil2100, backup: amurray
19:40 <vorlon> #topic AOB
19:40 <vorlon> anything else for today?
19:40 <amurray> nothing from me
19:40 <rbasak> Nothing from me.
19:41 <rbasak> Thank you for chairing!
19:41 <rbasak> And thank you everyone for the productive discussion.
19:41 <vorlon> #endmeeting