=== Gyuseok is now known as Silica === Silica is now known as Guest4468 [14:29] good morning [14:29] hello. I am here for the nvme-stas MIR [14:30] o/ [14:30] hello o/ [14:30] good morning [14:30] o/ [14:30] #startmeeting Weekly Main Inclusion Requests status [14:30] Meeting started at 14:30:54 UTC. The chair is cpaelzer. Information about MeetBot at https://wiki.ubuntu.com/meetingology [14:30] Available commands: action, commands, idea, info, link, nick [14:30] Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe ) [14:31] lots of people already around [14:31] and a lot on the agenda I guess [14:31] so let us start [14:31] #topic current component mismatches [14:31] Mission: Identify required actions and spread the load among the teams [14:31] #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [14:31] #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg [14:32] o/ [14:32] on spamassassin we now have mirespace working, but that still isn't yet ready for review [14:32] rustc we've had the hiccup of bundling cargo and the related back and forth [14:32] oooof so much perl [14:32] what we see now for rustc [14:32] is that it was demoted to universe [14:32] I can give an update on rustc in AOB (for now it's back to universe) [14:32] to let it pass [14:32] O/ [14:33] thanks slyon, I'll stop at this level of detail then [14:33] hiding in there are two new candidates to look at [14:33] fence-agents -> sbd [14:33] and libblockdev -> libbytesize [14:34] fence is server [14:34] I guess I need to ask kanashiro[m] about that one [14:34] who is libblockdev? [14:34] desktop it seems [14:34] yeah, sounds like it [14:34] I’ll ask [14:35] ok ok, thanks didrocks [14:35] cpaelzer, libblockdev is fixed and just needs a refresh of the report [14:35] new binaries were sent to main by error by whoever NEWed it [14:36] I see, thanks [14:36] #topic New MIRs [14:36] Mission: ensure to assign all incoming reviews for fast processing [14:36] #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:36] * didrocks will NOT ask then :) [14:36] we had quite a few spread last weeks, two more this time [14:36] 1. lua5.4 [14:36] https://bugs.launchpad.net/ubuntu/+source/lua5.4/+bug/2026608 [14:36] -ubottu:#ubuntu-meeting- Launchpad bug 2026608 in lua5.4 (Ubuntu) "[MIR] lua5.4" [Undecided, New] [14:37] this is from my team so I can't really take it :-) [14:37] but gladly this is a carry forward MIR [14:37] it is about getting all to move to 5.4 and then let go of 5.3 [14:37] so it isn't exactly "new" [14:37] anyone up to look at that? [14:37] I can [14:37] I can [14:37] ah :) [14:37] slyon: wins [14:37] didrocks: gets next [14:37] next would be https://bugs.launchpad.net/ubuntu/+source/aom/+bug/2004442 [14:37] -ubottu:#ubuntu-meeting- Launchpad bug 2004442 in aom (Ubuntu) "[MIR] aom (dependency of libheif)" [Undecided, New] [14:38] yeah, assign me that one then [14:38] wasn't that done already? [14:38] I think aom is actually fine. No work for us, but back to the reporter [14:38] by didrocks [14:38] some deps of libheif were [14:38] unsure that one [14:38] ah, indeed [14:38] should be incomplete to fix the things didrocks requested [14:38] the status of aom may be wrong, should have been set to in progress [14:39] just looking at the same eslerm [14:39] there is also https://bugs.launchpad.net/ubuntu/+source/tecla/+bug/2026774 which I think is ready for review [14:39] security ack is good [14:39] -ubottu:#ubuntu-meeting- Launchpad bug 2026774 in tecla (Ubuntu) "[MIR] tecla" [Undecided, New] [14:39] how about all the findings of didrocks ...? [14:39] yeah, sounds like some questions that were not answered [14:39] jbicha, did you forgot to unassign yourself so it shows in the MIR team queue? [14:39] that might be the reasons we miss it [14:39] but you are on time [14:39] we'll have a look next [14:39] didrocks: would you have a look at https://bugs.launchpad.net/ubuntu/+source/aom/+bug/2004442 if all your asks are fulfilled [14:39] -ubottu:#ubuntu-meeting- Launchpad bug 2004442 in aom (Ubuntu) "[MIR] aom (dependency of libheif)" [Undecided, New] [14:40] and set it to incomplete or in progress accordingly? [14:40] cpaelzer: will do [14:40] I just subscribed ~ubuntu-mir to https://bugs.launchpad.net/ubuntu/+source/nvme-stas/+bug/2026591 [14:40] -ubottu:#ubuntu-meeting- Launchpad bug 2026591 in nvme-stas (Ubuntu) "[MIR] nvme-stas" [Undecided, New] [14:40] I don’t see followup comments, but maybe new uploads fixes it [14:40] ok thanks bdrung and seb128 [14:40] reloading the page now gives the expected two more [14:40] We now have a MIR queue that is filling up just-in-time :D [14:40] https://bugs.launchpad.net/ubuntu/+source/tecla/+bug/2026774 [14:40] -ubottu:#ubuntu-meeting- Launchpad bug 2026774 in tecla (Ubuntu) "[MIR] tecla" [Undecided, New] [14:40] https://bugs.launchpad.net/ubuntu/+source/nvme-stas/+bug/2026591 [14:40] slyon: lol [14:41] I'd look at nvme-stas [14:41] that sounds like a candidate for "special HW" though :-) [14:41] who would be up for tecla [14:42] I can take it, I think mine will be easy to reset to incomplete [14:42] tecla should be relatively easy, it's a simple UI to show keyboard layouts (replace libgnomekbd) [14:42] there is also dasbus as nvme-stas dependency: https://bugs.launchpad.net/ubuntu/+source/dasbus/+bug/2025912 (just subscribed) [14:42] -ubottu:#ubuntu-meeting- Launchpad bug 2025912 in dasbus (Ubuntu) "[MIR] dasbus" [Undecided, New] [14:42] ok, I can't deal with everything [14:42] one by one :-) [14:43] ok, tecla for didrocks [14:43] thanks [14:43] joalif: are you around? [14:43] yes [14:43] round robin wise https://bugs.launchpad.net/ubuntu/+source/dasbus/+bug/2025912for you ? [14:43] ack [14:43] BTW we'd have now hit the limit that we once discussed [14:44] even if there would be more I guess that is all we should assign in one week [14:44] gladly unless anyone adds another one last miute, that was all of them [14:44] +1 [14:44] #topic Incomplete bugs / questions [14:44] Mission: Identify required actions and spread the load among the teams [14:44] #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:45] cargo will be mentioned by slyon in AOB [14:45] we mentioned dmarc-perl [14:45] dhcpcd was in a bad state [14:45] I corrected it to incomplete as there are tasks up [14:45] (what is AOB?) [14:45] TBH this is quite some effort, but the new dhcp seems to really end up much better eventually [14:45] any-other-business (the last section of the meeing) [14:45] AOB = any other business [14:46] ty [14:46] the python things have been reviewed and wait for the reporter (hence incomplete) on one task [14:46] fdk-aac .. reading ... ? [14:46] reviewed [14:46] got tasks [14:47] ok, back on jbicha by his own comment [14:47] opk [14:47] ok [14:47] nothing to act on here [14:47] yes, fdk-aac we are working on getting it in shape, maybe by next week [14:47] #topic Process/Documentation improvements [14:47] Mission: Review pending process/documentation pull-requests or issues [14:47] #link https://github.com/canonical/ubuntu-mir/pulls [14:47] #link https://github.com/canonical/ubuntu-mir/issues [14:47] https://github.com/canonical/ubuntu-mir/pull/23 [14:47] -ubottu:#ubuntu-meeting- Pull 23 in canonical/ubuntu-mir "Modernize Process States Overview" [Open] [14:47] we have the re-review topic which I consider on-hold until other things settled [14:47] we have special HW which I'd move to AOB as it could be long [14:48] that leaves https://github.com/canonical/ubuntu-mir/pull/23 as dviererbe said [14:48] I acked it already [14:48] but wanted to give everone a last chance to yell "no I loved asciart" [14:48] if not, then I'd merge [14:48] :D [14:48] this can be seen much better under these links [14:48] well, I *did* love the ascii art.. :) [14:49] old: https://github.com/canonical/ubuntu-mir/blob/main/README.md#process-states [14:49] new: https://github.com/dviererbe/ubuntu-mir/tree/modernize-process-states-overview#process-states [14:49] only condsideration I have: This will make us non-backward compatible [14:49] sarnold: me too, it was much better than the old text, but this really seems to be an improvement [14:49] should we ever want to go back to moinmoin/wiki [14:49] slyon: backward with what - wiki text? [14:49] I really prefer mermaid for our own API scheme too, so it’s not completely stranger [14:49] but do we want that? :D [14:49] slyon: no we don't [14:49] slyon: please nooooooooooo [14:49] slyon: and if we do we would find another way [14:49] this is git [14:49] easy to grab the old [14:50] OK, so +1 from my side for merging it :) [14:50] yeah, and probably markdown-based :p [14:50] ok, sounds like overall +1 [14:50] merging ... [14:50] yay \o/ [14:50] thanks dviererbe :) [14:50] #topic MIR related Security Review Queue [14:50] thanks dviererbe, this looks so much better! [14:50] Mission: Check on progress, do deadlines seem doable? [14:50] the new version is much more readable :) [14:50] Some clients can only work with one, some with the other escaping - the URLs point to the same place. [14:50] #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:50] #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:50] Internal link [14:50] - ensure your teams items are prioritized among each other as you'd expect [14:50] - ensure community requests do not get stomped by teams calling for favors too much [14:50] #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 [14:50] we didn't have much time last week [14:50] so ensure there is no crap in these queues ... [14:51] LGTM in regard to server [14:51] nothing yet from us, slowly acruing credit for our perl-storm [14:51] * sarnold hides [14:51] +c [14:51] right now the lists feels managable [14:51] anyone else seeing anything of concern? [14:52] indeed [14:52] [dh-]cargo is highest priority from foundations, but more on that later.. [14:52] but that big pile of perl is troubling; even if each individual package is super-simple, there's a cost / stress on the sheer number of them [14:52] keeping in mind how much else will come I'd go on then ... [14:52] #topic Any other business? [14:52] slyon: cargo first [14:52] Ok: [14:52] nothing for me [14:52] that was all there is ^^ :-) [14:53] basically in the past we had src:rustc (main) and src:cargo (universe), which got merged in the current version in mantic. so we now only have src:rustc [14:53] (foundations can adjust the prioirty of the cargo jira task, we encouarge other teams to set priority relative to their other mirs) [14:53] it circumvented the MIR process, sneaking cargo into main [14:53] ^^ unintentional [14:53] but as we needed the new version to support firefox and kernel, we decided to demote src:rust back to universe for now [14:54] but it's our hightes priority and I'd like to ask security to review the cargo parts and didrocks to coordinate with liushuyu[m] about the open MIR questions/answers [14:54] eslerm: I think the priority is set accordingly for cargo [14:54] that matches all I've heard and is ok [14:54] ty [14:54] thanks for summarizing so that everyone is aware [14:54] how do kernel builds in mantic work if rust is in universe? [14:54] That leads me to my topic of revisiting special HW rules [14:55] sarnold: build deps can be in universe [14:55] once we have a final MIR ACK for cargo and security +1, we can promote the combined rustc+cargo package [14:55] which shall happen this cycle [14:55] cpaelzer: ah, right, thanks [14:55] ok, seb128 brought this up and I took it actively trying to find a compromise [14:55] by now most of you have seen [14:55] https://github.com/canonical/ubuntu-mir/issues/30 [14:55] -ubottu:#ubuntu-meeting- Issue 30 in canonical/ubuntu-mir "Testing requirements for hardware enablement" [Open] [14:55] https://github.com/canonical/ubuntu-mir/pull/31 [14:55] -ubottu:#ubuntu-meeting- Pull 31 in canonical/ubuntu-mir "Clarify options in case special-HW is needed" [Open] [14:56] It seems on these links that we seem to settle and agree [14:56] But - if you do not mind - I want no one later on be surprised and yell at us. Therefore I'd bring it to the sprint and have everyone that MIGTH suffer long term by effort or untestable things to sign off. [14:57] I can do all the sprint magic for this, just set up your Director of choice if you want to :-) [14:57] but this is my "last call" here for the actual MIR members and friends - would you be ok to go that way? [14:57] :sprint-magic: [14:58] I guess there are not much answers as most of you said "ok" on the issue or PR [14:58] and therefore consider the silence as "no revolts" [14:58] :-) [14:58] +1, especially with buy-in from management [14:58] slyon: yeah, I think that is the best way to go and hence I try to drive it that way [14:59] ok then [14:59] any other AOB then? [14:59] nothing for me [14:59] nothing else here ... [14:59] quick ones from me yes [14:59] none from me [14:59] nothing [14:59] ok go seb128 [14:59] closing words [14:59] * didrocks needs to jump to a customer meetings, will read afterwards [14:59] 1. as a FYI we are going to try to MIR gst-plugins-bad [14:59] we would like a couple of plugins in main [14:59] we currently move some of those to -good via distro patches but that's tedious and we need some more [15:00] that was just a FYI [15:00] set up dependencies to match what you want, and describe in the case which to promote and which not [15:00] 2. I would like to give another try to reconsider dbus-broker for promotion even if we can't demote dbus-daemon [15:00] #2 is valid, sometime there just isn't any other choice [15:00] put a statement there why you think that is right [15:00] I think we do a disfavor to Ubuntu by using a less performant and secure dbus service only to spare some maintainance work on dbus-daemon that we have to do anyway under esm [15:01] and make it appear in the queue next week [15:01] is that ok seb128? [15:01] re dbus-broker, I'd be more amenable if I knew a timeline to write a replacement for the missing tool [15:01] ack [15:01] .. or demote gdm or whatever [15:01] lol [15:01] ok, I need to close and run [15:01] thank you all [15:01] :D [15:01] thanks [15:01] thanks cpaelzer, seb128, all [15:01] #endmeeting [15:01] Meeting ended at 15:01:38 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-07-11-14.30.moin.txt [15:01] thank you all! [15:01] thanks all o/ [15:01] sarnold, in practice what difference does it make if dbus-daemon is in main or universe? we need to provide secure update either way [15:01] thanks cpaelzer, all :) [15:02] seb128: re gst-plugins-bad, are there a handful of codecs that have improved enough to instead move them? or maybe split the package from 3 (iirc) to twenty? [15:02] we just put our distro on a less secure and performant implementation which is way higher impact and cost than the alternative imho [15:03] sarnold, ideally we would get them moved, but that's in our hands alone and upstream isn't considering that as priority [15:03] seb128: having two simulataneous running dbus daemons on a single machine sounds like a recipe for crazy sadness imho -- it increases memory usage, vastly confuses users, etc [15:06] sarnold, it's not ideal, I wouldn't go as far as saying it should confuse users since that's probably not a visible detail to any normal user [15:13] seb128: heh, yeah, most people don't even know it's there. but we've got enough folks who peek under the hood and start fiddling with knobs and trying to reduce memory use or disk used or whatever [16:51] sarnold: the general idea is to split the binary package gstreamer1.0-plugins-bad into a binary package for main & one for universe & I think there's a decent chance we could push that split into Debian too [16:52] Fedora ships a limited set as https://src.fedoraproject.org/rpms/gstreamer1-plugins-bad-free ; webkitgtk & other parts of GNOME assume that select parts of -bad are installed [17:01] jbicha: aha, that works :) thanks [19:00] o/ [19:00] o/ [19:01] o/ [19:01] #startmeeting Ubuntu Technical Board [19:01] Meeting started at 19:01:22 UTC. The chair is amurray. Information about MeetBot at https://wiki.ubuntu.com/meetingology [19:01] Available commands: action, commands, idea, info, link, nick [19:01] #topic Apologies [19:02] sil2100 and vorlon are both noted as absent [19:02] #topic Action review [19:02] ACTION: rbasak to get agreed backporter charter https://lists.ubuntu.com/archives/technical-board/2023-June/002740.html documented under https://wiki.ubuntu.com/TechnicalBoard/ [19:03] Done [19:03] yep - thanks for emailing the backporters team too rbasak [19:03] My other items need carrying over please - no progress so far [19:03] ok - will do [19:03] ACTION: seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage [19:03] sadly I have not made any progress here [19:04] #action seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage [19:04] ACTION: seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage [19:04] carrying over rbasak's items [19:04] #action rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification [19:04] ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification [19:04] #action rbasak to follow up on finding consensus on question of test plans for third party apps [19:04] ACTION: rbasak to follow up on finding consensus on question of test plans for third party apps [19:05] #action rbasak to restructure the third-party repo doc to make the status clearer [19:05] ACTION: rbasak to restructure the third-party repo doc to make the status clearer [19:05] #action rbasak to open wider discussion on third-party repo policy [19:05] ACTION: rbasak to open wider discussion on third-party repo policy [19:05] as noted earlier sil2100 is absent so will carry over his item too [19:05] #action sil2100 to follow up on the Key Ubuntu teams discussion [19:05] ACTION: sil2100 to follow up on the Key Ubuntu teams discussion [19:05] he did [19:06] not that the reply was adressing my concerns [19:06] oh indeed - yes I do recall I saw that earlier [19:06] #undo [19:06] Removing item from minutes: ACTION [19:06] but most members seem to just want to ignore that specific concern so I guess that's how it is [19:06] #topic Scan the mailing list archive for anything we missed (standing item) [19:06] still frustrating [19:07] seb128: to be clear, what exactly do you think has not been addressed? [19:08] sorry seb128 I seem to be steam rolling along with the meeting - apologies - is it helpful to try discuss this further now? [19:09] rbasak, I still feel like that despite what teams might think or their staffing it is demotivating for contributors to not be able to ask the question and get the answer [19:09] I mentioned my experience for SRU and release [19:10] I still don't know today if my intend to join was clear to the team, if I've been considered and what was the issue [19:10] it sucks as a project member experience [19:10] I wish others wouldn't have to end up in the same cases [19:10] my intend to join was clear to the team> which team? SRU team? [19:11] anyone should be able to make their intend clear and to get an reply [19:11] rbasak, SRU and release, did you read my most recent email? [19:11] to quote the email [19:11] > I had a similar experience with the SRU team a few years ago. At a time where I felt like the team was struggling with reviews and that we making them busy with desktop review I asked if it would help if I was joining to review non desktop upload (and free some time from other reviews to help getting our desktop items reviewed). I remember discussing it in person at a Canonical event with Lukasz in Frankfurt in 2020 who said that it [19:11] sounded like worth considering, I was never able to get an answer about that one either. [19:11] For the SRU team, an answer was supposed to have been relayed to you. [19:12] it was not [19:12] which is part of my point, if there is no (open) process then we have no record and we end up in such situations [19:12] I'd be happy to go into that with you, but perhaps doing that in public isn't appropriate? [19:12] my point isn't about my application [19:13] My position is that this kind of discussion must be private as to judge people in public is usually not appropriate. [19:13] is about the ability for someone to be able to ask a question and to follow the status [19:13] well, a private record would wfm [19:13] but afaik there is no private records in those teams [19:14] like is there a place you could go to check about the status of my request? [19:14] Your request to join the SRU team was a while ago. [19:14] I listed a bunch of similar cases for archive admin and release [19:14] But more recently, I've been trying to assess candidates in (private) documents, so they exist now. [19:14] again I don't think my case is what we want to discuss [19:14] Although who should have access is unclear. [19:14] it's just an example I've visibility on [19:15] k, that's good to hear [19:15] maybe you should reply that on the list [19:15] I think an issue here is that we simply don't agree on what is appropriate. I've said in the TB thread that I don't think a team necessarily must have a process for candidates to apply. [19:15] and we should encourage other core teams to do the same [19:15] IMHO, it's OK for the SRU and release teams to be teams that do not have a process to apply. [19:16] So it's not that I've not addressed your concern - we just disagree (which is fine). [19:16] I'm ok with not having a process, even if I think those teams should [19:16] but I do think that if someone wants to step up there should be a process that own them a reply [19:17] it just hurts being ignored and we just risk loosing those contributors [19:17] -just [19:18] In my view, the reply for some of these teams could be "the team's process to add new members is ". That's not really a reply of course, but the natural consequence of my view as above. [19:18] I personally considered leaving the project because I think that's just not how a welcome community should behave [19:19] ok, so let's agree to disagree [19:19] how do we come to a conclusion [19:19] is that something we can vote on? [19:19] risk losing contributors> IMHO, that's really not a problem for my view of the tasks that the SRU, release team and AAs perform. They are IMHO decision making teams. These are contributions, but a rather special kind. [19:19] If the teams cannot perform their duties, then it may be that they need more members. [19:19] sure you can feel because I'm not worth joining those team I'm worthless to Ubuntu [19:20] But if that's not the case, it's not necessarily appropriate to grow the teams, and therefore there's no loss of potential contributors if people cannot join them. [19:20] it's not only about those teams staffing though [19:20] it's also about making contributors feel valued and treated with respect [19:20] trying to step up to help and being ignored isn't a great feeling [19:20] We do need to make sure that everyone feels valued and treated with respect, as much as is reasonable. [19:21] But at the same time, I think it's perfectly fine for a team to not have any positions open. That doesn't diminish the value provided by contributors not on those teams. [19:22] I'm not arguing against being accept or not [19:22] fwiw I don't think it is unreasonable that for each of the teams there should be some documented process about how new members get added - at least something to lay out expectations to others - and that they have a duty to follow up on enquiries from outsiders [19:22] just that people should be able to hear back on whether someone is on the receiving end and about what they can expect [19:22] > and that they have a duty to follow up on enquiries from outsiders [19:23] ^ that's the point I'm trying to make [19:23] that's not the case today [19:23] I agree with teams having a documented process. But if the process is "we will invite and assess new member candidates using process ", then the only reasonable response to a member asking to apply is to be pointed to that documentation. [19:23] That would just be a stock answer. [19:24] well at least that would provide something a bit more formal than what there is today [19:24] Sure. I have no objection to doing that. [19:24] I posted the SRU team's draft process in the ML thread already. [19:24] well if the candidate follows process , what's next [19:25] seb128: if the team's process doesn't involve candidates applying, then there's no process for them to follow. There would be nothing next. [19:26] seb128: you seem to want all teams to have an application process. I think that's a point upon which we disagree. [19:26] alright [19:26] so how do we come to a conclusion [19:26] do we call a vote from the TB members? [19:26] I think we're all agreed that these teams should document a process. [19:26] yep [19:26] So maybe would make some progress by focusing on that? [19:27] that would be a first step [19:27] As the TB, we could ask the teams to produce that documentation. [19:27] We need a list of teams for a start. [19:27] I think SRU, release, AA, backporters to start with? For DMB, it's already an election run by the TB (although usually delegated). [19:27] do we have a list of teams that got delegation powers from the TB? [19:28] Are there any other relevant teams here? [19:28] For upload access the DMB already has process. [19:28] And there are various other teams that just have open membership that probably don't need to be within the scope of this, eg. ~ubuntu-server. [19:29] the main ones imho are release/archive-admin/SRU [19:29] I can't think of any other decision-making teams in Ubuntu right now, except for the various uploading teams whose membership is managed by the DMB. [19:30] Oh, ~ubuntu-security [19:30] CC? but that has a documented election process [19:31] Yes, but that's out of the scope of the TB [19:31] (along with all other community teams directly managed by the CC) [19:31] heh yep ~ubuntu-security - which is essentially ~canonical-security, ie. you have to be a canonical employee of the ubuntu security team [19:32] amurray: that is generally the case but it is not a requirement. The CoC requires that anybody can join that team. [19:32] indeed, I was just stating the current status quo for the team [19:33] OK. But that means that it's within scope for this discussion I think - it's reasonable for ~ubuntu-security to also have a documented process. [19:33] (and that process cannot be Canonical-only, even if it is in practice) [19:33] fair poitn [19:33] +1 [19:33] point [19:34] OK, so how about we start there? I started the section at https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations earlier. [19:35] seb128: how about we look to link to a documented membership process for each of the teams mentioned above into there? [19:35] If the TB today agrees to do that, could seb128 drive that perhaps, asking each team to provide that documentation? [19:35] sounds like a good first step [19:36] I can do that yes [19:36]