20:03 #startmeeting Ubuntu Technical Board 20:03 Meeting started at 20:03:47 UTC. The chair is cyphermox. Information about MeetBot at https://wiki.ubuntu.com/meetingology 20:03 Sure 20:03 Available commands: action, commands, idea, info, link, nick 20:03 I was just looking up previous action items 20:04 #chairs cyphermox rbasak 20:04 I think everything was carried 20:04 probably 20:04 And I also had " 20:04 rbasak will send out the private removal emails 20:04 " 20:04 which I've done 20:04 thanks :) 20:04 #topic Action Review 20:05 * cyphermox formal ratification of third party seeded snap security policy, depends on: (rbasak, 19:06) 20:05 I think we were going to collapse this all into the ongoing (pad) discussion on seeded snap requirements, but I failed to update the agenda 20:08 ok 20:08 so carry? 20:09 no longer double-booked. 20:09 I'd say yes 20:09 * cyphermox 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) 20:09 carry-over 20:10 (I think at this point it makes sense for the above to be dependent on finalizing the ratification of the policy) 20:10 I agree, I'll update the agenda to that effect 20:10 * cyphermox 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 (rbasak, 19:08) 20:10 Yes, so the draft is started, but still not finished! 20:11 alright, thanks sil2100 :) 20:11 So carry over please ;) 20:11 (https://wiki.ubuntu.com/OEMArchive for the record) 20:11 * cyphermox Review and leave feedback on the first version of the preamble and three first requirements https://pad.ubuntu.com/third-party-repository-requirements (all of the TB) (sil2100, 20:09) 20:12 I had left my feedback months ago 20:13 hmmm, yeah, I didn't leave my comment on the actual preamble 20:13 Well, it's about the formal preamble, that's quite new 20:13 I'll re-review for myself too 20:13 * cyphermox Discuss DMB inactivity expiration policy (all of the TB) (sil2100, 20:27) 20:13 cyphermox: yes, but I'd like more feedback please now that I've actually started drafting the proposed final wording after having gathered everyone's opinions 20:13 We were working on the rules themselves, but then rbasak started working on the actual wording - I need to sit down on that 20:13 oops sorry 20:13 arewe continuing on using a pad for this, vs perhaps moving it to a google doc? 20:14 +1 for a Google doc, if we're doing final wording 20:14 I'm happy to move it to a Google Doc if you all think it's worth doing that. I used the pad because I thought it'd be more open, but it turns out to be really hard to use the pad effectively 20:14 OK I'll do that thanks 20:15 ok, what about the DMB inactivity policy? 20:15 and perhaps, TB inactivity, since I was so kind to just disappear for three months myself :/ 20:16 That's resolved for the current situation, but longer term I think the TB needs to decide what to do if the situation recurs 20:16 ok 20:16 That's not urgent though. 20:18 should we discuss it now, or take that back to the mL? 20:18 We need someone to drive it on the ML :-/ 20:18 (IMHO) 20:20 yep 20:22 Or, it gets left until it actually comes up I guess. 20:23 ok 20:25 +1 20:26 alright. that's a drop then, for all intents and purposes 20:26 I still think the retention policy is a good idea 20:26 postpone until it comes up 20:26 ah 20:27 FTR, I basically agree with what the DMB wants to do. I think we just need to refine the detail about the interaction between the DMB and the TB to actually do the removal, and communicate with the DMB members being removed, etc. 20:27 sil2100: does that mean you want to drive the discussion on the list? 20:27 vorlon: eh, I'm worried that I have so many DMB + the TB action that it might not be driven to completion 20:27 I would love to, since I think this policy will be helpful 20:28 I agree that it would be helpful but am wary of committing myself to driving it 20:28 I think, given recent events, it would be best if I didn't drive this one. 20:28 (but I will provide input, etc) 20:28 Ok, so maybe please assign it to me and if I can't make it by the next meeting, we'll try finding someone else 20:31 alright 20:31 Thanks o/ 20:31 (sil2100) Discuss if the membership to ~ubuntu-archive should be managed by the Technical Board, and if yes: consider new timezone-diverse additions to the team (i.e. bdmurray). 20:32 I thought ~ubuntu-archive managed their own membership, and various existing members were added that way? 20:33 Yeah, I think that's correct, I think the action item is invalid! 20:33 err okay :P 20:33 Sorry about that ;p 20:33 moving on 20:33 OK 20:33 Definition of our third party repository policy. See https://lists.ubuntu.com/archives/technical-board/2021-July/002562.html and https://pad.ubuntu.com/third-party-repository-requirements 20:34 To be clear, if members of ~ubuntu-archive want to change things, then consulting with the TB is probably worthwhile. 20:34 But unless there's some reason we'd probably leave it as-is 20:34 Sure, but I think that's all up to the ubuntu-archive admins - I think as of right now there is no actions required 20:35 *action 20:35 OK 20:36 On the pad, I'll take the action to move it to a Google Doc then, update everyone on the TB with the link and ask for further feedback there. 20:36 yes 20:37 I don't think there's anything else on this, except to say that I really want to make progress on this and need to know that you're happy with the direction it's going in since I'll need the final wording to be agreed later. 20:39 #topic Mailing list review 20:39 Not sure if this is the right moment to bring this up: 20:39 there was only one email there, not sure if it had been actioned yet, DMB allow 20:40 But there was the e-mail from Marc? 20:41 Should we think about starting an election? 20:41 yeah, I suppose there is that too 20:41 We need the CC to do that I think. 20:41 cyphermox: do you want to give us a gmail address for you to use for the google doc? I think that will make comment etc. tracking saner so it's not accidentally "anonymous" 20:41 At least that's what's happened in the past. 20:41 vorlon: I will share it, yes 20:41 Unless you want to do like the DMB and have us run the TB election admin ourselves 20:42 I guess someone will have to take the AI to contact the CC in that case 20:42 historically it's been the CC 20:42 I will take that action 20:42 Thanks! 20:42 I'm doing the best I can to refer election management either up or down so I don't have to do it ;-) 20:42 I will contact the CC to trigger the election 20:43 Now that I've done the DMB one twice I've got the process in my head and don't mind doing it. But it'd probably be better if the CC can. 20:43 #topic Check up on community bugs 20:43 there are no open bugs 20:43 \o/ 20:43 #topic Select a chair for the next meeting 20:43 One AOB item please 20:43 sure 20:44 rbasak, it's your turn next to chair I think? 20:44 I chaired last week! But sure. 20:44 Uh, last time - two weeks ago. 20:44 unless someone wants to save you 20:44 I don't mind. 20:44 if I'm not double-booked I can do it again 20:44 okay, moving on 20:44 #topic AOB 20:45 Is everyone happy with my response on the question of DMB nomination eligibility? 20:45 It wasn't my intention to speak for the TB but it seems to have been taken that way. 20:46 (I also fail to see how asking the TB for a vote is any different to asking the DMB for a vote in terms of "formality" but there you go) 20:48 I'm trying to skim the mailing list thread quickly, since I don't remember this 20:48 Today on ubuntu-devel@ 20:48 the old one on tech-board 20:48 Oh right sorry 20:49 giving the timing I can well understand why I personally didn't reply to it :) 20:50 I agree that ~ubuntu-sru-developers is narrower than what we expect DMB to assess and therefore isn't a good fit 20:50 also wonder why anyone on the ~ubuntu-sru-developers team who was actually interested in running for DMB wouldn't also just get core-dev first 20:51 I would be fine to vote on this if necessary 20:51 btw. do we have this documented somewhere besides the ML? 20:51 Like, who can actually be nominated for a seat for the DMB 20:52 Following that ML post, I put it in my call for nominations 20:53 Additionally I wrote it up in https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Running_a_DMB_election - not specifically the rule, but it does link to my call for nomination email as an example to use as a basis. 20:53 Ah, ok! 20:53 Noted ;) 20:53 I can document the rule explicitly there if you think it'd be helpful. 20:55 vorlon: thanks, but also, are you happy with the position that it's for the TB to decide eligbility and not the DMB? That's what ddstreet seems to be complaining about as "all this formality". I don't see any other reasonable option though. 20:55 (and same question to the others) 20:57 rbasak: yes, TB should decide this, not DMB 20:58 Does anyone on the TB want to support any change to the status quo? 20:58 If not then I'm done - thank you for clarifying. 20:58 hm, it's hard to say from my POV, I don't have a strong opinion. But I think that since the TB does manage the DMB membership (besides the fact of startin elections), I think it makes sense to assume that the TB is the one setting the base rules 20:58 I wanted to make sure that this is handled openly since I'm dancing a fine line of ensuring that the election is done properly :-/ 20:59 But as said, I'm of no strong opinion here 21:06 okay, so do we need a vote or do we already have consensus on the topic? 21:07 I don't think anyone has called for a vote here. 21:07 So I think we're good. Thanks! 21:07 o/ 21:08 Does that mean "I'd like to raise something" or "bye"? :) 21:08 haha 21:08 ...that is a bit confusing, yes! But the latter ;) 21:09 alrighty then, any other other business? 21:09 #endmeeting