== Meeting information == * #ubuntu-meeting: Ubuntu Technical Board meeting, started by amurray, 24 Oct at 19:03 — 19:53 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-10-24-19.03.log.html == Meeting summary == === Apologies === Discussion started by amurray at 19:03. === Action review === Discussion started by amurray at 19:03. * ''ACTION:'' seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage (amurray, 19:06) * ''ACTION:'' rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification (amurray, 19:06) * ''ACTION:'' rbasak to follow up on finding consensus on question of test plans for third party apps (amurray, 19:07) * ''ACTION:'' rbasak to open wider discussion on third-party repo policy (amurray, 19:08) * ''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 (amurray, 19:09) * ''ACTION:'' vorlon to write up draft guidelines for packages in the archive that download from the Internet (amurray, 19:10) === Scan the mailing list archive for anything we missed (standing item) === Discussion started by amurray at 19:10. * ''LINK:'' https://lists.ubuntu.com/archives/technical-board/2023-October/002767.html (amurray, 19:11) === Check up on community bugs and techboard bugs === Discussion started by amurray at 19:12. * ''LINK:'' https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard (amurray, 19:12) * ''LINK:'' https://bugs.launchpad.net/techboard (amurray, 19:12) * ''LINK:'' https://bugs.launchpad.net/techboard/+bug/2015921 (amurray, 19:13) === Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) === Discussion started by amurray at 19:14. * ''AGREED:'' next meeting chair: amurray, backup: rbasak (amurray, 19:15) === AOB === Discussion started by amurray at 19:15. * ''LINK:'' https://lists.ubuntu.com/archives/technical-board/2023-September/002763.html (amurray, 19:17) == Action items, by person == * amurray * seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage * 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 == People present (lines said) == * amurray (40) * seb128 (35) * rbasak (27) * vorlon (16) * meetingology (9) == Full log == 19:03 #startmeeting Ubuntu Technical Board 19:03 Meeting started at 19:03:03 UTC. The chair is amurray. 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 sil2100 is out 19:03 #topic Action review 19:04 * amurray seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage 19:05 to carry over I guess? 19:05 yeah - I don't have any update on this myself either 19:06 #action seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage 19:06 * meetingology seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage 19:06 * amurray rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification 19:06 Carry over please 19:06 #action rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification 19:06 * meetingology rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification 19:06 * amurray rbasak to follow up on finding consensus on question of test plans for third party apps 19:07 Carry over please 19:07 #action rbasak to follow up on finding consensus on question of test plans for third party apps 19:07 * meetingology rbasak to follow up on finding consensus on question of test plans for third party apps 19:07 * amurray rbasak to open wider discussion on third-party repo policy 19:08 Carry over please 19:08 #action rbasak to open wider discussion on third-party repo policy 19:08 * meetingology rbasak to open wider discussion on third-party repo policy 19:09 * amurray 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 to carry over, there were no news since the last meeting 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:10 * amurray vorlon to write up draft guidelines for packages in the archive that download from the Internet 19:10 carry over please 19:10 #action vorlon to write up draft guidelines for packages in the archive that download from the Internet 19:10 * 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 ubuntu-advantage-tools SRU exception policy review 19:11 #link https://lists.ubuntu.com/archives/technical-board/2023-October/002767.html 19:11 I think that one is done from the TB perspective. 19:11 There's an ongoing discussion with the release team. 19:11 oh sorry yes I see now 19:11 nothing else on the mailing list then that I can see 19:12 #topic Check up on community bugs and techboard bugs 19:12 #link https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard 19:12 #link https://bugs.launchpad.net/techboard 19:12 nothing new here either that I can see 19:13 although I do wonder about the "Inactive DMB members can stall DMB progress" bug 19:13 #link https://bugs.launchpad.net/techboard/+bug/2015921 19:13 is this still seen as an issue from the DMB side? 19:13 That's related to my action item above 19:14 It's not currently an issue, so that's why I haven't prioritised it. 19:14 But I should sort it out so it's done before it becomes an issue again. 19:14 ah cool - fair enough - thanks rbasak 19:14 #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) 19:15 looks like it's me :) 19:15 #agreed next meeting chair: amurray, backup: rbasak 19:15 AGREED: next meeting chair: amurray, backup: rbasak 19:15 #topic AOB 19:16 last meeting we had also deferred, due to low attendance, seb128's discussion topic from the mailing list 19:16 wrt freeze exception request reviews 19:17 #link https://lists.ubuntu.com/archives/technical-board/2023-September/002763.html 19:18 is that the one? 19:18 yes 19:18 right, but to be honest I'm unsure how to move that forward at this point 19:18 well there are two responses I want to make 19:18 With my TB hat on, I think that the release team should have the opportunity to address seb128's concerns in the first instance, before the TB go any further. 19:18 I still feel like things aren't working and I see no sign of the release team having an hand on the issue 19:19 but at the same time I feel like other board members don't agree with that view so perhaps it's only me 19:19 first is to say that after this mail, we took stock within the release team and identified that the FFe request queue was a gap in our internal processes; so we set up a (light-touch) vanguard rotation to ensure they were being processed 19:20 ah, that's good to read (a public reply to say so would also have been nice) 19:21 and second, seeing this message rankled not only because it jumped over attempting to first resolve the question with the release team (pings on #ubuntu-release are not how you have a discussion about such topics, we have an ubuntu-release@ mailing list for this which was never attempted before escalating to the TB) but also because there are clearly mismatched expectations of what the FFe process 19:21 is for 19:23 the FFe process exists in part to ensure the Release Team has a healthy overview of the remaining in-flight development work for the cycle, so we can help the engineering teams make sound priority trade-offs where necessary in order to not jeopardize the release schedule or the quality of the product 19:24 if anyone has an *urgent* FFe request, I quite frankly think that represents a failure of planning, because the teams should have known, before it was urgent, what work covered by freeze exceptions they were still planning on landing 19:24 and file the bugs at that point for discussion and review 19:25 so if we want to have a longer discussion of what the SLA should be for release team reviews of FFe requests, let's have that discussion on the ubuntu-release mailing list please, and not inject the TB into it 19:26 that's orthogonal to the issue imho 19:26 or you are arguing that the release team being understaffed and onboarding one new member by year is a feature and not a bug? 19:26 the bug in question was late and not important 19:26 the issue you escalated in that email was that you didn't think the Release Team was doing an adequate job of responding to FFe requests, which is what I am addressing with my comments 19:27 the problem isn't the urgency, is the difficulty to get a reply or to find an active member to engage with 19:28 vorlon, at the time of that email you were basically the only release team member actively doing review, when you were not around things were not moving 19:28 I'm glad you are active but relying on so few people isn't sane imho, which is the issue I'm trying to resolve 19:30 I have previously made my position clear on why the understaffing of the release team, which is an undisputed problem, is not something to be solved quickly 19:30 and I have nothing further to say on that 19:31 also while I may have been the only release team member you noticed doing reviews on your bugs, it's not true that I was the only one doing reviews; but we still had a process gap wrt making sure the queue was being worked 19:33 ok, so from what I can see, whilst I acknowledge there is a perceived issue with understaffing on the release team, they have enacted a process to help with the FFe reviews going forward (being the most visible symptom) 19:34 so I don't feel the TB needs to step in at this stage personally 19:34 let's dismiss it then, at least I've tried 19:35 I think it's appropriate to leave an initial discussion on this between seb128 and the release team. But wearing no hats and acting only as an observer, I'd like to make an observation. 19:35 It doesn't necessarily follow that a perception that there isn't a sufficient response from the existing release team means that more release team members are required. 19:35 There may be other issues, such as process. 19:35 Further, adding more members means inconsistency in decisions, unless you also tackle that. As we've seen in the SRU team. 19:35 I suggest that you focus on what you perceive to be the issue in the release team's performance, and leave it to the release team to decide how they want to handle that. 19:35 If after discussion with them (I'd expect a thread on the mailing list) there is an impasse, only then would a TB escalation be appropriate. Such an escalation should focus on what it is that the release team is in your view failing to deliver, rather than presuming the solution is to add release team members. 19:37 well, I think I will just give up at this point but thanks 19:38 I do think it would be better to have a release team with time and capacity to be actively engaged and responsive 19:38 but Steve pointed out that it's not in the release team mission currently, so that would mean having a project discussion of what the release team should be 19:39 actively engaged and responsive> In responding to FFe requests, or more broadly? 19:39 AIUI, Steve only talked about FFes. 19:39 FFe is one time of the cycle where it's more visible but not only 19:39 And acknowledged a gap that has now been addressed. 19:40 OK, but FFe response time is the only objective complaint that I've seen, unless I'm missing something? 19:41 my initial emails have example of uploads stuck in the unapproved queue for several days around milestones 19:41 which community contributor and flavor leads also found problematic 19:41 To be clear, I'm not trying to disagree with your perception seb128. I am just unable to respond to it because we can only realistically address specifics when they are pointed out. 19:42 I could go do a poll in the coredev/motu set about how they feel about their interactions with the release team, especially on engagements and delay 19:43 just to see if that's seen as a real problem by the other project members 19:43 I don't see how that would be constructive. The release team need objective feedback, not subjective feelings. 19:43 but I'm unsure it would help eithe 19:43 how would you get objective feedback? 19:44 I've collected a number of specific examples and situations in my original email 19:44 from coredev, flavors, etc 19:44 I suggest you start by starting a thread on ubuntu-release@ when you have an issue that you think isn't get the response you expect from the release team. 19:44 That gives the release team an opportunity to respond and fix the issue. 19:45 my issue there is that the release team agree they are understaffed 19:45 ok, they can't onboard more than 1 new member by cycle max 19:45 but check https://launchpad.net/~ubuntu-release/+members#active 19:45 If after a few of those you're still unhappy, then you could point to those threads as concrete examples of how you think the release team is failing to meet your expectations. 19:46 thanks, I will think about it 19:46 I just feel like I'm not able to get anywhere, because it's easy to just dismiss concerns 19:46 I'm not willing to go into a discussion about understaffing or onboarding rates here, since that doesn't directly relate to performance, and your complaint seems to be about performance. As I said above, it's up to them how they want to address any performance concerns, but first they have to be concretely raised with them. 19:47 my worry is that the situation is just going to drive away the remaining contributors we have 19:47 and no metrics is going to tell us that until we have no community left 19:47 That's a valid concern, but I really think that the only way to make progress is to turn those into concrete examples eg. via the ML as above. 19:48 ok, well let's wrap the discussion on that note 19:49 fair enough - thanks for the candour folks - any other items anyone wants to raise? 19:49 OK, thanks. My final note: it's certainly not my intention to dismiss your concerns. Unfortunately I don't think they are actionable right now, and I'm trying really hard to turn this into something actionable. 19:51 rbasak, thanks, I just feel like it's an uphill battle and I'm unsure I've the energy to go forward with it atm but let's see 19:51 amurray, not from me 19:53 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)