19:03 <amurray> #startmeeting Ubuntu Technical Board
19:03 <meetingology> Meeting started at 19:03:03 UTC.  The chair is amurray.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
19:03 <meetingology> Available commands: action, commands, idea, info, link, nick
19:03 <amurray> #topic Apologies
19:03 <amurray> sil2100 is out
19:03 <amurray> #topic Action review
19:04 * amurray seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage
19:05 <seb128> to carry over I guess?
19:05 <amurray> yeah - I don't have any update on this myself either
19:06 <amurray> #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 <rbasak> Carry over please
19:06 <amurray> #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 <rbasak> Carry over please
19:07 <amurray> #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 <rbasak> Carry over please
19:08 <amurray> #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 <seb128> to carry over, there were no news since the last meeting
19:09 <amurray> #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 <vorlon> carry over please
19:10 <amurray> #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 <amurray> #topic Scan the mailing list archive for anything we missed (standing item)
19:11 <amurray> ubuntu-advantage-tools SRU exception policy review
19:11 <amurray> #link https://lists.ubuntu.com/archives/technical-board/2023-October/002767.html
19:11 <rbasak> I think that one is done from the TB perspective.
19:11 <rbasak> There's an ongoing discussion with the release team.
19:11 <amurray> oh sorry yes I see now
19:11 <amurray> nothing else on the mailing list then that I can see
19:12 <amurray> #topic Check up on community bugs and techboard bugs
19:12 <amurray> #link https://bugs.launchpad.net/ubuntu-community/+bugs?field.assignee=techboard
19:12 <amurray> #link https://bugs.launchpad.net/techboard
19:12 <amurray> nothing new here either that I can see
19:13 <amurray> although I do wonder about the "Inactive DMB members can stall DMB progress" bug
19:13 <amurray> #link https://bugs.launchpad.net/techboard/+bug/2015921
19:13 <amurray> is this still seen as an issue from the DMB side?
19:13 <rbasak> That's related to my action item above
19:14 <rbasak> It's not currently an issue, so that's why I haven't prioritised it.
19:14 <rbasak> But I should sort it out so it's done before it becomes an issue again.
19:14 <amurray> ah cool - fair enough - thanks rbasak
19:14 <amurray> #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members)
19:15 <amurray> looks like it's me :)
19:15 <amurray> #agreed next meeting chair: amurray, backup: rbasak
19:15 <meetingology> AGREED: next meeting chair: amurray, backup: rbasak
19:15 <amurray> #topic AOB
19:16 <vorlon> last meeting we had also deferred, due to low attendance, seb128's discussion topic from the mailing list
19:16 <vorlon> wrt freeze exception request reviews
19:17 <amurray> #link https://lists.ubuntu.com/archives/technical-board/2023-September/002763.html
19:18 <amurray> is that the one?
19:18 <vorlon> yes
19:18 <seb128> right, but to be honest I'm unsure how to move that forward at this point
19:18 <vorlon> well there are two responses I want to make
19:18 <rbasak> 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 <seb128> 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 <seb128> 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 <vorlon> 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 <seb128> ah, that's good to read (a public reply to say so would also have been nice)
19:21 <vorlon> 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 <vorlon> is for
19:23 <vorlon> 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 <vorlon> 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 <vorlon> and file the bugs at that point for discussion and review
19:25 <vorlon> 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 <seb128> that's orthogonal to the issue imho
19:26 <seb128> 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 <seb128> the bug in question was late and not important
19:26 <vorlon> 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 <seb128> the problem isn't the urgency, is the difficulty to get a reply or to find an active member to engage with
19:28 <seb128> 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 <seb128> 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 <vorlon> 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 <vorlon> and I have nothing further to say on that
19:31 <vorlon> 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 <amurray> 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 <amurray> so I don't feel the TB needs to step in at this stage personally
19:34 <seb128> let's dismiss it then, at least I've tried
19:35 <rbasak> 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 <rbasak> 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 <rbasak> There may be other issues, such as process.
19:35 <rbasak> Further, adding more members means inconsistency in decisions, unless you also tackle that. As we've seen in the SRU team.
19:35 <rbasak> 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 <rbasak> 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 <seb128> well, I think I will just give up at this point but thanks
19:38 <seb128> I do think it would be better to have a release team with time and capacity to be actively engaged and responsive
19:38 <seb128> 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 <rbasak> actively engaged and responsive> In responding to FFe requests, or more broadly?
19:39 <rbasak> AIUI, Steve only talked about FFes.
19:39 <seb128> FFe is one time of the cycle where it's more visible but not only
19:39 <rbasak> And acknowledged a gap that has now been addressed.
19:40 <rbasak> OK, but FFe response time is the only objective complaint that I've seen, unless I'm missing something?
19:41 <seb128> my initial emails have example of uploads stuck in the unapproved queue for several days around milestones
19:41 <seb128> which community contributor and flavor leads also found problematic
19:41 <rbasak> 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 <seb128> 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 <seb128> just to see if that's seen as a real problem by the other project members
19:43 <rbasak> I don't see how that would be constructive. The release team need objective feedback, not subjective feelings.
19:43 <seb128> but I'm unsure it would help eithe
19:43 <seb128> how would you get objective feedback?
19:44 <seb128> I've collected a number of specific examples and situations in my original email
19:44 <seb128> from coredev, flavors, etc
19:44 <rbasak> 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 <rbasak> That gives the release team an opportunity to respond and fix the issue.
19:45 <seb128> my issue there is that the release team agree they are understaffed
19:45 <seb128> ok, they can't onboard more than 1 new member by cycle max
19:45 <seb128> but check https://launchpad.net/~ubuntu-release/+members#active
19:45 <rbasak> 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 <seb128> thanks, I will think about it
19:46 <seb128> I just feel like I'm not able to get anywhere, because it's easy to just dismiss concerns
19:46 <rbasak> 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 <seb128> my worry is that the situation is just going to drive away the remaining contributors we have
19:47 <seb128> and no metrics is going to tell us that until we have no community left
19:47 <rbasak> 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 <seb128> ok, well let's wrap the discussion on that note
19:49 <amurray> fair enough - thanks for the candour folks - any other items anyone wants to raise?
19:49 <rbasak> 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 <seb128> 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 <seb128> amurray, not from me
19:53 <amurray> #endmeeting