19:01 #startmeeting Technical Board 19:01 Meeting started at 19:01:04 UTC. The chair is seb128. Information about MeetBot at https://wiki.ubuntu.com/meetingology 19:01 Available commands: action, commands, idea, info, link, nick 19:01 #topic Action Review 19:02 ups 19:02 #topic Apologies 19:02 I don't see any on the list/wiki 19:02 Lukasz doesn't seem to be online though 19:03 anyway, let's move one 19:03 * vorlon waves 19:03 #topic Action Review 19:03 * seb128 amurray to follow up with backporters team on Mattia's draft charter proposal 19:03 amurray, did you get a reply since the previous meeting? 19:03 No - I've sent two emails to the backporters team asking them to ack mattia's proposal but had no response still 19:04 :-/ 19:04 :-( 19:04 At the last meeting I said this: 19:04 It'd be nice to see a conclusion on this. I wonder if it would be appropriate to set a deadline at some point, and if no reply then we just use the current draft and call it done. I wouldn't mind it being long eg. months, but it'd be nice to have _some_ end point. 19:04 I'm +1 with that 19:04 We've already adjusted the draft to their suggestion, dropping what I had originally proposed. 19:05 also +1 19:05 Could we agree that this draft becomes final at some future date now, and encourage the backporters team to engage with us if they disagree? 19:05 I agree - how about I send one more follow-up later today and stipulate that if we get no response within another 2 weeks (that would be over 1 month since my original email asking for their ack) then this will become final 19:05 eg. two months from today, so 30 July. 19:05 Sure. 19:06 I think that should be the default. We want the involved teams to be on board with what we rule, but if they're not going to engage, it's the TB who has the authority here 19:06 I'm easy on the actual date as long as we set one :) 19:06 I was going to suggest start of July, seems similar timeframe 19:06 Sounds like we're all on the same page, so as amurray is driving I suggest he sets the date as he feels appropriate. 19:06 +1 19:07 sure - I prefer going with say 2 weeks to avoid this dragging on much longer 19:07 Sure 19:08 so June 13 ? 19:08 FWIW, we should also work with some of the other teams to establish some similar documentation. I'm not trying to single out the backporters team here! In the past few years, questions have arisen on the scope of the DMB's role, as well as AAs. 19:09 I suggest June 12th - that way it falls just before the next TB meeting 19:09 +1 19:10 Though, to be clear, I don't think it should take a further TB meeting to agree. We're agreeing it now :) 19:10 (but I welcome further discussion at a TB meeting should it arise) 19:10 indeed - but this way at that meeting we have a clear outcome with any luck 19:11 #agreed amurray to send one more follow-up later today to the backporters team and stipulate that if we get no response before June 12th then this will become final 19:11 AGREED: amurray to send one more follow-up later today to the backporters team and stipulate that if we get no response before June 12th then this will become final 19:11 also means that if there is any feedback given on the current draft we can quickly ratify those changes 19:12 seb128: o/ 19:12 k, let's move on? 19:12 rbasak, yes? 19:12 Minor point: "if we get no response before" -> that sounds like if they respond, then it won't become final. 19:12 how do I edit an agreed? :p 19:13 But I think we just agreed to make it final regardless, on 12 June, unless the TB (and only the TB) decide otherwise before that date. 19:13 You can use #undo 19:13 #undo 19:13 Removing item from minutes: AGREED 19:13 Then #agreed something else 19:13 thanks 19:14 #agreed amurray to send one more follow-up later today to the backporters team and stipulate that we set June 12th as the limit for changes to the draft unless the TB decides otherwise 19:14 AGREED: amurray to send one more follow-up later today to the backporters team and stipulate that we set June 12th as the limit for changes to the draft unless the TB decides otherwise 19:15 better? 19:15 Sure 19:15 Thanks 19:15 thanks! 19:15 moving on 19:15 * seb128 seb128 to help draft an exception to the "must build on all architectures" requirement for snaps 19:15 I'll discuss the status of the draft in a bit. 19:15 But we're a bit blocked on this now :-/ 19:16 sorry, I've still been struggling with finding time for those items but rbasak started editing which pushed me to go back to it now 19:16 * seb128 seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage 19:16 similar 19:16 * seb128 rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification 19:16 Carry this please - I've been focused on the other thing 19:16 * seb128 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:17 Carry again I guess, as he's not here 19:17 Lukasz is not around today so that's another carry over 19:17 #topic Scan the mailing list archive for anything we missed (standing item) 19:17 I see some emails from amurray :-P 19:17 nothing recent on the list 19:17 lol 19:17 #topic Check up on community bugs and techboard bugs 19:18 Oh, did we lose the progress item on the third party repository requirements doc in general? I'd like to discuss that please. 19:18 same 19:19 rbasak, I was expecting that it come as an AOB since we don't have a specific item on the agenda for it 19:19 ack 19:19 but yes we should add it back as an action 19:19 #info No new community bug activity 19:19 #topic Select a chair for the next meeting 19:20 next would be vorlon and if we follow the ordering on the launchpad page Lukasz as a backup 19:21 #info vorlon will chair next, with sil2100 as backup 19:21 * vorlon nods 19:21 #topic third party repository requirements status update 19:21 rbasak, ^ 19:22 I have been working on the doc and I think it's ready. Apart from the appendices and the wording of the "build on all architectures exception" for the desktop packages that I think, we agree we need. 19:22 fwiw I have another topic for AOB after this 19:22 Next, I'd like to publish this for wider feedback. 19:22 Before I do that, could the TB please review the main body of the document and check you're happy with it? 19:22 Perhaps we could give all TB members an opportunity to do that before our next meeting? 19:22 sounds good to me 19:22 rbasak: so I noticed there is nothing in the document regarding testability- ie. how do we integrate a seeded snap with britney? 19:23 And unless there are any further comments from the TB, I'll present that as the TB's draft position, pending further feedback. 19:23 amurray: I'm not sure I follow 19:24 do we want to stipulate that a seeded snap must be able to be tested / have some tests that can be run to ensure it is "stable" before being released? 19:24 I think we should definitely do those things. But I'm not sure it should be within the scope of this doc - just as we leave the specifics of how to test debs up to Ubuntu developers. 19:25 For example a package can be a deb in the Ubuntu archive with no tests whatsoever - that's currently permitted, even if it's not best practice. 19:25 well we have a MIR process, it sort of opens the question of it should apply to snaps that we want seeded 19:25 Currently the MIR team may decide to permit something in main without tests though, without involvement of the TB. 19:26 So in my mind, for a seeded snap, we're leaving that kind of decision to the Ubuntu developer making the change (in the seed, presumably). 19:26 It's a good question though. 19:27 I don't want to be too specific here - but I do want to make sure that we can maintain quality for any third party packages and I see testing as a big part of that 19:27 Do you think we should require something? And if so, would we require this for debs as well? 19:27 amurray: I see your concern addressed by "Proposed requirement C: the package maintainer agrees to maintain the package for the lifetime of the Ubuntu release" already 19:27 And the paragraph that says "the precise meaning of "maintain", is enforced by trust only" 19:28 IOW - we agree that this is important, but we aren't dictating the specifics 19:28 agreed w/ rbasak on this 19:28 but should a pre-installed snap get a +1 from the MIR team? 19:29 I like that idea but think we should discuss it with the MIR team first to make sure they're comfortable taking on that duty 19:30 for debs we have britney and proposed-migration that enforces a level of quality on SRUs (assuming there are dep8 tests etc) by doing automated testing - if cups becomes a snap, how do we make sure it doesn't regress on updates in future releases? a lot of stuff depends on cups so I see this as important (as a topical example) 19:30 I have no objection to a process requirement to get a review from some appropriate team 19:30 But whether that's the TB, the MIR team, or some new kind of snap-MIR team, is an open question I think. 19:31 Another option might be to start softer - by requiring such changes to be announced eg. to ubuntu-devel@ and be done before eg. feature freeze. That would allow the TB to object, but without the friction of a team requiring an approval. 19:32 Or indeed to give some notice before doing it 19:32 (or committing to doing it) 19:33 amurray: would that address your concern with your cups example? 19:33 yes I think that would work 19:34 thanks 19:34 So I'm open to any of the above. I would add it as a snap-specific policy requirement in the document (so into appendix C) 19:34 Which of those options should I take? 19:35 Personally I think I'd favour "soft, with notice" if that works for everyone? 19:35 +1 19:36 +1 19:36 +1 19:37 I'll write that up then. Thanks! 19:37 thank you :) 19:37 So, to summarise, homework for the TB: you have until the next meeting to study the doc and raise any other concerns you may have at the next meeting. 19:38 And I'll write up the "snap MIR" process (just notice) requirement into appendix C. 19:38 Any other comments on this topic for today? 19:38 none from me 19:39 #agreed the TB members have until the next meeting to review the third party repository requirements document and raise concerns 19:39 AGREED: the TB members have until the next meeting to review the third party repository requirements document and raise concerns 19:39 #topic AOB 19:39 vorlon, ? 19:40 last meeting we talked about the question of core teams governance 19:40 I had just sent an email to the private thread, which I understood folks had the action to review and reply to? 19:40 I haven't seen any responses yet :) 19:40 Oh, right 19:41 IIRC, we said we'd make it public today? 19:41 yes, in fact I wanted to mention that, it's another of those action items I failed at acting on 19:41 going back to meeting log to see what we said 19:41 would people be ok to postpone until the next meeting? 19:42 https://irclogs.ubuntu.com/2023/05/16/%23ubuntu-meeting.html#t19:10 19:42 Lukasz hasn't been around/commented on it 19:42 Sure. The thread hasn't had any activity recently. Perhaps we could agree that all further discussion on that topic can be expected to be public? 19:42 weeks were given and no objections were raised, so maybe "replay the thread but publicly" is the correct next action here? 19:42 +1 19:42 wfm 19:42 +1 19:43 in which case I guess it would be an action for seb128 to kick it off? :) 19:43 if I correctly understand what is meant by "replay" 19:43 That was my wording IIRC, and yes I think you do. 19:44 #agreed seb128 to resend 'core teams governance' email to the public techboard list 19:44 AGREED: seb128 to resend 'core teams governance' email to the public techboard list 19:44 Because if seb128 posts it, then I can provide basically the same reply I did privately, and then the public will be able to follow my position/opinion on it. 19:44 #undo 19:44 Removing item from minutes: AGREED 19:44 #agreed seb128 to resend the 'core teams governance' email to the public techboard list 19:44 AGREED: seb128 to resend the 'core teams governance' email to the public techboard list 19:44 any other AOB? 19:45 nothing from me 19:45 nor me 19:45 None from me. 19:45 ok, it's a wrap then, thanks everyone! 19:45 Thank you all for a productive meeting! 19:45 #endmeeting