19:03 <vorlon> #startmeeting
19:03 <meetingology> Meeting started at 19:03:10 UTC.  The chair is vorlon.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
19:03 <meetingology> Available commands: action, commands, idea, info, link, nick
19:03 <vorlon> #topic apologies
19:03 <vorlon> amurray sent his apologies to the list
19:03 <vorlon> and as mentioned, I expect sil2100 is indisposed due to release sprint
19:03 <vorlon> #topic action review
19:04 <vorlon> seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage
19:04 <vorlon> seb128: anything to update here?
19:04 <seb128> not from me, and I didn't see activity from the others either
19:04 <vorlon> ok, carrying over
19:04 <vorlon> #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 <vorlon> rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification
19:05 <vorlon> rbasak: ?
19:05 <rbasak> Carry over again please
19:05 <vorlon> #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 <vorlon> rbasak to follow up on finding consensus on question of test plans for third party apps
19:05 <rbasak> Same again
19:05 <vorlon> #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 <rbasak> And my third too
19:05 <vorlon> #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 <vorlon> 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 <vorlon> this appears to be in process
19:05 <seb128> I finally found some time to reach out to the teams
19:06 <vorlon> 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 <seb128> but it was only yesterday, rbasak replied for the SRU team today
19:06 <vorlon> yes
19:06 <seb128> 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 <seb128> I should perhaps have included a note about that directly
19:07 <seb128> I will follow up
19:07 <vorlon> ok
19:08 <vorlon> 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 <seb128> maybe reword slightly the action item?
19:08 <rbasak> +1
19:09 <vorlon> huh maybe the new action would also be follow-up? :)
19:09 <seb128> follow up -> continue working
19:09 <vorlon> ok
19:09 <vorlon> #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 <vorlon> and mine is also carry-over
19:09 <vorlon> #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 <vorlon> #topic Scan the mailing list archive for anything we missed (standing item)
19:11 <vorlon> 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 <vorlon> seb128: is there a discussion you want to have about this right now?
19:12 <seb128> 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 <vorlon> ok
19:12 <vorlon> #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 <vorlon> then there is also https://lists.ubuntu.com/archives/technical-board/2023-October/002767.html
19:13 <vorlon> in which rbasak asks for TB sign-off
19:13 <vorlon> while we could vote here with 3 of us, that seems better done via the mailing list IMHO?
19:13 <rbasak> But nobody replied in the ML
19:14 <seb128> I was waiting for the meeting thinking it would be easier
19:14 <seb128> I will reply on the list since that didn't work out
19:14 <rbasak> We're here, so could we just do it now?
19:15 <rbasak> 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 <rbasak> If you have questions or concerns, then we could discuss that right now.
19:15 <vorlon> 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 <seb128> I'm +1 as well
19:16 <rbasak> 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 <vorlon> if we're doing the formal signoff here let's call a vote
19:16 <rbasak> But I figured that if the TB and SRU team are both happy, then we can call it done.
19:17 <vorlon> rbasak: <shrug> 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 <rbasak> We don't have any formal definition of what requires TB sign-off :)
19:17 <vorlon> #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 <meetingology> 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 <meetingology> 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 <vorlon> +1
19:18 <meetingology> +1 received from vorlon
19:18 <rbasak> The whole ESM arrangement was done with TB members involved so I think we can assume the TB is happy with it.
19:18 <rbasak> +1
19:18 <meetingology> +1 received from rbasak
19:18 <seb128> +1
19:18 <meetingology> +1 received from seb128
19:18 <vorlon> #endvote
19:18 <meetingology> 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 <meetingology> Votes for: 3, Votes against: 0, Abstentions: 0
19:18 <meetingology> Motion carried
19:18 <rbasak> Great! Thanks.
19:18 <vorlon> that's it for mailing list
19:18 <vorlon> #topic Check up on community bugs and techboard bugs
19:19 <vorlon> #link https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard
19:19 <vorlon> 0
19:19 <vorlon> #link https://bugs.launchpad.net/techboard
19:19 <vorlon> nothing new...
19:19 <vorlon> (and both covered via outstanding actions)
19:20 <vorlon> #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members)
19:20 <vorlon> I believe next is sil2100 with amurray as backup
19:21 <seb128> ack
19:21 <vorlon> #agreed next chair: sil2100, backup: amurray
19:21 <meetingology> AGREED: next chair: sil2100, backup: amurray
19:21 <vorlon> #topic AOB
19:22 <vorlon> one little thing that might be worth mentioning here vs in a direct message
19:22 <vorlon> DMB recently approved philroche's PPU application for livecd-rootfs
19:22 <vorlon> 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 <vorlon> 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 <seb128> vorlon, it was mentioned on https://lists.ubuntu.com/archives/devel-permissions/2023-October/002350.html I think?
19:23 <rbasak> 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 <vorlon> seb128: right, TB isn't expected to be subscribed to that list? (I'm not)
19:24 <seb128> fair enough
19:24 <vorlon> 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 <rbasak> 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 <vorlon> and I just wanted to make the rest of the TB aware of this
19:25 <rbasak> doesn't review historic> this applies to things like core dev, too.
19:25 <vorlon> very true
19:25 <seb128> I was going to say that, taking the archive team as another example
19:25 <rbasak> 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 <rbasak> Although I wouldn't want to encourage uploaders to make junk uploads to keep their rights, either.
19:26 <vorlon> 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 <rbasak> That would help keep the archive secure - less attack surface for an adversary getting hold of uploaders' keys, etc.
19:27 <vorlon> 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 <vorlon> Anyway!  this isn't something I wanted to demand / propose immediate changes around, just raising awareness and food for thought
19:28 <rbasak> I'm not sure I see that distinction really, but I agree with the general principle.
19:28 <rbasak> FWIW, this sort of thing has been discussed within the DMB before. I don't remember anyone having any particular objections.
19:28 <vorlon> 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 <rbasak> We don't currently have the mechanism. Somebody would have to write the code.
19:29 <vorlon> 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 <rbasak> 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 <rbasak> Perhaps we could "downgrade" them to "Contributing Developer", and the DMB should have a lower bar on reapplication.
19:30 <vorlon> 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 <rbasak> So that they are still recognised for their previous contributions.
19:30 <vorlon> oh, one other practical implication of all of this
19:32 <vorlon> 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 <rbasak> honors packagesets> what does that mean, exactly?
19:33 <rbasak> Is it re-applying an ACL somehow?
19:33 <rbasak> Because apart from that, a packageset is just a list of packages, no?
19:33 <vorlon> 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 <vorlon> which means they sit in the queue longer until a human reviews them
19:33 <vorlon> maybe the answer is "the bot shouldn't do that"
19:33 <rbasak> I was going to say that :)
19:34 <rbasak> Can it use seeded-in-ubuntu instead perhaps?
19:34 <vorlon> well now we're getting into the weeds
19:34 <vorlon> because I have issues with the implementation of that command too :)
19:35 <vorlon> anyway, enough of this digression IMHO
19:35 <rbasak> The thing is, the DMB doesn't actively maintain packagesets
19:35 <rbasak> It's sort of difficult to do.
19:35 <rbasak> In practice they are only tweaked on request
19:35 <vorlon> yeah
19:36 <vorlon> IMHO https://ubuntu-archive-team.ubuntu.com/packagesets/mantic/ has some definitely dodgy stuff
19:37 <seb128> we should probably try to review those at some point indeed
19:37 <seb128> the ubuntugnome one for example doesn't make sense anymore
19:37 <seb128> just to pick one random example
19:38 <vorlon> would we want the TB to do that review?  DMB?  Random Ubuntu devs (maybe on the release team) proposing removals?
19:39 <seb128> 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 <vorlon> sounds fine to me
19:40 <vorlon> anyway -
19:40 <vorlon> AOB?
19:41 <rbasak> I just managed to dig up https://irclogs.ubuntu.com/2023/08/07/%23ubuntu-meeting.html#t19:24
19:41 <rbasak> This is an example of Brian noticing the mythbuntu packageset still existing
19:41 <vorlon> oh augh
19:41 <vorlon> :)
19:41 <seb128> 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 <rbasak> He got an action item to clear it up since he noticed, but I'm not sure if that was recorded properly.
19:42 <vorlon> 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 <seb128> rbasak, the action isn't listed on the wiki so it seems it wasn't recorded properly
19:44 <seb128> 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 <vorlon> sounds good
19:44 <vorlon> shall we call the meeting there?
19:44 <rbasak> Sure, thanks.
19:44 <vorlon> #endmeeting