[06:34] <Kilos> o/
[07:33] <nicoz> o/
[15:30] <cpaelzer> Hiho
[15:30] <ahasenack> hiho
[15:30] <cpaelzer> #startmeeting Weekly Main Inclusion Requests status
[15:30] <meetingology> Meeting started at 15:30:39 UTC.  The chair is cpaelzer.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[15:30] <meetingology> Available commands: action, commands, idea, info, link, nick
[15:30] <cpaelzer> ping slyon, didrocks, sarnold, joalif, jamespage for MIR meeting
[15:30] <joalif> o/
[15:31] <didrocks999> hey
[15:31] <cpaelzer> #topic Review of previous action items
[15:31] <slyon> o/
[15:31] <cpaelzer> we had none - other than the assigned reviews
[15:31] <cpaelzer> #topic current component mismatches
[15:31] <cpaelzer> Mission: Identify required actions and spread the load among the teams
[15:31] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[15:31] <cpaelzer> #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[15:31] <sarnold> good morning
[15:32] <ahasenack> ndctl in that report is a mess, vorlon asked me to look into it
[15:33] <sarnold> I can't spot it.. did you already de-mess it? :)
[15:33] <cpaelzer> TBH I do not even see ndctl in there
[15:33] <ahasenack> his words were
[15:33] <ahasenack>  <vorlon> ahasenack: coherent accelerator vs compute express link? wheeee
[15:33] <ahasenack>  <vorlon> ahasenack: I will trust you to sort this
[15:33] <cpaelzer> does it go by another name here, i do not see it in the .svg
[15:34] <ahasenack> I didn't demess it yet
[15:34] <cpaelzer> then maybe someone else did
[15:34] <cpaelzer> I see nothing new in the normal mismatches
[15:34] <ahasenack> I guess they removed it from proposed
[15:34] <cpaelzer> and a few in -proposed
[15:34] <ahasenack> something happened, ndctl is today in jammy release
[15:34] <ahasenack> that wasn't the case yesterday
[15:34] <cpaelzer> \o/
[15:35] <cpaelzer> -proposed shows libreoffic -> epiphany-browser and IIRC didrocks wanted to have a look
[15:35] <cpaelzer> any news there?
[15:35] <didrocks> yes, the issue appeared when debian version was synced in ubuntu. Asked the maintainer, should be fixed with next libreoffice version (hopefully this/next week)
[15:35] <didrocks> basically, debian assumed we had firefox-esr, and then, by the alternatives order, epiphany is picked
[15:35] <cpaelzer> ok, so for that one we just wait then
[15:35] <didrocks> indeed
[15:36] <cpaelzer> heat -> python3-vitrageclient -> twitter-bootstrap3 is openstack - jamespage
[15:37] <cpaelzer> jamespage: any news on that, I saw the upload that pulls in python3-vitrageclient, but will you really go for  twitter-bootstrap3 or will there be another upload cutting the dependency?
[15:37] <cpaelzer> while waiting for jamespage another candidate for didrocks
[15:37] <cpaelzer> xwayland -> libxcvt
[15:37] <didrocks> putting it in my caddy of things to look at :)
[15:38] <cpaelzer> is Desktop aware of that as far as you know?
[15:38] <cpaelzer> ah ok, if you need a look that is fine
[15:38] <cpaelzer> we will see if it is gone next week :-)
[15:38] <cpaelzer> all others are known cases AFAICS (or known false positives)
[15:38] <didrocks> yeah, I’m not working too much on transitions/gnome/xorg stack (actually, desktop is still not the ones doing Xorg uploads)
[15:39] <cpaelzer> hehe
[15:39] <cpaelzer> TIL - but you are ok to check this case are you?
[15:39] <didrocks> sure sure
[15:39] <cpaelzer> jamespage: please chime in later when you see the questions - we will go on ...
[15:39] <cpaelzer> #topic New MIRs
[15:39] <cpaelzer> Mission: ensure to assign all incoming reviews for fast processing
[15:39] <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
[15:40] <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-auth-openidc/+bug/1959722
[15:40] <cpaelzer> just one that needs a review
[15:40] <cpaelzer> oh BTW since I gave you credit - didrocks did you have a chance last week to complete cargo?
[15:40] <cpaelzer> looking for a volunteer to review this libapache case
[15:41] <joalif> I can take the  new one
[15:41] <cpaelzer> thank you joalif !
[15:41] <slyon> I could to the review for joalif
[15:41] <joalif> np :)
[15:41] <slyon> (if needed)
[15:41] <joalif> thanks!
[15:41] <cpaelzer> slyon: you'll be her "if in doubt ask" buddy :-)
[15:41] <cpaelzer> #topic Incomplete bugs / questions
[15:41] <cpaelzer> Mission: discuss the recent activity to identify any follow up action
[15:41] <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
[15:42] <cpaelzer> rust has a discussion ongoing, I have done the review
[15:42] <cpaelzer> I saw schopin answered, but had no time to read the answer yet
[15:42] <cpaelzer> just saw the mail in my inbox
[15:42] <cpaelzer> cargo will be done by didrocks  in a bit
[15:42] <schopin> cpaelzer: tldr: progress on many items but the big one (LLVM) is still pending
[15:42] <cpaelzer> thanks for that TL;DR
[15:42] <didrocks> cpaelzer: yeah, couldn’t even start looking at it until now
[15:42] <didrocks> but still plan for this one :)
[15:43] <cpaelzer> since I've kept schopin busy with rustc that is ok :-)
[15:43] <cpaelzer> FRR is recently incomplete and I've brought ahasenack here with me to talk about it
[15:43] <cpaelzer> https://bugs.launchpad.net/ubuntu/+source/frr/+bug/1951834
[15:43] <ahasenack> o/
[15:43] <cpaelzer> sarnold: we will need everyone, but especially you for this
[15:43] <cpaelzer> This is mostly done from an MIR review POV with one exception
[15:44] <ahasenack> let me try to find the original quagga mir
[15:44] <didrocks> indeed, ahasenack quickly addressed most of the concerns :)
[15:44] <cpaelzer> sarnold: the question that is still open is "does it need a security review or does it get a fast pass"
[15:44] <didrocks> right!
[15:44] <cpaelzer> didrocks: he always does, when you see his name be prepared for quick answers to your review :-)
[15:44] <didrocks> heh :-)
[15:44] <cpaelzer> sarnold: here the situation:
[15:44]  * ahasenack didn't find the quagga mir, maybe it was born in main
[15:44] <cpaelzer> 1. quagga is a discontinued project
[15:44] <cpaelzer> 2. FRR is the fork and continuation
[15:45] <cpaelzer> 3. So the code is the same, but very much evolved since then
[15:45] <didrocks> ahasenack: you’re correct, first upload was in main: https://launchpad.net/ubuntu/+source/quagga/+publishinghistory?batch=75&direction=backwards&start=225
[15:45] <cpaelzer> 4. Security asked us to switch those for jammy to be able to long term support it
[15:45] <cpaelzer> 5. We would not have checked a new quagga version (with the same changes)
[15:46] <ahasenack> this is the original frr release, from 2017: https://frrouting.org/release/2.0/
[15:46] <cpaelzer> So the question to you sarnold, does this go onto your not too small pile of reviews-with-deadline or does this get a fast pass by you?
[15:47] <cpaelzer> We (MIR team) are happy with both, but me (Server team) and me (pity for your review queue) want to recommend a fast pass
[15:47] <sarnold> cpaelzer: I'm inclined to say we should give it the fast pass. :( we just really don't have the capacity to look at everything, and quagga is a known sad situation
[15:47] <ahasenack> https://bugs.launchpad.net/ubuntu/+source/frr/+bug/1951834 for my MIR reveiew
[15:47] <cpaelzer> ok ahasenack, here you have it - fast pass it will be for "special csae + capacity"
[15:47]  * ahasenack better subscribe to its bugs then
[15:47] <ahasenack> also in debian
[15:47] <ahasenack> stay on top of it
[15:47] <cpaelzer> ahasenack: this is still blocked on libyang2
[15:47] <cpaelzer> ahasenack: but other than that it is ready
[15:48] <ahasenack> yes, I'll get to that one next then
[15:48] <sarnold> thanks cpaelzer, ahasenack :)
[15:48] <ahasenack> let me just quickly check if I have questions about libyang2
[15:48] <ahasenack> well, it does need a security review
[15:48] <ahasenack> hi sarnold ;)
[15:48] <sarnold> ohello :)
[15:49] <ahasenack> ok, better dep8, deal with gcc warnings
[15:49] <ahasenack> easy
[15:49] <cpaelzer> I updated the FRR bug status and left a comment
[15:50] <cpaelzer> To complete the list of recent incompletes - https://bugs.launchpad.net/ubuntu/+source/v4l2-relayd/+bug/1958109 got reviewed by slyon and is now back with the reporter
[15:50] <cpaelzer> Before I go on - are we ok with FRR / Libyang2 for now or are there open questions here?
[15:51] <ahasenack> I'll address the libyang2 comments, but will be blocked on a security review
[15:51] <cpaelzer> o
[15:51] <cpaelzer> ok
[15:51] <cpaelzer> #topic MIR related Security Review Queue
[15:51] <cpaelzer> Mission: Check on progress, do deadlines seem doable?
[15:51] <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
[15:51] <sarnold> python-cheroot python-asgiref adsys are in progress at the moment
[15:52] <cpaelzer> Glad to hear that
[15:52] <cpaelzer> Adsys was in progress last time, what happened there?
[15:52] <didrocks> it wasn’t, was it?
[15:52] <sarnold> I finished going through the coverity issues -- there's a vast number of error checks that are skipped
[15:52] <didrocks> hum? This is surprising
[15:52] <sarnold> didrocks: alas it's been in progres for weeks
[15:52] <cpaelzer> It was "on" or "next" as far as I remember
[15:53] <didrocks> we are using go vet and error checking are all covered
[15:53] <slyon> IIRC it was "no progress on adsys so far"
[15:53] <didrocks> what slyon said ^
[15:53] <cpaelzer> ah ok, thanks
[15:53] <cpaelzer> well we all know the list
[15:53] <didrocks> sarnold: btw, 0.8 for adsys is out, it shouldn’t change the general strategy, but Mark asked explicitely the script part (in 0.8) to go through security
[15:53] <slyon> sarnold: but it's good that adsys is on progress now as the release team has been asking for that
[15:53] <cpaelzer> in Theory 16 days until FF and 7 cases with a deadline towards that
[15:53] <cpaelzer> you can all do the dpressing math
[15:54] <cpaelzer> wishing the best for sarnold and company to churn through some more
[15:54] <didrocks> I think the coverity thing should be looked again, I’m happy to have preliminery results because errors are for sure all covered and linted by upstream tools
[15:54]  * cpaelzer hands a crate of security-engergy-drinks
[15:54] <ahasenack> is adsys ours? (canonical)
[15:54] <didrocks> yes
[15:54] <cpaelzer> desktop driven ahasenack
[15:55] <sarnold> didrocks: it's not as friendly as the web interface, but it's way easier to share the text output: https://termbin.com/hb49
[15:55] <sarnold>   Type: Unchecked error (SUPPRESSED_ERROR)
[15:56] <cpaelzer> Ok, that seems like didrocks has some homework to check these for false-positives
[15:56] <sarnold> $ grep -c SUPPRESSED_ERROR coverity.txt
[15:56] <sarnold> 1442
[15:56] <cpaelzer> The rest of the list is done for today
[15:56] <cpaelzer> #topic Any other business?
[15:56] <cpaelzer> we can continue adsys talk here
[15:56] <cpaelzer> but is there anything else for this section?
[15:56] <seb128> hey, I wanted to mention https://github.com/cpaelzer/ubuntu-mir/pull/5
[15:56] <cpaelzer> thanks seb128
[15:57] <seb128> it's trivial and can wait for another meeting which is less busy if you prefer
[15:57] <ahasenack> I have a question, if my style of very verbose MIRs helps, or hinders, analysis
[15:57] <ahasenack> (since I'm here)
[15:57] <cpaelzer> it looks trivial seb128, I can merge it once I have 1-2 reviews - so everyone could a few have a look together with me?
[15:58] <cpaelzer> ahasenack: I like it, I read it, and I appreciate when I find the answers in the MIR request instead of having to dig on my own
[15:58] <cpaelzer> ahasenack: we have continuously extended the report template for wanting those infos
[15:58] <slyon> cpaelzer: seb128: I just added my +1 for that PR#5 on github
[15:58] <cpaelzer> thanks slyon
[15:58] <sarnold> ahasenack: I like your very verbose MIRs :)
[15:58] <seb128> slyon, thx
[15:58] <cpaelzer> seb128: I'll keep the tab open and have a look myself and then merge most likely
[15:58] <ahasenack> ok, thx :)
[15:58] <ahasenack> I'll continue with the style then :)
[15:58] <cpaelzer> next meeting is knocking on my door, closing for today
[15:59] <cpaelzer> anything urgent we missed ?
[15:59] <sarnold> nothing from me
[15:59] <joalif> nothing
[15:59] <slyon> nope
[15:59] <cpaelzer> thanks then
[15:59] <sarnold> thanks cpaelzer, all :)
[15:59] <cpaelzer> #endmeeting
[15:59] <meetingology> Meeting ended at 15:59:36 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-02-08-15.30.moin.txt
[15:59] <didrocks> nothing either
[15:59] <seb128> cpaelzer, thanks, it was a draft, there might be similar changes to do down on the page in the MIR reviewer section I think, I can update for that latter if you agree on the principle and want those done in the same edit
[15:59] <seb128> thanks!
[16:00] <joalif> thanks all bye o/
[16:00] <slyon> o/
[16:00] <cpaelzer> seb128: it seems we have principle agreement
[16:00] <slyon> ack
[16:00] <cpaelzer> seb128: please complete it with a full search/replace
[16:00] <seb128> cpaelzer, ack
[16:00] <didrocks> sarnold: back on adsys, it seems most of the issues are in vendored dependencies. There are 79 in our code itself. I don’t think we can fix the ones vendored though? (would be like fixing the stdlib…). However, I’m really surprised by the amount of issues in our code while gosec, which is the tool used by google has no errors (we run that in CI and fixed them all)
[16:01] <didrocks> sarnold: how do you want to proceed? Happy to give an answer for each false positive and see what we have as actionables one
[16:01] <sarnold> didrocks: it all code in the package, though, and going through all thousand of them to find out which ones are safely ignored (most of them) vs which ones shouldn't be ignored (who knows?) is a fair chunk of effort. it's not great :(
[16:02] <didrocks> sarnold: indeed, this is why gosec compiles your code and goes to your code path and used deps
[16:02] <sarnold> didrocks: I'm fine with deciding to ignore entire classes of cases, eg "errors on write(2), close(2), etc are never checked by anything except sqlite3 anyway" ..
[16:03] <didrocks> sarnold: yeah, the valid ones I see is not checking the error returned by fmt.Fprintf() on stdout/stderr
[16:03] <didrocks> which is… if you can’t write to it, you don’t check errors to return it, and ignored by default by most linters
[16:03] <sarnold> didrocks: is that something you could poke along? it's entirely possible that there's nothing of consequence in that list, but it doesn't feel right to just ignore 1k+ known issues that coverity has given us
[16:03] <didrocks> I will double check the file permissions in particular, but same, we fixed them
[16:03] <sarnold> yes ignore the file permissions
[16:04] <sarnold> those are stupid :)
[16:04] <sarnold> (well, not stupid, but.. you know what I mean. heh.)
[16:04] <didrocks> well, we used the gosec returned one to lessen the permissions as much of them as possible :)
[16:04] <didrocks> and justify we ones we can’t :p
[16:04] <sarnold> cool cool
[16:04] <didrocks> like a non executable script you want to run… hermf :p
[16:05] <sarnold> I *think* I invested all the non-SUPPRESSED_ERROR cases and found they were fine
[16:05] <sarnold> s/invested/investigated/
[16:05] <sarnold> so obviously the gosec integration has gone a long way :)
[16:05] <didrocks> ack, I’ll check some other and keep you posted, In case some are interesting, this will be a good report to gosec upstream :p
[16:06] <didrocks> yeah, when plugging it in… well let’s say once all fixed… I was happy to plug it in :p
[16:06] <sarnold> excellent idea :D
[16:06] <sarnold> hah
[16:06] <didrocks> (and some issues were embarrassing)
[16:06] <sarnold> aye
[16:06] <sarnold> I've seen that myself with my own projects and linters / warnings..
[16:06] <didrocks> yeah, this is why we plug it in early. Anyway, if you just started, ensure you do 0.8 with the scripts
[16:07] <didrocks> also, one the architecture/permissions I’m happy to spend some time explaining how the project works. It’s not trivial between the unix socket, grpc communication, polkit integration and so on…
[16:07] <sarnold> heh, I've been plugging away at it for a looong time, going in fits and starts, on 0.7.1build1 .. I can kick off a new run...
[16:08] <sarnold> didrocks: wonderful, thanks :) I just started reading the docs/ last night
[16:08] <sarnold> thanks for the docs
[16:08] <didrocks> heh, happy those are useful :p
[16:08] <sarnold> it's really amazing how often projects provide *none* and just assume you know what the thing does and why :)
[16:08] <didrocks> sarnold: you have the live version automatically synced to https://github.com/ubuntu/adsys/wiki if you prefer having screenshots
[16:08] <sarnold> reading the source code is sometimes like watching the turbo-retroencabulator video
[16:09] <sarnold> sweeeet :D
[16:09] <didrocks> (we have no doc yet on privilege escalation and scripts which will be ready in the coming month)
[16:09] <sarnold> I did wonder if there wasa nice way to read these, heh
[16:09] <didrocks> otherwise, if you feel adventurous, you can run "adsysctl doc <chapter"
[16:09] <didrocks> and you have the CLI rendered-version
[16:09] <sarnold> oooooo
[16:09] <sarnold> that's so cool :D
[16:10] <didrocks> the coolest part is that it’s the daemon which stream the doc to the client :p
[16:10] <didrocks> (and provide dynamic shell completion on available chapters)
[16:11] <sarnold> so it always reflects what the running daemon's docs say it is capable of :D
[16:11] <didrocks> exactly, that’s the goal
[16:11] <sarnold> though it does mean it's probably a bit more work to turn it into a generic md browser, hehe
[16:12] <didrocks> you have a way to render the md file back and pipe it to where you want… :p
[16:12] <didrocks> anyway, I will have a look tomorrow/thursday on the errors and will keep you posted
[16:12] <sarnold> wonderful, thanks didrocks :) have a good night
[16:13] <didrocks> thanks, have a nice day!
[19:56]  * vorlon waves
[19:58] <rbasak> o/
[19:59] <sil2100> o/
[20:01] <vorlon> sil2100: I see you as backup chair in cyphermox's absence
[20:01] <sil2100> Okay! Let me prep the meeting then, one moment
[20:02] <sil2100> #startmeeting Technical Board meeting
[20:02] <meetingology> Meeting started at 20:02:26 UTC.  The chair is sil2100.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[20:02] <meetingology> Available commands: action, commands, idea, info, link, nick
[20:02] <sil2100> #topic Apologies
[20:02] <sil2100> I thin mdeslaur sent apologies for not being able to make it
[20:03] <sil2100> #topic Action review
[20:03] <sil2100> ACTION: formal ratification of third party seeded snap security policy, depends on:
[20:03] <sil2100> ACTION: vorlon to circle around with store, snapcraft, et all, and revise the snap source revision policy to be more clear with regards to rebuildability and GPL compliance.
[20:03] <rbasak> I've been working on the pad, which is related.
[20:03] <sil2100> vorlon: any progress here? ^
[20:03] <vorlon> carry-over on that one, sorry
[20:04] <sil2100> #action formal ratification of third party seeded snap security policy, depends on:
[20:04] <meetingology> ACTION: formal ratification of third party seeded snap security policy, depends on:
[20:04] <sil2100> #action vorlon to circle around with store, snapcraft, et all, and revise the snap source revision policy to be more clear with regards to rebuildability and GPL compliance. (carry over)
[20:04] <meetingology> ACTION: vorlon to circle around with store, snapcraft, et all, and revise the snap source revision policy to be more clear with regards to rebuildability and GPL compliance. (carry over)
[20:04] <sil2100> ACTION: vorlon to reply to seeded snap upload permissions question on list
[20:05] <vorlon> unless either of you think that's still important for me to do, I think we should just drop that one; likely to be superseded by the new policy regardless
[20:05] <rbasak> Yeah I think it makes sense to collapse this all into the one effort.
[20:05] <rbasak> (which is currently the pad)
[20:05] <sil2100> +1
[20:05] <sil2100> Moving on...
[20:05] <rbasak> Just make sure that everything you want incorporated is actually included in the current pad please
[20:06] <sil2100> ACTION: sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step
[20:06] <sil2100> Sadly this needs to be carried over. There has been progress but since last meeting not much, sadly
[20:06] <sil2100> #action sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step (carry over)
[20:06] <meetingology> ACTION: sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step (carry over)
[20:06] <sil2100> ACTION: all members to continue discussion at https://pad.ubuntu.com/third-party-repository-requirements
[20:06] <vorlon> x-nox? /me glances at the wiki edit history and chuckles
[20:07] <rbasak> I've been writing up wording on the pad.
[20:07] <vorlon> rbasak: is that in a state now that you want us to review and give feedback on, or do you have further edits pending?
[20:07] <rbasak> I'd like feedback on the preamble and my mostly v1 wording on the first three requirements please, to make sure I'm proceeding in a direction everyone agrees with.
[20:07] <vorlon> ok
[20:08] <sil2100> rbasak: thanks!
[20:08] <vorlon> right now, or out of band?
[20:08] <rbasak> What I'm proposing is that everything between BEGIN and END markers will end up in the final document (except for inline comments)
[20:08] <rbasak> Out of band is probably best.
[20:08] <vorlon> deadline? next TB meeting?
[20:08] <rbasak> At least this time.
[20:08] <rbasak> Yep
[20:08] <rbasak> And then let's discuss in realtime next TB meeting please.
[20:08] <rbasak> Also feel free to leave comments inline
[20:08] <sil2100> Ok, let's create a differently worded action item then
[20:09] <sil2100> #action Review and leave feedback on the first version of the preamble and three first requirements https://pad.ubuntu.com/third-party-repository-requirements (all of the TB)
[20:09] <meetingology> ACTION: Review and leave feedback on the first version of the preamble and three first requirements https://pad.ubuntu.com/third-party-repository-requirements (all of the TB)
[20:10] <sil2100> Thank you for working on this
[20:10] <rbasak> yw! Glad to be doing something productive.
[20:11] <sil2100> Ok, I think that's it from the explicit action items we have on the agenda
[20:11] <sil2100> #topic ML topics
[20:11] <rbasak> There is one private ML topic, and the DMB referred public one.
[20:11] <sil2100> So we do seem to have the recent discourse regarding the DMB expiry
[20:12] <rbasak> I don't see any other recent traffic.
[20:12] <sil2100> vorlon's e-mail suggests that the authority to actually change DMB governance policy should be done by the TB - probably a good point that has been missed during the new policy discussion and ratification
[20:13] <rbasak> I wonder if, to make progress, we could just vote to ratify the DMB's motion now. If the TB agrees, then that would make the (valid) point moot.
[20:13] <sil2100> Should we discuss it here? Both me and rbasak are part of the DMB, but should we maybe request the DMB to submit an official proposal to the TB to review and/or ratify the new policy that wanted to be executed here?
[20:13] <sil2100> *that was meant to
[20:14] <rbasak> I think it's implied that the DMB wants the motion it passed ratified by the TB if ratification by the TB is required.
[20:15] <sil2100> We could do that, although sooner or later I would like the policy to be reworded and include information about sending notices to members getting expired
[20:15] <vorlon> I would kind of prefer to have more non-DMB members of the TB present for that particular discussion/vote
[20:16] <sil2100> Agreed, maybe even, as someone outside of the team suggested, me and rbasak shouldn't actually have a vote on this?
[20:16] <vorlon> no, you sohuld
[20:16] <vorlon> should
[20:16] <sil2100> I don't know what are the common-sense policies in such situations!
[20:16] <rbasak> On sil2100's point, it would be nice to clear that up at the same time, if we're going to do it. Again, I don't think anybody on the DMB actually objects to that being in the long term policy?
[20:16] <vorlon> there's no reason to recuse yourselves from such a decision
[20:17] <sil2100> rbasak: yeah, I don't think so as well. I think it was something that was clearly missed, unfortunately, but at least I get the feeling that all DMB members would be fine with that - if included
[20:17] <vorlon> in the meantime, if you've seen my second message on the list, I'm suggesting a path forward that doesn't depend on the TB ratification
[20:17] <rbasak> I agree with not recusing myself for the reasons I stated in the ML thread. At least on this point. I think ddstreet is also questioning my conduct in one of his emails to the TB thread today, and wants a response from the TB on that too. I think I should stay out of that one.
[20:17] <rbasak> But really they're two distinct questions I think.
[20:17]  * vorlon nods
[20:18] <rbasak> "if the members of the DMB who are currently under discussion have personally voted to approve" -> that didn't happen - they were absent.
[20:18] <rbasak> (IIRC)
[20:18] <vorlon> ok
[20:18] <sil2100> One thing for sure: I want us to have clear policies which have all requirements clearly stated
[20:18] <vorlon> if someone wants to confirm whether they were or weren't present and follow up to the list to that effect, then, I would appreciate it
[20:19] <rbasak> I should be able to look that up in a couple of minutes. Doing so...
[20:19] <sil2100> ACK
[20:20] <rbasak> According to https://lists.ubuntu.com/archives/devel-permissions/2021-November/001780.html the absent members did not vote.
[20:20] <vorlon> If they WEREN'T present, then I definitely think the present members of the DMB, quorate or not, deciding a policy that allows them to remove members not present, and then removing those members, is improper.  So any resolution here is going to require the TB voting
[20:21] <sil2100> vorlon: would you prefer to wait for input from other TB members? mdeslaur and cyphermox?
[20:22] <rbasak> FTR, I voted -1 because I didn't think there was sufficient opportunity given to figure out the details by a forced email vote rather than waiting for a slot in a regular meeting (the meetings were full of applications around the time).
[20:22] <vorlon> sil2100: for an actual policy that the TB votes on, yes, I want broader input than us 3
[20:22] <sil2100> That of course makes sense
[20:23] <sil2100> Let's maybe create an action item for this for the next meeting
[20:23] <rbasak> FTR 2: I am however in favour in principle. Just that the details need figuring out properly, as I think the current mess demonstrates.
[20:23] <vorlon> I will say that from my side I will attempt to make time for dealing with this on the mailing list in a timely manner, as I think having a functional DMB that can deal with applications promptly is very important to the health of the developer community
[20:24] <sil2100> I also think that the base principle is good, especially that it's all for the good of a well-working DMB
[20:24] <vorlon> (there was one suggestion on the list that we just let things wait until May for the next election of the DMB in general; I don't think that's a good idea)
[20:25] <sil2100> No, I don't think so either. THe truth of the matter is that we have 2 inactive members which does cripple DMB operations. We didn't ahve a real problem yet but only because the remaining DMB members keep quite high attendance
[20:26] <rbasak> It is at least functioning OK at the moment. I think most meetings that matter have made quorum recently. I'm fairly sure it's been much worse in the past.
[20:26] <sil2100> But if we go down by 2 members, like it was mentioned on the ML, this will be problematic
[20:26] <sil2100> Let me add an action item just in case for the next TB meeting
[20:27] <rbasak> I would like to leave us time to handle the other private thread in realtime if possible please.
[20:27] <sil2100> #action Discuss DMB inactivity expiration policy (all of the TB)
[20:27] <meetingology> ACTION: Discuss DMB inactivity expiration policy (all of the TB)
[20:27] <rbasak> That one has been dragging on for too long.
[20:28] <vorlon> the proposal is that after adjourning the public meeting we meet in realtime via another medium to discuss the private matter
[20:28] <vorlon> I have no objection to this
[20:28] <sil2100> Yeah, let's do that please. Ok, in that case let's finalize the meeting here
[20:28] <sil2100> #topic Community bugs
[20:28] <sil2100> I see no open bugs
[20:28] <sil2100> #topic Select chair
[20:29] <sil2100> I have no idea how we actually do this, but I suppose let's try with cyphermox chairing and hmm, rbasak as backup? Would that make sense?
[20:29] <rbasak> Sure
[20:29] <sil2100> Thanks!
[20:29] <sil2100> #endmeeting
[20:29] <meetingology> Meeting ended at 20:29:47 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-02-08-20.02.moin.txt
[20:29] <rbasak> No AOB?
[20:29] <rbasak> A couple of quick points please.
[20:30] <rbasak> 1) A couple of additional requirements were suggested to me for the third party repo pad. I added them at the bottom. I think they may be uncontroverial to the other TB members. Please take a look when you review the pad.
[20:30] <sil2100> Ouch! Went too fast!
[20:30] <rbasak> Sorry I forgot to mention that earlier. Just wanted to call it out.
[20:30] <sil2100> (would probably help if the Agenda had an AOB section ;) )
[20:30] <rbasak> 2) On the private thread, mdeslaur and cyphermox are absent now, so I assume they will be absent for that discussion too.
[20:30] <sil2100> I'll add one
[20:30] <vorlon> fwiw the normal process is to rotate alphabetically on https://launchpad.net/~techboard/+members which would have cyphermox with mdeslaur as backup :)
[20:30] <rbasak> ie. I'm not going to worry about sending round a private link except to you two.
[20:30]  * vorlon nods
[20:30] <rbasak> I just wanted to put that on the record to ensure that nobody felt excluded.
[20:31] <sil2100> ACK
[20:33] <rbasak> (private link sent; see you there)