[10:37] <cpaelzer> sarnold: slyon: eslerm_: joalif: didrocks:  today is the Ubuntu stakeholder meeting to discuss the coming cycle, I won't be able to attend :-/ Could either of you drive the meeting please?
[12:49] <slyon> cpaelzer: I can.
[12:51] <cpaelzer> thank you slyon
[14:29] <slyon> #startmeeting Weekly Main Inclusion Requests status
[14:29] <meetingology> Meeting started at 14:29:08 UTC.  The chair is slyon.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[14:29] <meetingology> Available commands: action, commands, idea, info, link, nick
[14:29] <slyon> Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe )
[14:29] <dviererbe> o/
[14:29] <slyon> Still a bit early. Let's give it a minute or two
[14:30] <slyon> #topic current component mismatches
[14:30] <joalif> o/
[14:30] <slyon> Mission: Identify required actions and spread the load among the teams
[14:31] <slyon> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[14:31] <slyon> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[14:31] <slyon> This is looking very good. *bpf* got promoted. *trace* is making nice progress, just pending some work on libtracefs
[14:31] <slyon> #topic New MIRs
[14:31] <slyon> Mission: ensure to assign all incoming reviews for fast processing
[14:32] <slyon> #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:32] <cpaelzer> I managed to be free - hello (keep going slyon and thank you!)
[14:32] <slyon> just bug #2060056 from dviererbe
[14:32] -ubottu:#ubuntu-meeting- Bug 2060056 in dotnet8 (Ubuntu) "[MIR] dotnet8" [Undecided, New] https://launchpad.net/bugs/2060056
[14:32] <slyon> just-in-time cpaelzer :)
[14:32] <slyon> I'd like to ask cpaelzer to check this ^ as I think you have the most context.
[14:32] <cpaelzer> ack on bpf, I resolved that
[14:32] <cpaelzer> trace-cmd ack on looking good but needing a bit
[14:32] <slyon> It should be a quick "versioned package" upgrade, I assume. Correct, dviererbe?
[14:33] <dviererbe> Yes
[14:33] <cpaelzer> on dotnet8 I didn't feel there was much open other than asking "do we need a full process again"
[14:33] <cpaelzer> reading ...
[14:33] <cpaelzer> spoiler: the answer is no - not full again
[14:33] <cpaelzer> Oh I see, that is the new bug
[14:33] <sarnold> good morning
[14:33] <cpaelzer> I can give this a review tomorrow morning, expect this to be 99% a yes
[14:34] <dviererbe> Thanks! :)
[14:34] <slyon> cool, thanks!
[14:34] <slyon> assigned
[14:34] <slyon> #topic Incomplete bugs / questions
[14:34] <slyon> Mission: Identify required actions and spread the load among the teams
[14:34] <slyon> #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:36] <cpaelzer> so many recent updates
[14:36] <cpaelzer> should we go top to bottom?
[14:36] <slyon> ok. bug #2004516
[14:36] -ubottu:#ubuntu-meeting- Bug 2004516 in libyuv (Ubuntu) "[MIR] libyuv (transitive dependency of libheif)" [Undecided, Incomplete] https://launchpad.net/bugs/2004516
[14:36] <cpaelzer> ok, that says escalate to have a chance
[14:36] <cpaelzer> which I think is reasonable
[14:37] <slyon> This is blocked on security-review. but it's too late. I think it's not high priority and not necessarily needed for 24.04. So probably no need for escalation. I'll double check with ravikant_
[14:37] <slyon> bug #2051925
[14:37] <cpaelzer> yes
[14:37] -ubottu:#ubuntu-meeting- Bug 2051925 in libtracefs (Ubuntu) "[MIR] promote libtracefs as a trace-cmd dependency" [Undecided, Incomplete] https://launchpad.net/bugs/2051925
[14:37] <cpaelzer> and update the case either way
[14:37] <slyon> will do
[14:37] <cpaelzer> part of the bigger "perf tools for ubuntu by default" movement
[14:38] <cpaelzer> "I'm working on this and mostly finishing the changes." sounds good
[14:38] <slyon> right. that should be the last missing piece for trace-cmd
[14:38] <cpaelzer> ok, wait for the final update
[14:38] <slyon> bug #2004449
[14:38] -ubottu:#ubuntu-meeting- Bug 2004449 in libde265 (Ubuntu) "[MIR] libde265 (dependency of libheif)" [Undecided, Incomplete] https://launchpad.net/bugs/2004449
[14:38] <slyon> cpaelzer: you were the original reviewer. This is part of the libgd2 -> libheif -> ... chain, which is moving closer to completion
[14:38] <cpaelzer> same as libyuv - although I'd love to have that in next LTS
[14:39] <slyon> Vladimir told me he did the work on this in Debian an it's sync'ed, can you double-check the requirements, cpaelzer ?
[14:39] <cpaelzer> oh no, security has passed that already
[14:39] <cpaelzer> yeah I can check against my requests from the review
[14:39] <slyon> thanks
[14:39] <sarnold> can this move forward if libyuv doesn't?
[14:39] <slyon> no it can't
[14:40] <slyon> well... it could probably, but doesn't make a lot of sense I think
[14:40] <cpaelzer> well,  libde265 could - but there is no point for the final use case without the other
[14:40] <adrien> for libtracefs, I think I'm only left waiting on test results (I think I triggered the tests too early and it didn't pick the version in the PPA sadly)
[14:40] <slyon> exactly
[14:41] <slyon> thanks adrien! please re-ping the MIR bug once it's ready
[14:41] <slyon> bug #1977614
[14:41] -ubottu:#ubuntu-meeting- Bug 1977614 in fdk-aac-free (Ubuntu) "[MIR] fdk-aac-free" [Undecided, Incomplete] https://launchpad.net/bugs/1977614
[14:41] <adrien> sure
[14:41] <slyon> tracking update from security team. Nothing to do for us
[14:41] <cpaelzer> ack
[14:41] <slyon> bug #2058192
[14:41] -ubottu:#ubuntu-meeting- Bug 2058192 in OEM Priority Project "[MIR][needs-packaging] lenovo-wwan-unlock" [Undecided, Confirmed] https://launchpad.net/bugs/2058192
[14:41] <cpaelzer> not yet ready
[14:42] <slyon> ack
[14:42] <slyon> bug #2054480
[14:42] -ubottu:#ubuntu-meeting- Bug 2054480 in nbd (Ubuntu) "[MIR] nbd-client" [Undecided, Incomplete] https://launchpad.net/bugs/2054480
[14:43] <slyon> this is a case of "to re-review security" or "not to re-review security"
[14:43] <cpaelzer> +1 vote on should-be-reviewed
[14:43] <slyon> It would be useful, but we're past the point where we can make it happen for 24.04 I assume? I'll double-check with waveform to see how critical this is
[14:43] <cpaelzer> or is this "needs to be in noble in main asap" panic (still review but later then)?
[14:44] <slyon> I'll try to find out
[14:44] <cpaelzer> and if you need it
[14:44] <cpaelzer> go the "escalate with security" path
[14:44] <waveform> slyon, it's one of the items on my roadmap but it's not going to "break the image" if it has to go red
[14:44] <cpaelzer> See the update by Seth on the other bug
[14:44] <cpaelzer> if you (and mclemenceau_) think we should have it
[14:44] <cpaelzer> escalate it now
[14:44] <cpaelzer> and we might
[14:45] <cpaelzer> waveform: can this be "added to main later" ?
[14:45] <cpaelzer> we have done component moves after the release, that isn't impossible
[14:45] <cpaelzer> so could it be ready for 24.04.1 ?
[14:45] <waveform> well, the idea of including it in the image was to enable netboot of the release image, so if we add it to main later it'll only really benefit .1 onwards
[14:45] <cpaelzer> or is - after that is approved - a "major revamp how everything works" needed?
[14:46] <cpaelzer> I'm mostly, is this a "safe addition" later or is this "to be used break the world" change
[14:46] <cpaelzer> if it is the former, we can make it happen toward 24.04.1 and that should be our goal then IMHO
[14:46] <waveform> oh, safe addition -- it's basically just enabling the initramfs to support nbd boot (assuming the necessary kernel param is present)
[14:46] <cpaelzer> ok, how about that - not giving up on the item but timing it towards that?
[14:46] <eslerm_> o/
[14:46] <sarnold> given that this package had been in main itself, it's 'just'a binary package move, and I don't recall seeing it as a source of work, and that the attack surface is largely in the kernel, I think I'd encourage this to go to main in time for 24.04 release
[14:47] <cpaelzer> update the bug in that case and security can review without panic-priority
[14:47] <waveform> I'm fine with that (enabling for .1)
[14:47] <adrien> I do have a question for libtracefs btw: I've addressed comments; does the MIR team still needs to be involved or could a regular review before upload do it? (sorry to come back late to this)
[14:47] <cpaelzer> sarnold: sure, if you consider this a quick security review - let us make the change for 24.04
[14:47] <cpaelzer> I'm sure waveform will be happy
[14:47] <waveform> I would love it to go into 24.04 but if it has to be shunted, I'm okay with that too
[14:47] <cpaelzer> how about this - sarnold spends 20 minutes, and gives a shallow security review based on this being in main in the past kind of alreay
[14:48] <cpaelzer> if that outcome is good, get it into 24.04
[14:48] <sarnold> wfm
[14:48] <cpaelzer> if not, see former plan for 24.04.1
[14:48] <cpaelzer> great
[14:48] <waveform> sure
[14:48] <slyon> very nice! thanks
[14:48] <cpaelzer> waveform: sarnold: work together and make my Pi NBD boot!
[14:48] <sarnold> :D
[14:48] <waveform> o7
[14:48] <slyon> I guess that's all for MIR updates. dbus-broker is stuck for now and needs some additional (upstream) work
[14:49] <slyon> #topic Process/Documentation improvements
[14:49] <slyon> Mission: Review pending process/documentation pull-requests or issues
[14:49] <slyon> #link https://github.com/canonical/ubuntu-mir/pulls
[14:49] <slyon> #link https://github.com/canonical/ubuntu-mir/issues
[14:49] <slyon> no updates as of last week AFAICT
[14:49] <slyon> #topic MIR related Security Review Queue
[14:49] <slyon> Mission: Check on progress, do deadlines seem doable?
[14:49] <slyon> Some clients can only work with one, some with the other escaping - the URLs point to the same place.
[14:49] <slyon> #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:49] <slyon> #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:49] <slyon> Internal link
[14:49] <slyon> #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594
[14:50] <cpaelzer> no more looks front-loaded which is good given the time we are in the cycle
[14:50] <slyon> bug #2004516 was discussed above and should not get a sec-* tag for now
[14:50] -ubottu:#ubuntu-meeting- Bug 2004516 in libyuv (Ubuntu) "[MIR] libyuv (transitive dependency of libheif)" [Undecided, Incomplete] https://launchpad.net/bugs/2004516
[14:50] <cpaelzer> slyon: it should
[14:51] <slyon> bug #2060035 is targeted for 24.04.1
[14:51] -ubottu:#ubuntu-meeting- Bug 2060035 in msgraph (Ubuntu) "[MIR] msgraph" [Undecided, Confirmed] https://launchpad.net/bugs/2060035
[14:51] <cpaelzer> just not an urgent one
[14:51] <slyon> wfm
[14:51] <cpaelzer> BTW - I know we all feel pressure atm, please all remember how bad this often was in the past, and be happy. Then take a breath and thank security for making it happen!
[14:51] <sarnold> <3
[14:51] <eslerm_> <3
[14:51] <cpaelzer> thanks sarnold and eslerm_ - pass the thanks to all that helped please
[14:51] <slyon> Yes.. we have enough fires in other places this cycle :)
[14:51]  * slyon looking at t64 & xz
[14:51] <cpaelzer> oh so true slyon
[14:51] <sarnold> yes
[14:52] <slyon> sarnold: eslerm_: OK so can we get msgraph and libyuv imported in Jira?
[14:52] <eslerm_> can do
[14:52] <slyon> for non-urgent processing
[14:53] <slyon> #topic Any other business?
[14:53] <dviererbe> A follow up question to the dotnet6 MIR: Do I need to find an Archive Admin to do the promotion or will someone take care of this eventually before 24.04 GA?
[14:53] <slyon> adrien: can you please repeat your question from above?
[14:53] <slyon> dviererbe: AAs usually pick it up from the report, once the MIR status is "Fix Committed"
[14:54] <slyon> and it is seeded/pulled as a dependency
[14:54] <sarnold> dviererbe: the last comment from cpaelzer is "ready for you to change seeds" -- do know if this step has been done yet?
[14:54] <cpaelzer> I do not see it in component mismatches
[14:54] <slyon> neither do I
[14:54] <dviererbe> No, I don't think so
[14:55] <mirespace> o/ for the DMARC perl, do you need anything from me to decide about libmime-tools vs libemail-mime ?
[14:55] <cpaelzer> Hi mirespace -  who are you asking in particular?
[14:55] <cpaelzer> security, MIR in general, ... ?
[14:55] <slyon> mirespace: did you see this update? https://github.com/rjbs/Email-MIME/issues/66#issuecomment-2024085120 (cc eslerm_)
[14:55] -ubottu:#ubuntu-meeting- Issue 66 in rjbs/Email-MIME "DoS on excessive or deeply nested parts" [Open]
[14:55] <cpaelzer> there is so much context that sadly left my memory
[14:55] <adrien> slyon: my question is whether the MIR team expects to have further MIR-specific comments for libtracefs or if any uploader/reviewer could check the open items effectively
[14:56] <cpaelzer> dviererbe: for your case, do you know what is expected from you to change seeds for this?
[14:56] <mirespace> _checking that link_
[14:56] <dviererbe> cpaelzer: not really, I have never done this so far
[14:56] <adrien> I've been addressing all the open comments and I'm almost done (it looks like something still isn't ready but it shouldn't take much longer)
[14:56] <cpaelzer> dviererbe: and you can be bold, and do it for dotnet6 and dotnet8 (for noble) to make them supported (but do not pre-install them anywhere)
[14:56] <slyon> adrien: you get the upload done and then a MIR team member needs to approve the bug report by changing to the relevant status
[14:56] <cpaelzer> slyon: can you teach dviererbe or organize that someone else does?
[14:57] <cpaelzer> foundations internal I mean
[14:57] <slyon> sure dviererbe. I can help with that. please reach out to me on MM
[14:57] <adrien> slyon: hmmm, right, the question is mostly moot indeed
[14:57] <dviererbe> slyon: ack
[14:57] <cpaelzer> adrien: once you think it is ready, update the case. And for urgency get in touch with me or slyon (to not wait for next Tue)
[14:57] <mirespace> :O ... so the MIME DoS issue is not toatally resolved...
[14:57] <adrien> cpaelzer: thanks
[14:58] <mirespace> cpaelzer: I was worried that the debate between mime-tools and email-mime could make the MIR being stuck
[14:59] <eslerm_> I would like to see rjbs/Email-MIME in 24.04, the upstream devs do great work at fastmail
[14:59] <cpaelzer> I'm worried as well, but too far from it to have a good understanding atm
[14:59] <slyon> mirespace: can you remind us of the LP bug number?
[14:59] <slyon> it didn't show up in today's lists
[14:59] <cpaelzer> also collision and I need to leave for the next meeting
[14:59] <cpaelzer> slyon: it is an older incomplete somewhere
[14:59] <mirespace> https://bugs.launchpad.net/ubuntu/+source/libmail-dmarc-perl/+bug/2023971
[14:59] -ubottu:#ubuntu-meeting- Launchpad bug 2023971 in libmail-dmarc-perl (Ubuntu) "[MIR] libmail-dmarc-perl" [High, In Progress]
[14:59] <slyon> cpaelzer: I have one question for you, regarding libgoa-* depdency
[15:00] <slyon> cpaelzer: see https://bugs.launchpad.net/ubuntu/+source/msgraph/+bug/2060035 (you can reply on that bug later)
[15:00] -ubottu:#ubuntu-meeting- Launchpad bug 2060035 in msgraph (Ubuntu) "[MIR] msgraph" [Undecided, Confirmed]
[15:00] <slyon> Not sure what to do about the libgoa-* dependency or why we check for it during the MIR review. It's been there for historical reasons. But we need it in this case
[15:01] <cpaelzer> eslerm_: to what extend it rjibs/Email-MIME and similar good wishes for the future but no blockers for now
[15:01] <cpaelzer> after all time for 24.04 runs out and I understand mirespace getting concerned
[15:01] <cpaelzer> mirespace:  what are the options we have there
[15:01] <cpaelzer> is it:
[15:01] <eslerm_> libmail-dmarc-perl does have an ack, the open issue needs to be solved, but *might* not be a blocker (Seth?)
[15:02] <cpaelzer> I fail to summarize it :-/
[15:02] <mclemenceau_> thanks cpaelzer sarnold, I'm ok with the plan w.r.t netboot with a preference for addition in 24.04 :)
[15:02] <eslerm_> I don't mind contacting upstream and asking if they can make a plan
[15:02] <mirespace> use the change we did to use libmime-tools-perl, diverging from upstream
[15:02] <cpaelzer> ok, consider ^^ option (a)
[15:03] <cpaelzer> what is option (b)
[15:03] <cpaelzer> slyon: for libgoa - it can be a build dependency, just not a runtime dependency (and not part of the final code, no static linking tricks)
[15:03] <mirespace> if (a) is libemail-mime contacting upstream, option (b)is  use libmime-tools, diverging upstream
[15:04] <slyon> cpaelzer: ACK. thanks I'll update the case
[15:04] <cpaelzer> slyon: but if it is used at build to get stuff done (like test tools, binary mangling helpers, ...) then it does not need to be in main
[15:04] <sarnold> (or 'it's not a library it's just a .h file tricks :)
[15:04] <cpaelzer> slyon: >Trusty, before it had to be
[15:04] <cpaelzer> sarnold: yes, that I count as "static code active in the final binary" which would need to be in main
[15:05] <cpaelzer> sarnold: just as much as any other similar trick
[15:05] <cpaelzer> back to mime
[15:05] <cpaelzer> eslerm_: mirespace: what is the way forward
[15:05] <cpaelzer> eslerm_: you said the open issue might (tm) not be a blocker
[15:05] <slyon> libgoa being gnome-online-accounts, right? I.e. https://packages.ubuntu.com/noble/libgoa-1.0-0b
[15:05] <cpaelzer> just an important "we want to work thazt out in the long run"
[15:06] <cpaelzer> if it is really that, can we go on with the promotion of that stack then?
[15:06] <cpaelzer> as-is I mean
[15:06] <mirespace> the promotion form my PPA uses libmime-tools by the moment
[15:06] <eslerm_> since these are ack'd I am okay with pushing through if Seth agrees. If so, I can contact upstream and try to settle issues.
[15:06] <mirespace> because emailñ-mime introduced duplicity
[15:07] <cpaelzer> sounds like a good plan compromise, unblock now, do not give up on making it better
[15:07] <cpaelzer> and thanks for the offer to contact upstream
[15:07] <sarnold> I'm a bit worried that comment #27 on https://bugs.launchpad.net/ubuntu/+source/libmail-dmarc-perl/+bug/2023971 suggests that there's even MORE packages to MIR in order to "just ship what debian ships"
[15:07] -ubottu:#ubuntu-meeting- Launchpad bug 2023971 in libmail-dmarc-perl (Ubuntu) "[MIR] libmail-dmarc-perl" [High, Incomplete]
[15:07] <eslerm_> (I'll message upstream today)
[15:07] <sarnold> but I have to admit that this is a twisty maze of package names that all collide into one single mental hashbucket and I've long ago lost the plot
[15:07] <cpaelzer> sarnold: well, we can slowly sort that out one by one >24.04
[15:08] <cpaelzer> the question is can we take the current approved set for 24.04 and resolve it here?
[15:09] <cpaelzer> if yes, then I'd ask mirespace to work with bryce to prepare the seed/dependency changes and prepare a session telling me what would need to be promoted and why. I could check one by one - if all good mass promotion
[15:09] <cpaelzer> mirespace: will work on several follow up items anyway, like the elliptic curve lib wrapper and such
[15:10] <mirespace> for me it's ok
[15:11] <slyon> +1
[15:12] <cpaelzer> so to summarize, eslerm_ contacts upstreams for a better path forward. mirespace will prep and lay out what we have ready and can land for 24.04
[15:12] <cpaelzer> short: get what we have to noble, mid term make it better
[15:12] <eslerm_> I can do that :)
[15:13] <mirespace> sounds like a plan :)
[15:13] <cpaelzer> mirespace: can you work with bryce to get all in line (probably some blocks by the beta freeze) and then get in touch
[15:13] <cpaelzer> it is work, but better than the unclear state before
[15:13] <cpaelzer> ok, we are way over time
[15:13] <mirespace> yes, I do.. thank you all for unblocking this
[15:13] <cpaelzer> slyon: time to get to the end :-) ?
[15:13] <sarnold> i'm probably not going to come to a good udnerstanding of the whole problem space and the options quickly .. so here's a few of my general thoughts: (a) I'd prefer to not diverge from debian and the upstreams if we can (b) i'm fine with shipping mirespace's "lets change packages to meet our existing main requirements" but I'm not wedded to it (c) I'm not too worried about a 1 meg --> 2 gigs of ram
[15:13] <sarnold> DOS, that'd probably be tolerable enough to fix post-release if upstream doesn't get to it sooner
[15:14] <sarnold> (doesn't every mail server have 100 gigs ram? :)
[15:14] <cpaelzer> almost
[15:14] <slyon> thanks for the summary!
[15:14] <cpaelzer> or 640k
[15:14] <sarnold> :D
[15:14] <slyon> do we have anything else?
[15:14] <slyon> #endmeeting
[15:14] <meetingology> Meeting ended at 15:14:55 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-04-09-14.29.moin.txt
[15:14] <cpaelzer> exhaustion everywhere
[15:15] <cpaelzer> thank you all
[15:15] <sarnold> nothing from me besidews thanks to everyone :)
[15:15] <slyon> oops, too quick :)
[15:15] <cpaelzer> hehe
[15:15] <slyon> anway, thanks all!
[15:15] <eslerm_> thanks all o/
[15:15] <mirespace> thanks all o/
[15:15] <dviererbe> Thanks everyone! o/
[18:59] <amurray> o/
[19:00] <rbasak> o/
[19:00]  * vorlon waves
[19:01] <seb128> hey
[19:01] <vorlon> seb128: hi! I believe you're on for chairing
[19:01] <seb128> yes, sorry for being late!
[19:02] <seb128> #startmeeting
[19:02] <meetingology> Meeting started at 19:02:26 UTC.  The chair is seb128.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[19:02] <meetingology> Available commands: action, commands, idea, info, link, nick
[19:02] <seb128> #topic Apologies
[19:02] <amurray> apologies folks but I have a hard stop in 30 mins so I may have to drop early
[19:03] <seb128> k, let's try to keep going, no apologies for this meeting I can see
[19:03] <seb128> #topic Action review
[19:03] <seb128> ACTION: rbasak to update third party repo draft with outcomes from our recent out-of-band meeting
[19:03] <rbasak> I've made progress on this...
[19:04] <amurray> it looks really good rbasak, thanks for that
[19:04] <rbasak> The doc is updated. Could all TB members please check what I've updated (highlighted in green), and raise any comments within a week?
[19:04] <seb128> +1
[19:04] <rbasak> This time next week I'll publish the initial consultation to Discourse for Ubuntu developers at large.
[19:04] <vorlon> yes
[19:04] <rbasak> Thanks amurray!
[19:05] <rbasak> FTR, I intend to edit heavily to clean up the documentation generally, resolve outstanding Google Doc comments, etc. But I don't intend to change anything substantial at this stage.
[19:05] <rbasak> (nothing about intent, I mean)
[19:06] <seb128> #action everyone to review the third party repo draft within a week and raise any comments they have, after that Robie will post to discourse
[19:06] <meetingology> ACTION: everyone to review the third party repo draft within a week and raise any comments they have, after that Robie will post to discourse
[19:06] <rbasak> Great. Thanks!
[19:06] <seb128> ACTION: rbasak to open wider discussion on third-party repo policy
[19:06] <seb128> I guess that's what is happening in a week so carrying over?
[19:06] <rbasak> Yep
[19:06] <rbasak> So carry over that one please
[19:06] <seb128> #action rbasak to open wider discussion on third-party repo policy
[19:06] <meetingology> ACTION: rbasak to open wider discussion on third-party repo policy
[19:06] <rbasak> Nearly there!
[19:07] <seb128> ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification
[19:07] <rbasak> Carry over my DMB action please
[19:07] <seb128> #action rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification
[19:07] <meetingology> ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification
[19:07] <seb128> ACTION: vorlon to look into scripting for packages in flavor-specific overlays
[19:07] <vorlon> still outstanding sorry
[19:07] <seb128> #action vorlon to look into scripting for packages in flavor-specific overlays
[19:07] <meetingology> ACTION: vorlon to look into scripting for packages in flavor-specific overlays
[19:07] <rbasak> I also need to get the DMB election going
[19:07] <seb128> do you want an action item for that?
[19:07] <rbasak> Sure
[19:08] <seb128> #action rbasak to get the DMB election going
[19:08] <meetingology> ACTION: rbasak to get the DMB election going
[19:08] <seb128> 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:08] <seb128> still carrying that one over
[19:08] <seb128> #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:08] <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:08] <seb128> #topic Scan the mailing list archive for anything we missed (standing item)
[19:09] <seb128> there is https://lists.ubuntu.com/archives/technical-board/2024-March/002913.html but that doesn't really seem to be a TB topic
[19:09] <teward> *raises hand briefly*
[19:09] <seb128> teward, yes?
[19:10] <teward> regarding that, there was one sent to the CC and other teams as well as Canonical's teams.
[19:10] <teward> CC hasn't addressed it yet, but Canonical (Fallen, etc.) were starting to investigate best approaches
[19:10] <teward> just wanted to have that on the record.
[19:10] <teward> (expected it to show up here)
[19:10] <rbasak> It sounds like something the nearest Loco could take up perhaps?
[19:10] <teward> ^^ that
[19:10] <rbasak> Happy to hear that it's being looked at. Thank you!
[19:11] <teward> *returns to the shadowy void from whence he came*
[19:11] <seb128> thanks teward!
[19:11] <seb128> other list topic
[19:11] <seb128> https://lists.ubuntu.com/archives/technical-board/2024-March/002905.html (Call for vote: Ubuntu Cinnamon 24.04 LTS Qualification)
[19:12] <seb128> afaik only amurray and me voted
[19:12] <seb128> can we get some other members to also vote?
[19:12] <vorlon> I have a concern about the "contact" being a list of ~10 people
[19:12] <vorlon> I've raised similar concerns with other flavor applications before
[19:13] <vorlon> but I haven't had time to respond to the list about this
[19:13] <seb128> can you follow up on the list with that concern?
[19:13] <vorlon> yes
[19:13] <seb128> thanks
[19:13] <seb128> want an action item for it?
[19:13] <vorlon> but mentioning here this is what's blocked me from +1'ing
[19:13] <vorlon> I'll accept an action item :)
[19:14] <seb128> #action vorlon to follow up on the Cinnamon 24.04 LTS Qualification re the number of contacts listed for the flavor
[19:14] <meetingology> ACTION: vorlon to follow up on the Cinnamon 24.04 LTS Qualification re the number of contacts listed for the flavor
[19:14] <seb128> no other topic on the list that I can see (outside of the DMB election which we discussed earlier)
[19:15] <seb128> #topic Check up on community bugs and techboard bugs
[19:15] <seb128> #info No open community bugs
[19:15] <seb128> #info No new techboard bugs
[19:15] <seb128> #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members)
[19:16] <seb128> #info Next chair will be vorlon, with sil2100 as backup
[19:16] <seb128> #topic AOB
[19:16] <vorlon> ack
[19:16] <seb128> AOB?
[19:16] <vorlon> nothing from me
[19:16] <amurray> neither from me
[19:17] <seb128> nor from me
[19:17] <seb128> ok, that's a wrap then, thanks everyone!
[19:17] <seb128> #endmeeting
[19:17] <meetingology> Meeting ended at 19:17:09 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-04-09-19.02.moin.txt
[19:17] <vorlon> thanks!
[19:17] <amurray> thanks folks - thanks seb128 for chairing
[19:17] <rbasak> Thanks all!