== Meeting information == * #ubuntu-meeting meeting, started by vorlon, 10 Oct at 19:03 — 19:44 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-10-10-19.03.log.html == Meeting summary == === apologies === Discussion started by vorlon at 19:03. === action review === Discussion started by vorlon at 19:03. * ''ACTION:'' seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage (vorlon, 19:04) * ''ACTION:'' rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification (vorlon, 19:05) * ''ACTION:'' rbasak to follow up on finding consensus on question of test plans for third party apps (vorlon, 19:05) * ''ACTION:'' rbasak to open wider discussion on third-party repo policy (vorlon, 19:05) * ''ACTION:'' seb128 to continue working with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations (vorlon, 19:09) * ''ACTION:'' vorlon to write up draft guidelines for packages in the archive that download from the Internet (vorlon, 19:09) === Scan the mailing list archive for anything we missed (standing item) === Discussion started by vorlon at 19:10. * ''ACTION:'' add to next meeting agenda to have follow-up discussion on https://lists.ubuntu.com/archives/technical-board/2023-September/002763.html (vorlon, 19:12) * ''VOTE:'' sign off on UbuntuAdvantageToolsUpdates exception that "Facilities that enable access to Ubuntu Pro may be added to the main Ubuntu archive and installed by default" and "Updates shall be permitted as usual for SRUs and additionally after EoSS." (Carried) (vorlon, 19:18) === Check up on community bugs and techboard bugs === Discussion started by vorlon at 19:18. * ''LINK:'' https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard (vorlon, 19:19) * ''LINK:'' https://bugs.launchpad.net/techboard (vorlon, 19:19) === Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) === Discussion started by vorlon at 19:20. * ''AGREED:'' next chair: sil2100, backup: amurray (vorlon, 19:21) === AOB === Discussion started by vorlon at 19:21. == Vote results == * [[https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-10-10-19.03.log.html#70|sign off on UbuntuAdvantageToolsUpdates exception that "Facilities that enable access to Ubuntu Pro may be added to the main Ubuntu archive and installed by default" and "Updates shall be permitted as usual for SRUs and additionally after EoSS."]] * Motion carried (For: 3, Against: 0, Abstained: 0) * Voters: vorlon, rbasak, seb128 == Action items, by person == * rbasak * rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification * rbasak to follow up on finding consensus on question of test plans for third party apps * rbasak to open wider discussion on third-party repo policy * seb128 * seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage * seb128 to continue working with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations * vorlon * vorlon to write up draft guidelines for packages in the archive that download from the Internet * **UNASSIGNED** * add to next meeting agenda to have follow-up discussion on https://lists.ubuntu.com/archives/technical-board/2023-September/002763.html == People present (lines said) == * vorlon (85) * rbasak (38) * seb128 (24) * meetingology (18) == Full log == 19:03 #startmeeting 19:03 Meeting started at 19:03:10 UTC. The chair is vorlon. Information about MeetBot at https://wiki.ubuntu.com/meetingology 19:03 Available commands: action, commands, idea, info, link, nick 19:03 #topic apologies 19:03 amurray sent his apologies to the list 19:03 and as mentioned, I expect sil2100 is indisposed due to release sprint 19:03 #topic action review 19:04 seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage 19:04 seb128: anything to update here? 19:04 not from me, and I didn't see activity from the others either 19:04 ok, carrying over 19:04 #action seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage 19:04 * meetingology seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage 19:04 rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification 19:05 rbasak: ? 19:05 Carry over again please 19:05 #action rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification 19:05 * meetingology rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification 19:05 rbasak to follow up on finding consensus on question of test plans for third party apps 19:05 Same again 19:05 #action rbasak to follow up on finding consensus on question of test plans for third party apps 19:05 * meetingology rbasak to follow up on finding consensus on question of test plans for third party apps 19:05 And my third too 19:05 #action rbasak to open wider discussion on third-party repo policy 19:05 * meetingology rbasak to open wider discussion on third-party repo policy 19:05 seb128 to follow up with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations 19:05 this appears to be in process 19:05 I finally found some time to reach out to the teams 19:06 seb128: I was surprised that you were emailing the AAs about this because you are an admin in that team, and I thought in a previous round of discussion I suggested that you should take the point on drafting? 19:06 but it was only yesterday, rbasak replied for the SRU team today 19:06 yes 19:06 vorlon, I do plan to follow up/work on that but I decided to email anyway to give the context to everyone in the team 19:07 I should perhaps have included a note about that directly 19:07 I will follow up 19:07 ok 19:08 is there a new action that should be recorded now that this is in progress? the follow-up is done but of course there's nothing to record on the wiki yet 19:08 maybe reword slightly the action item? 19:08 +1 19:09 huh maybe the new action would also be follow-up? :) 19:09 follow up -> continue working 19:09 ok 19:09 #action seb128 to continue working with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations 19:09 * meetingology seb128 to continue working with SRU, AA, Release, Backporters and Security teams to document their membership process and link to it from https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations 19:09 and mine is also carry-over 19:09 #action vorlon to write up draft guidelines for packages in the archive that download from the Internet 19:09 * meetingology vorlon to write up draft guidelines for packages in the archive that download from the Internet 19:10 #topic Scan the mailing list archive for anything we missed (standing item) 19:11 so in https://lists.ubuntu.com/archives/technical-board/2023-September/002763.html seb128 says he would like to "put the topic back on the agenda for the next TB meeting" 19:11 seb128: is there a discussion you want to have about this right now? 19:12 vorlon, let's postpone to next time to let a chance for the concerned team to follow up on the emails I just sent, and also to have more TB members around? 19:12 ok 19:12 #action add to next meeting agenda to have follow-up discussion on https://lists.ubuntu.com/archives/technical-board/2023-September/002763.html 19:12 * meetingology add to next meeting agenda to have follow-up discussion on https://lists.ubuntu.com/archives/technical-board/2023-September/002763.html 19:13 then there is also https://lists.ubuntu.com/archives/technical-board/2023-October/002767.html 19:13 in which rbasak asks for TB sign-off 19:13 while we could vote here with 3 of us, that seems better done via the mailing list IMHO? 19:13 But nobody replied in the ML 19:14 I was waiting for the meeting thinking it would be easier 19:14 I will reply on the list since that didn't work out 19:14 We're here, so could we just do it now? 19:15 If you're both happy, then we could just call it done, and I can reply to the ML and speak for the TB in approving. 19:15 If you have questions or concerns, then we could discuss that right now. 19:15 rbasak: I'm happy, and additionally I don't see the fact that this is done after EoSS to be something that structurally requires TB signoff 19:16 I'm +1 as well 19:16 I was unclear if that aspect was for the TB or SRU team to decide - it's unclear that the SRU team has any say after EoSS at all. 19:16 if we're doing the formal signoff here let's call a vote 19:16 But I figured that if the TB and SRU team are both happy, then we can call it done. 19:17 rbasak: the fact that there is a difference between standard support and esm support, and the fact that we keep the archive open past the end of standard support, is also not anything that required TB signoff 19:17 We don't have any formal definition of what requires TB sign-off :) 19:17 #vote sign off on UbuntuAdvantageToolsUpdates exception that "Facilities that enable access to Ubuntu Pro may be added to the main Ubuntu archive and installed by default" and "Updates shall be permitted as usual for SRUs and additionally after EoSS." 19:17 Please vote on: sign off on UbuntuAdvantageToolsUpdates exception that "Facilities that enable access to Ubuntu Pro may be added to the main Ubuntu archive and installed by default" and "Updates shall be permitted as usual for SRUs and additionally after EoSS." 19:17 Public votes can be registered by saying +1, -1 or +0 in channel (for private voting, private message me with 'vote +1|-1|+0 #channelname') 19:18 +1 19:18 +1 received from vorlon 19:18 The whole ESM arrangement was done with TB members involved so I think we can assume the TB is happy with it. 19:18 +1 19:18 +1 received from rbasak 19:18 +1 19:18 +1 received from seb128 19:18 #endvote 19:18 Voting ended on: sign off on UbuntuAdvantageToolsUpdates exception that "Facilities that enable access to Ubuntu Pro may be added to the main Ubuntu archive and installed by default" and "Updates shall be permitted as usual for SRUs and additionally after EoSS." 19:18 Votes for: 3, Votes against: 0, Abstentions: 0 19:18 Motion carried 19:18 Great! Thanks. 19:18 that's it for mailing list 19:18 #topic Check up on community bugs and techboard bugs 19:19 #link https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard 19:19 0 19:19 #link https://bugs.launchpad.net/techboard 19:19 nothing new... 19:19 (and both covered via outstanding actions) 19:20 #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) 19:20 I believe next is sil2100 with amurray as backup 19:21 ack 19:21 #agreed next chair: sil2100, backup: amurray 19:21 AGREED: next chair: sil2100, backup: amurray 19:21 #topic AOB 19:22 one little thing that might be worth mentioning here vs in a direct message 19:22 DMB recently approved philroche's PPU application for livecd-rootfs 19:22 and the packageset stuff seemed to all happen behind the scenes, which is fine - I assume rbasak switched hats DMB->TB and got it done? 19:23 anyway I also gave him direct commit rights on the git repo (because it's not git-ubuntu yet cough cough) which caused me to notice that rcj who is no longer actively involved in Ubuntu development still has livecd-rootfs ppu rights as well 19:23 vorlon, it was mentioned on https://lists.ubuntu.com/archives/devel-permissions/2023-October/002350.html I think? 19:23 Yes I just did the PPU addition wearing my TB hat, without bothering with the process for a bug, because I'm on both teams. 19:23 seb128: right, TB isn't expected to be subscribed to that list? (I'm not) 19:24 fair enough 19:24 so anyway, this made me aware that DMB doesn't review historic PPU rights or packagesets to confirm they're still relevant and appropriate 19:24 We only created the bug process to request PPU changes because we were struggling to get the changes done otherwise. I think we should keep that option open (eg. if a TB+DMB member is unavailable or retires) but didn't think it was mandatory to use. 19:24 and I just wanted to make the rest of the TB aware of this 19:25 doesn't review historic> this applies to things like core dev, too. 19:25 very true 19:25 I was going to say that, taking the archive team as another example 19:25 It has been suggested that perhaps we should expire people from those teams if they haven't uploaded for some period of time. 19:26 Although I wouldn't want to encourage uploaders to make junk uploads to keep their rights, either. 19:26 fwiw it feels to me that ppu should have >= scrutiny to the general uploader teams; because someone who has passed muster for core-dev might perhaps dip in and out of involvement over time while still having passed the bar for technical knowledge of Ubuntu as a whole 19:27 That would help keep the archive secure - less attack surface for an adversary getting hold of uploaders' keys, etc. 19:27 whereas someone who has only been approved for PPU of a particular package(set), and has NOT been involved in the maintenance of it... well? 19:27 Anyway! this isn't something I wanted to demand / propose immediate changes around, just raising awareness and food for thought 19:28 I'm not sure I see that distinction really, but I agree with the general principle. 19:28 FWIW, this sort of thing has been discussed within the DMB before. I don't remember anyone having any particular objections. 19:28 rbasak: well in this specific case I would say that if rcj actually exercised his PPU rights on livecd-rootfs I would immediately be checking if his account was compromised (or, er, if he was personally compromised) 19:28 We don't currently have the mechanism. Somebody would have to write the code. 19:29 also while security is always a concern, I also want to balance that against not causing folks in the broader Ubuntu developer community feel like they are being cast off if they have had less time to be involved 19:29 I'm not keen on singling out individuals FWIW. If we want to implement this kind of policy, we should do it, but we should define the criteria and apply it at once for whomever it's met. 19:30 Perhaps we could "downgrade" them to "Contributing Developer", and the DMB should have a lower bar on reapplication. 19:30 of course. I'm just using him as an example of why we might want a policy, because I'm familiar enough with the specifics there 19:30 So that they are still recognised for their previous contributions. 19:30 oh, one other practical implication of all of this 19:32 the release team bot that auto-approves non-frozen packages in the unapproved queue ... honors packagesets. So having stale packagesets wastes some developer time during release freezes 19:32 honors packagesets> what does that mean, exactly? 19:33 Is it re-applying an ACL somehow? 19:33 Because apart from that, a packageset is just a list of packages, no? 19:33 rbasak: the bot assumes that packages that are part of a packageset, but not seeded in main, should not be blindly waved through the queue 19:33 which means they sit in the queue longer until a human reviews them 19:33 maybe the answer is "the bot shouldn't do that" 19:33 I was going to say that :) 19:34 Can it use seeded-in-ubuntu instead perhaps? 19:34 well now we're getting into the weeds 19:34 because I have issues with the implementation of that command too :) 19:35 anyway, enough of this digression IMHO 19:35 The thing is, the DMB doesn't actively maintain packagesets 19:35 It's sort of difficult to do. 19:35 In practice they are only tweaked on request 19:35 yeah 19:36 IMHO https://ubuntu-archive-team.ubuntu.com/packagesets/mantic/ has some definitely dodgy stuff 19:37 we should probably try to review those at some point indeed 19:37 the ubuntugnome one for example doesn't make sense anymore 19:37 just to pick one random example 19:38 would we want the TB to do that review? DMB? Random Ubuntu devs (maybe on the release team) proposing removals? 19:39 having the devs proposing removals might make sense, I'm unsure the TB or DMB have enough context on the specifics of each set 19:40 sounds fine to me 19:40 anyway - 19:40 AOB? 19:41 I just managed to dig up https://irclogs.ubuntu.com/2023/08/07/%23ubuntu-meeting.html#t19:24 19:41 This is an example of Brian noticing the mythbuntu packageset still existing 19:41 oh augh 19:41 :) 19:41 vorlon, on the cleaning of packagesets should we take a note / action item to maybe at least start a discussion about it on a project list tbd? 19:41 He got an action item to clear it up since he noticed, but I'm not sure if that was recorded properly. 19:42 seb128: I don't want to take the action because it's low-priority, and I don't want it to be "everybody's responsibility" either :) 19:43 rbasak, the action isn't listed on the wiki so it seems it wasn't recorded properly 19:44 vorlon, fair enough, I keep a note on my backlog of things I might try to do one day if nobody beats me to it 19:44 sounds good 19:44 shall we call the meeting there? 19:44 Sure, thanks. 19:44 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)