[14:29] <cpaelzer> slowly lighting the MIR campfire
[14:29] <eslerm> o/
[14:30] <cpaelzer> double booked, I hope attention is enough to do this well ...
[14:30] <cpaelzer> shout if I fail :-)
[14:30] <cpaelzer> #startmeeting Weekly Main Inclusion Requests status
[14:30] <meetingology> Meeting started at 14:30:38 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[14:30] <meetingology> Available commands: action, commands, idea, info, link, nick
[14:30] <cpaelzer> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe )
[14:30] <cpaelzer> #topic current component mismatches
[14:30] <cpaelzer> Mission: Identify required actions and spread the load among the teams
[14:30] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[14:30] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[14:31] <cpaelzer> the old jaraco that we know for openstack
[14:31] <slyon> o/
[14:31] <cpaelzer> not more yet for https://launchpad.net/ubuntu/noble
[14:31] <sarnold> good morning
[14:31] <cpaelzer> #topic New MIRs
[14:31] <cpaelzer> Mission: ensure to assign all incoming reviews for fast processing
[14:31] <didrocks> o/ (I’m exceptionnally here this week)
[14:31] <cpaelzer> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir
[14:31] <cpaelzer> happy, I hope that means no sick-at-home being the reason didrocks
[14:32] <cpaelzer> we have a bunch (much less than expected due to massaging dependencies and function) perl items that need review
[14:32] <cpaelzer> 5 of them are waiting for a reviewer
[14:32] <cpaelzer> I need TBH that I can not take any before the sprint
[14:33] <cpaelzer> is any of you having enough capacity to take one for this or next week?
[14:33] <didrocks> I can take a second one (I couldn’t due to the sprint and final rush do the one I had previous one) and do it before EOW
[14:33] <slyon> I can take one
[14:33] <didrocks> next week, I don’t want to commit with the sprint
[14:33] <slyon> There's a list of priorities for those MIRs in https://bugs.launchpad.net/ubuntu/+source/libmail-dmarc-perl/+bug/2023971/comments/11
[14:33] -ubottu:#ubuntu-meeting- Launchpad bug 2023971 in libmail-dmarc-perl (Ubuntu) "[MIR] libmail-dmarc-perl" [Undecided, Incomplete]
[14:34] <cpaelzer> of those https://bugs.launchpad.net/ubuntu/+source/libregexp-common-perl/+bug/2039563 and https://bugs.launchpad.net/ubuntu/+source/libnet-ip-perl/+bug/2039456 are already assigned
[14:34] -ubottu:#ubuntu-meeting- Launchpad bug 2039563 in libregexp-common-perl (Ubuntu) "[MIR] libregexp-common-perl (as a libmail-dmarc-perl dependency)" [Undecided, New]
[14:34] -ubottu:#ubuntu-meeting- Launchpad bug 2039456 in libnet-ip-perl (Ubuntu) "[MIR] libnet-ip-perl (as libmail-dmarc-perl dependency)" [Undecided, New]
[14:35] <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/libnet-idn-encode-perl/+bug/2038929 has been reviewed and back on miriam until action has been taken
[14:35] -ubottu:#ubuntu-meeting- Launchpad bug 2038929 in libnet-idn-encode-perl (Ubuntu) "[MIR] libnet-idn-encode-perl (as libmail-dmarc-perl dependency)" [Undecided, Incomplete]
[14:35] <cpaelzer> let us distribute a few more as we have capacity
[14:35] <cpaelzer> slyon: didrocks: could you just pick one each from https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir ?
[14:35] <slyon> So let me take libfile-sharedir-perl ?
[14:35] <cpaelzer> sure
[14:36]  * slyon assigned himself
[14:36] <didrocks> I will take libemail-abstract-perl
[14:36] <slyon> didrocks: that's one of the lower priority ones..
[14:36] <didrocks> abstract and perl in the same package name, what could go wrong? :)
[14:36] <didrocks> ah
[14:36] <cpaelzer> in terms of prio according to the post would be better https://bugs.launchpad.net/ubuntu/+source/libclass-inspector-perl/+bug/2039569
[14:36] <didrocks> I got the list the other way around
[14:36] -ubottu:#ubuntu-meeting- Launchpad bug 2039569 in libclass-inspector-perl (Ubuntu) "[MIR] libclass-inspector-perl (libfile-sharedir-perl dependency as libmail-dmarc-perl dependency)" [Undecided, New]
[14:36] <didrocks> good to me, picking that one
[14:36] <cpaelzer> ok, we'll slowly churn through all of those
[14:36] <didrocks> if I can stay away from any abstraction, that’s a bonus (somewhat :p)
[14:36] <cpaelzer> and let us just be happy it seems there won't be ~50 of them
[14:37] <didrocks> until debian sync starts, we’ll see…
[14:37] <cpaelzer> ok, going on ...
[14:37] <cpaelzer> #topic Incomplete bugs / questions
[14:37] <cpaelzer> Mission: Identify required actions and spread the load among the teams
[14:38] <cpaelzer> #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir
[14:40] <slyon> I think there's nothing actionable here
[14:40] <slyon> the libnet-idn-encode-perl MIR might be dropped by changing to another dependency, which is already in main
[14:40] <cpaelzer> agreed
[14:40] <didrocks> agreed
[14:40] <cpaelzer> leaving the check of that to miriam
[14:40] <cpaelzer> #topic Process/Documentation improvements
[14:41] <cpaelzer> Mission: Review pending process/documentation pull-requests or issues
[14:41] <cpaelzer> #link https://github.com/canonical/ubuntu-mir/pulls
[14:41] <cpaelzer> #link https://github.com/canonical/ubuntu-mir/issues
[14:41] <cpaelzer> the renovate auto branch is handled
[14:41] <cpaelzer> we can close #38
[14:41] <slyon> +1
[14:42] <cpaelzer> all the others are long term cases waiting for the right time
[14:42] <cpaelzer> nothing to act
[14:42] <cpaelzer> #topic MIR related Security Review Queue
[14:42] <cpaelzer> Mission: Check on progress, do deadlines seem doable?
[14:42] <cpaelzer> Some clients can only work with one, some with the other escaping - the URLs point to the same place.
[14:42] <cpaelzer> #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=%5BMIR%5D&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir
[14:42] <cpaelzer> #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=[MIR]&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir
[14:42] <cpaelzer> Internal link
[14:42] <cpaelzer> - ensure your teams items are prioritized among each other as you'd expect
[14:42] <cpaelzer> - ensure community requests do not get stomped by teams calling for favors too much
[14:42] <cpaelzer> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
[14:43] <cpaelzer> slyon: seeing https://bugs.launchpad.net/ubuntu/+source/libemail-simple-perl/+bug/2031491 in there
[14:43] -ubottu:#ubuntu-meeting- Launchpad bug 2031491 in libemail-simple-perl (Ubuntu) "[MIR] libemail-simple-perl ( libemail-mime-perl dependency as libmail-dmarc-perl dependency)" [Undecided, Incomplete]
[14:43] <eslerm> not much news, we've been discussing perl fuzzing and Andrei is writing documentation tips
[14:43] <cpaelzer> slyon: was my explanation of not being a dup enough that we mark it new?
[14:44] <eslerm> this work will begin after the sprint, we'll likely have several dedicated people involved
[14:44] <eslerm> a deadline by NN has been agreed to with Miriam
[14:45] <cpaelzer> ok, thanks eslerm
[14:45]  * slyon reading context on libemail-simple-perl
[14:46] <slyon> Okay. I requested a differentiation of the two stacks. You came to the conclusion that they should be considered non-duplicates.
[14:46] <cpaelzer> yes
[14:46] <slyon> So having that in the security queue seems correct. right?
[14:46] <cpaelzer> it is like mutt and thunderbird :-) but for perl
[14:47] <slyon> ACK. wfm
[14:47] <cpaelzer> thanks, I updated the case
[14:47] <slyon> But I guess we still need security ACK for the other/new stack
[14:47] <cpaelzer> #topic Any other business?
[14:47] <sarnold> ha :)
[14:47] <cpaelzer> yes we still need security, it is only back to "new" not to and "final and done" state
[14:48] <sarnold> my apologies for not getting the scheduling survey done :( it's been busy that it's always fallen out of my mental todo list
[14:48] <didrocks> you are not the only one :)
[14:48] <cpaelzer> exactly
[14:48] <eslerm> it would be nice to meet up during the sprint
[14:48] <didrocks> but yeah, would be great to settle that for post-sprint
[14:48] <sarnold> and i'll send my apologies for next week
[14:48] <cpaelzer> ha eslerm, that was just what I wanted to ask
[14:48] <eslerm> :)
[14:48] <cpaelzer> should I schedule something in Riga engineering week?
[14:49] <cpaelzer> give me an agenda item or two worth to see you over more than just a beer at a bar :-)
[14:49] <sarnold> I'd very much like us all to get together and have it be scheduled so that we don't wind up with yet another sprint with only half of us getting together
[14:49] <slyon> Yes, please. Maybe we can just use the usual MIR meeting slot, as we've done in the past?
[14:49] <didrocks> I think it’s been quite some time we haven’t done that, it would be great, but quick, the calendars are filing up quite fast :p
[14:49] <didrocks> as long as it’s booked to not be double booked, I’m fine
[14:50] <sarnold> yes :( so much double and triple-booking :(
[14:50] <cpaelzer> yes
[14:50] <cpaelzer> let me have a look right now ...
[14:50] <didrocks> but the MIR meeting slot is already booked for me in my case :/
[14:51] <cpaelzer> them original slot is gone for me too
[14:52] <cpaelzer> friday after lunch or before lightning talks is available to all of us
[14:53] <eslerm> after lunch sounds nice, in case people wanted to meet for lunch as well
[14:53] <cpaelzer> yep
[14:53] <didrocks> sounds good to me :)
[14:53] <slyon> wfm
[14:54] <cpaelzer> sent
[14:54] <cpaelzer> thanks
[14:54] <cpaelzer> anything else?
[14:54] <sarnold> thanks! \o/
[14:54] <sarnold> nothing else from me
[14:55] <cpaelzer> neither from me
[14:55] <didrocks> thanks!
[14:55] <slyon> nothing
[14:55] <cpaelzer> ok
[14:55] <slyon> thanks cpaelzer, all!
[14:55] <cpaelzer> next week some of us will be at the planning sprint already
[14:55] <cpaelzer> might be rather silent here
[14:55] <cpaelzer> whoever is left can lead the lonely meeting then
[14:55] <cpaelzer> bye
[14:55] <cpaelzer> #endmeeting
[14:55] <meetingology> Meeting ended at 14:55:31 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-10-24-14.30.moin.txt
[14:55] <eslerm> thanks all o/
[14:55] <sarnold> thanks cpaelzer, all :)
[18:59]  * vorlon waves
[18:59] <rbasak> o/
[19:00] <amurray> o/
[19:01] <seb128> hey
[19:02] <amurray> hey seb128
[19:02] <amurray> looks like sil2100 is not around - I'll kick things off then
[19:02] <vorlon> sil2100 was under the weather today
[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> ACTION: 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> ACTION: seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage
[19:06] <amurray> ACTION: 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> ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification
[19:06] <amurray> ACTION: 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> ACTION: rbasak to follow up on finding consensus on question of test plans for third party apps
[19:07] <amurray> ACTION: 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> ACTION: rbasak to open wider discussion on third-party repo policy
[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] <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> 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:10] <amurray> ACTION: 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> ACTION: 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] -ubottu:#ubuntu-meeting- Launchpad bug 2015921 in techboard "Inactive DMB members can stall DMB progress" [Undecided, Triaged]
[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
[19:53] <meetingology> Meeting ended at 19:53:09 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-10-24-19.03.moin.txt
[19:53] <rbasak> Thanks all!
[19:53] <seb128> thanks!
[19:53] <vorlon> amurray, rbasak, seb128: thanks!
[19:53] <amurray> indeed - thanks everyone