| === JanC_ is now known as JanC | ||
| didrocks | o/ | 14:31 |
|---|---|---|
| eslerm | o/ | 14:31 |
| sarnold | good morning | 14:32 |
| dviererbe | o/ | 14:32 |
| didrocks | ok, I think this is only us, let me lead the meeting | 14:33 |
| didrocks | #startmeeting Weekly Main Inclusion Requests status | 14:34 |
| meetingology | Meeting started at 14:34:24 UTC. The chair is didrocks. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 14:34 |
| didrocks | Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage ( eslerm dviererbe ) | 14:34 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 14:34 |
| didrocks | #topic current component mismatches | 14:34 |
| didrocks | Mission: Identify required actions and spread the load among the teams | 14:34 |
| didrocks | #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg | 14:34 |
| didrocks | #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg | 14:34 |
| didrocks | c-m-p: I don’t see anything new, the whole mm/pp stack is in discussion with the desktop team | 14:34 |
| didrocks | c-m: all good too, nothing to add | 14:35 |
| didrocks | #topic New MIRs | 14:35 |
| didrocks | Mission: ensure to assign all incoming reviews for fast processing | 14:35 |
| didrocks | #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:35 |
| didrocks | the status is incorrect on all of them | 14:36 |
| didrocks | jbicha: please, look at https://github.com/canonical/ubuntu-mir for the correct status, it should be New once ready for review | 14:36 |
| sarnold | is it? the process states section has "new/confirmed" even on step 1 | 14:36 |
| didrocks | oh, I still had the old wiki version in mind :) | 14:37 |
| jbicha | In this case, I specifically chose Confirmed, but LP automatically upgrades bugs to Confirmed if someone clicks "this affects me" :/ | 14:37 |
| didrocks | ah, that was maybe why it was changed to it | 14:37 |
| didrocks | ok, my bad then :) | 14:37 |
| didrocks | sorry for the false ping | 14:38 |
| didrocks | ok, so we need to split them | 14:38 |
| didrocks | but as I’m the only non security member here, I think nobody else can take any other? | 14:38 |
| didrocks | and I don’t want to assign for joalif or jamespage with them being away | 14:39 |
| jbicha | the 5 packages are fairly similar to each other | 14:39 |
| didrocks | I can take a second for the next pulse but can’t act more, I already have one | 14:39 |
| sarnold | yeah, at this point it's probably just a question of "how many does didrocks want?" :) | 14:39 |
| didrocks | sarnold: we agreed with management to take 2 by pulse | 14:40 |
| didrocks | this pulse was already full, so next pulse, I already have 1 | 14:40 |
| sarnold | heh | 14:40 |
| didrocks | + another one | 14:40 |
| sarnold | sounds like the start of the cycle, indeed | 14:40 |
| didrocks | but it means I can’t take anymore for the next 2 pulses | 14:40 |
| didrocks | sorry 2 weeks* | 14:40 |
| didrocks | so meh, let’s do that, and maybe that will convince people to add more people to the MIR team :) | 14:41 |
| didrocks | I think libglibmm is the one making more sense, isn’t it jbicha? | 14:41 |
| jbicha | that's fine with me to start there | 14:41 |
| jbicha | oh it actually depends on libsigc++-3.0 though | 14:42 |
| didrocks | jbicha: I see that most of them have a bunch of lintian warnings, some could be fixed if we are working on debian, is it the case? | 14:42 |
| jbicha | libsig actually has a symbols file already :) | 14:42 |
| sarnold | \o/ | 14:42 |
| jbicha | my opinion is that the lintian warnings are harmless, but yes I can fix things in Debian if needed | 14:43 |
| didrocks | jbicha: at worst with lintian override? that way, you get a clean list, and when a new one is introduced, you will notice it rather than being list in the existing list | 14:43 |
| didrocks | thanks! | 14:43 |
| didrocks | ok, taking libsigc++ first | 14:43 |
| didrocks | if joalif or jamespage reads afterwards, please, take one on the list ^ | 14:44 |
| sarnold | "national-encoding"? | 14:44 |
| didrocks | #topic Incomplete bugs / questions | 14:45 |
| didrocks | Mission: Identify required actions and spread the load among the teams | 14:45 |
| didrocks | #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 |
| jbicha | sarnold: I try to ignore m4 files | 14:45 |
| sarnold | jbicha: ahh, apparently, as did I, I saw the 'x86_64-linux-gnu' and assumed it was an .so :) | 14:45 |
| didrocks | ok, on the incomplete list, only tagging and other in progress comments as far as I can see | 14:46 |
| didrocks | let’s move on | 14:46 |
| sarnold | duktape assigned to band_ali, probably for todos? | 14:46 |
| didrocks | right | 14:46 |
| sarnold | and cargo, similar, tagged | 14:46 |
| didrocks | yep | 14:46 |
| didrocks | #topic Process/Documentation improvements | 14:46 |
| didrocks | Mission: Review pending process/documentation pull-requests or issues | 14:46 |
| didrocks | #link https://github.com/canonical/ubuntu-mir/pulls | 14:46 |
| didrocks | #link https://github.com/canonical/ubuntu-mir/issues | 14:46 |
| didrocks | unsure I will have time to go to your PR dviererbe this week, but nice to see this work! | 14:47 |
| dviererbe | No problem :) | 14:47 |
| didrocks | I think for typos, an approval from a peer is enough to merge | 14:48 |
| sarnold | ooo is there an easy way to see the rendered flowchart? | 14:48 |
| dviererbe | Just go to my repo | 14:48 |
| dviererbe | https://github.com/dviererbe/ubuntu-mir/tree/modernize-process-states-overview | 14:48 |
| sarnold | dviererbe: ah! | 14:48 |
| eslerm | \o/ | 14:48 |
| didrocks | that’s nice, I didn’t know that was rendered by GH! | 14:48 |
| dviererbe | I just learned about that this week | 14:49 |
| didrocks | just used mermaid today and rendered a svg… | 14:49 |
| didrocks | so ok, I have some PR to open :) | 14:49 |
| didrocks | ok, let’s move to the next section | 14:50 |
| didrocks | #topic MIR related Security Review Queue | 14:50 |
| didrocks | Mission: Check on progress, do deadlines seem doable? | 14:50 |
| didrocks | Some clients can only work with one, some with the other escaping - the URLs point to the same place. | 14:50 |
| didrocks | #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 |
| didrocks | #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 |
| didrocks | Internal link | 14:50 |
| didrocks | - ensure your teams items are prioritized among each other as you'd expect | 14:50 |
| didrocks | - ensure community requests do not get stomped by teams calling for favors too much | 14:50 |
| didrocks | #link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594 | 14:50 |
| didrocks | sarnold: anything to mention at this point? | 14:50 |
| sarnold | didrocks: eslerm finished cpdb-libs last week \o/ :) and we've assigned tasks around | 14:51 |
| didrocks | ironic that for once, you are more on the security side than the reviewer side :p | 14:51 |
| eslerm | I'm working on dbus-broker | 14:51 |
| didrocks | oh, that will make seb128 happy | 14:51 |
| eslerm | someone signed up for cargo, but since it is incomplete I'll suggest other cargo dependencies | 14:51 |
| didrocks | unsure we got a conclusion on the maintaince side yet | 14:52 |
| didrocks | yeah | 14:52 |
| didrocks | ok, so good progress on that front :) | 14:52 |
| didrocks | #topic Any other business? | 14:52 |
| sarnold | the one missing piece from dbus-daemon does seem like a large risk.. | 14:52 |
| didrocks | exactly | 14:52 |
| didrocks | and we need to know where we are heading to, to prevent doing a MIR security review check for nothing | 14:53 |
| sarnold | we're not interested in *two* running dbus daemons, one for system and one for user | 14:53 |
| eslerm | I could hold off for now | 14:53 |
| didrocks | maybe check with seb128 first, as he was the one checking with foundation IIRC | 14:53 |
| didrocks | apart from breaking dbus (oh wait… broker, not breaker :p) anything else to note? | 14:54 |
| eslerm | I'll ping ~mir-security-review-priority on MM | 14:54 |
| didrocks | sounds good to me | 14:54 |
| sarnold | I think eslerm ought to continue onwards; dbus is an integral part of everything, and getting issues with it sorted out as early as possible seems like a good approach | 14:54 |
| eslerm | I'll just do what Seth suggests :D | 14:54 |
| didrocks | ack! | 14:54 |
| sarnold | and even if we decide to stick with what we've got because it meets gdm's needs, maybe we'll find useful things for upstream to work on before we return | 14:55 |
| sarnold | oh yes! we missed the .../issues/ section earlier | 14:56 |
| sarnold | https://github.com/canonical/ubuntu-mir/issues | 14:56 |
| sarnold | I just added one about team members :) and eslerm added one a few days ago https://github.com/canonical/ubuntu-mir/issues/22 | 14:56 |
| -ubottu:#ubuntu-meeting- Issue 22 in canonical/ubuntu-mir "re-ACK after a set time period" [Open] | 14:56 | |
| didrocks | https://github.com/canonical/ubuntu-mir/issues/24 has been "opened" for years | 14:56 |
| -ubottu:#ubuntu-meeting- Issue 24 in canonical/ubuntu-mir "More team members" [Open] | 14:56 | |
| didrocks | yeah, agreed on 22, but it’s also blocked on 24 still | 14:57 |
| didrocks | anyway, I think we should discuss processes when more team members are around, wdyt? | 14:57 |
| eslerm | +1 | 14:57 |
| dviererbe | +1 | 14:57 |
| sarnold | now that it's written down somewhere, I can trust cpaelzer will be annoyed enough by it to try to drive that through to an answer of how we do this :) | 14:57 |
| didrocks | heh, sounds good! | 14:57 |
| sarnold | that's it for me | 14:58 |
| didrocks | ok, going once… | 14:58 |
| didrocks | going twice… | 14:58 |
| didrocks | and here we go! Thanks everyone :) | 14:58 |
| sarnold | thanks didrocks, dviererbe, eslerm, jbicha :) | 14:58 |
| didrocks | #endmeeting | 14:58 |
| meetingology | Meeting ended at 14:58:40 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-05-30-14.34.moin.txt | 14:58 |
| dviererbe | Thanks everyone! | 14:58 |
| eslerm | thanks for hosting didrocks \o/ | 14:58 |
| didrocks | yw! Have a good week | 14:58 |
| rbasak | o/ | 18:56 |
| amurray | o/ | 18:57 |
| seb128 | hey! :) | 19:00 |
| rbasak | seb128: o/ you're up to chair I think? | 19:00 |
| seb128 | yes | 19:00 |
| seb128 | #startmeeting Technical Board | 19:01 |
| meetingology | Meeting started at 19:01:04 UTC. The chair is seb128. Information about MeetBot at https://wiki.ubuntu.com/meetingology | 19:01 |
| meetingology | Available commands: action, commands, idea, info, link, nick | 19:01 |
| seb128 | #topic Action Review | 19:01 |
| seb128 | ups | 19:02 |
| seb128 | #topic Apologies | 19:02 |
| seb128 | I don't see any on the list/wiki | 19:02 |
| seb128 | Lukasz doesn't seem to be online though | 19:02 |
| seb128 | anyway, let's move one | 19:03 |
| * vorlon waves | 19:03 | |
| seb128 | #topic Action Review | 19:03 |
| seb128 | ACTION: amurray to follow up with backporters team on Mattia's draft charter proposal | 19:03 |
| seb128 | amurray, did you get a reply since the previous meeting? | 19:03 |
| amurray | No - I've sent two emails to the backporters team asking them to ack mattia's proposal but had no response still | 19:03 |
| seb128 | :-/ | 19:04 |
| rbasak | :-( | 19:04 |
| rbasak | At the last meeting I said this: | 19:04 |
| rbasak | It'd be nice to see a conclusion on this. I wonder if it would be appropriate to set a deadline at some point, and if no reply then we just use the current draft and call it done. I wouldn't mind it being long eg. months, but it'd be nice to have _some_ end point. | 19:04 |
| seb128 | I'm +1 with that | 19:04 |
| rbasak | We've already adjusted the draft to their suggestion, dropping what I had originally proposed. | 19:04 |
| vorlon | also +1 | 19:05 |
| rbasak | Could we agree that this draft becomes final at some future date now, and encourage the backporters team to engage with us if they disagree? | 19:05 |
| amurray | I agree - how about I send one more follow-up later today and stipulate that if we get no response within another 2 weeks (that would be over 1 month since my original email asking for their ack) then this will become final | 19:05 |
| rbasak | eg. two months from today, so 30 July. | 19:05 |
| rbasak | Sure. | 19:05 |
| vorlon | I think that should be the default. We want the involved teams to be on board with what we rule, but if they're not going to engage, it's the TB who has the authority here | 19:06 |
| rbasak | I'm easy on the actual date as long as we set one :) | 19:06 |
| seb128 | I was going to suggest start of July, seems similar timeframe | 19:06 |
| rbasak | Sounds like we're all on the same page, so as amurray is driving I suggest he sets the date as he feels appropriate. | 19:06 |
| seb128 | +1 | 19:06 |
| amurray | sure - I prefer going with say 2 weeks to avoid this dragging on much longer | 19:07 |
| rbasak | Sure | 19:07 |
| seb128 | so June 13 ? | 19:08 |
| rbasak | FWIW, we should also work with some of the other teams to establish some similar documentation. I'm not trying to single out the backporters team here! In the past few years, questions have arisen on the scope of the DMB's role, as well as AAs. | 19:08 |
| amurray | I suggest June 12th - that way it falls just before the next TB meeting | 19:09 |
| rbasak | +1 | 19:09 |
| rbasak | Though, to be clear, I don't think it should take a further TB meeting to agree. We're agreeing it now :) | 19:10 |
| rbasak | (but I welcome further discussion at a TB meeting should it arise) | 19:10 |
| amurray | indeed - but this way at that meeting we have a clear outcome with any luck | 19:10 |
| seb128 | #agreed amurray to send one more follow-up later today to the backporters team and stipulate that if we get no response before June 12th then this will become final | 19:11 |
| meetingology | AGREED: amurray to send one more follow-up later today to the backporters team and stipulate that if we get no response before June 12th then this will become final | 19:11 |
| vorlon | also means that if there is any feedback given on the current draft we can quickly ratify those changes | 19:11 |
| rbasak | seb128: o/ | 19:12 |
| seb128 | k, let's move on? | 19:12 |
| seb128 | rbasak, yes? | 19:12 |
| rbasak | Minor point: "if we get no response before" -> that sounds like if they respond, then it won't become final. | 19:12 |
| seb128 | how do I edit an agreed? :p | 19:12 |
| rbasak | But I think we just agreed to make it final regardless, on 12 June, unless the TB (and only the TB) decide otherwise before that date. | 19:13 |
| rbasak | You can use #undo | 19:13 |
| seb128 | #undo | 19:13 |
| meetingology | Removing item from minutes: AGREED | 19:13 |
| rbasak | Then #agreed something else | 19:13 |
| seb128 | thanks | 19:13 |
| seb128 | #agreed amurray to send one more follow-up later today to the backporters team and stipulate that we set June 12th as the limit for changes to the draft unless the TB decides otherwise | 19:14 |
| meetingology | AGREED: amurray to send one more follow-up later today to the backporters team and stipulate that we set June 12th as the limit for changes to the draft unless the TB decides otherwise | 19:14 |
| seb128 | better? | 19:15 |
| rbasak | Sure | 19:15 |
| rbasak | Thanks | 19:15 |
| seb128 | thanks! | 19:15 |
| seb128 | moving on | 19:15 |
| seb128 | ACTION: seb128 to help draft an exception to the "must build on all architectures" requirement for snaps | 19:15 |
| rbasak | I'll discuss the status of the draft in a bit. | 19:15 |
| rbasak | But we're a bit blocked on this now :-/ | 19:15 |
| seb128 | sorry, I've still been struggling with finding time for those items but rbasak started editing which pushed me to go back to it now | 19:16 |
| seb128 | ACTION: seb128/amurray/sil200 to help drafting the snap-store Ubuntu-specific tracks usage | 19:16 |
| seb128 | similar | 19:16 |
| seb128 | ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification | 19:16 |
| rbasak | Carry this please - I've been focused on the other thing | 19:16 |
| seb128 | 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 | 19:16 |
| rbasak | Carry again I guess, as he's not here | 19:17 |
| seb128 | Lukasz is not around today so that's another carry over | 19:17 |
| seb128 | #topic Scan the mailing list archive for anything we missed (standing item) | 19:17 |
| seb128 | nothing recent on the list | 19:17 |
| rbasak | I see some emails from amurray :-P | 19:17 |
| seb128 | lol | 19:17 |
| seb128 | #topic Check up on community bugs and techboard bugs | 19:17 |
| rbasak | Oh, did we lose the progress item on the third party repository requirements doc in general? I'd like to discuss that please. | 19:18 |
| amurray | same | 19:18 |
| seb128 | rbasak, I was expecting that it come as an AOB since we don't have a specific item on the agenda for it | 19:19 |
| rbasak | ack | 19:19 |
| seb128 | but yes we should add it back as an action | 19:19 |
| seb128 | #info No new community bug activity | 19:19 |
| seb128 | #topic Select a chair for the next meeting | 19:19 |
| seb128 | next would be vorlon and if we follow the ordering on the launchpad page Lukasz as a backup | 19:20 |
| seb128 | #info vorlon will chair next, with sil2100 as backup | 19:21 |
| * vorlon nods | 19:21 | |
| seb128 | #topic third party repository requirements status update | 19:21 |
| seb128 | rbasak, ^ | 19:21 |
| rbasak | I have been working on the doc and I think it's ready. Apart from the appendices and the wording of the "build on all architectures exception" for the desktop packages that I think, we agree we need. | 19:22 |
| vorlon | fwiw I have another topic for AOB after this | 19:22 |
| rbasak | Next, I'd like to publish this for wider feedback. | 19:22 |
| rbasak | Before I do that, could the TB please review the main body of the document and check you're happy with it? | 19:22 |
| rbasak | Perhaps we could give all TB members an opportunity to do that before our next meeting? | 19:22 |
| vorlon | sounds good to me | 19:22 |
| amurray | rbasak: so I noticed there is nothing in the document regarding testability- ie. how do we integrate a seeded snap with britney? | 19:22 |
| rbasak | And unless there are any further comments from the TB, I'll present that as the TB's draft position, pending further feedback. | 19:23 |
| rbasak | amurray: I'm not sure I follow | 19:23 |
| amurray | do we want to stipulate that a seeded snap must be able to be tested / have some tests that can be run to ensure it is "stable" before being released? | 19:24 |
| rbasak | I think we should definitely do those things. But I'm not sure it should be within the scope of this doc - just as we leave the specifics of how to test debs up to Ubuntu developers. | 19:24 |
| rbasak | For example a package can be a deb in the Ubuntu archive with no tests whatsoever - that's currently permitted, even if it's not best practice. | 19:25 |
| seb128 | well we have a MIR process, it sort of opens the question of it should apply to snaps that we want seeded | 19:25 |
| rbasak | Currently the MIR team may decide to permit something in main without tests though, without involvement of the TB. | 19:25 |
| rbasak | So in my mind, for a seeded snap, we're leaving that kind of decision to the Ubuntu developer making the change (in the seed, presumably). | 19:26 |
| rbasak | It's a good question though. | 19:26 |
| amurray | I don't want to be too specific here - but I do want to make sure that we can maintain quality for any third party packages and I see testing as a big part of that | 19:27 |
| rbasak | Do you think we should require something? And if so, would we require this for debs as well? | 19:27 |
| rbasak | amurray: I see your concern addressed by "Proposed requirement C: the package maintainer agrees to maintain the package for the lifetime of the Ubuntu release" already | 19:27 |
| rbasak | And the paragraph that says "the precise meaning of "maintain", is enforced by trust only" | 19:27 |
| rbasak | IOW - we agree that this is important, but we aren't dictating the specifics | 19:28 |
| vorlon | agreed w/ rbasak on this | 19:28 |
| seb128 | but should a pre-installed snap get a +1 from the MIR team? | 19:28 |
| vorlon | I like that idea but think we should discuss it with the MIR team first to make sure they're comfortable taking on that duty | 19:29 |
| amurray | for debs we have britney and proposed-migration that enforces a level of quality on SRUs (assuming there are dep8 tests etc) by doing automated testing - if cups becomes a snap, how do we make sure it doesn't regress on updates in future releases? a lot of stuff depends on cups so I see this as important (as a topical example) | 19:30 |
| rbasak | I have no objection to a process requirement to get a review from some appropriate team | 19:30 |
| rbasak | But whether that's the TB, the MIR team, or some new kind of snap-MIR team, is an open question I think. | 19:30 |
| rbasak | Another option might be to start softer - by requiring such changes to be announced eg. to ubuntu-devel@ and be done before eg. feature freeze. That would allow the TB to object, but without the friction of a team requiring an approval. | 19:31 |
| rbasak | Or indeed to give some notice before doing it | 19:32 |
| rbasak | (or committing to doing it) | 19:32 |
| rbasak | amurray: would that address your concern with your cups example? | 19:33 |
| amurray | yes I think that would work | 19:33 |
| amurray | thanks | 19:34 |
| rbasak | So I'm open to any of the above. I would add it as a snap-specific policy requirement in the document (so into appendix C) | 19:34 |
| rbasak | Which of those options should I take? | 19:34 |
| rbasak | Personally I think I'd favour "soft, with notice" if that works for everyone? | 19:35 |
| amurray | +1 | 19:35 |
| seb128 | +1 | 19:36 |
| vorlon | +1 | 19:36 |
| rbasak | I'll write that up then. Thanks! | 19:37 |
| amurray | thank you :) | 19:37 |
| rbasak | So, to summarise, homework for the TB: you have until the next meeting to study the doc and raise any other concerns you may have at the next meeting. | 19:37 |
| rbasak | And I'll write up the "snap MIR" process (just notice) requirement into appendix C. | 19:38 |
| rbasak | Any other comments on this topic for today? | 19:38 |
| vorlon | none from me | 19:38 |
| seb128 | #agreed the TB members have until the next meeting to review the third party repository requirements document and raise concerns | 19:39 |
| meetingology | AGREED: the TB members have until the next meeting to review the third party repository requirements document and raise concerns | 19:39 |
| seb128 | #topic AOB | 19:39 |
| seb128 | vorlon, ? | 19:39 |
| vorlon | last meeting we talked about the question of core teams governance | 19:40 |
| vorlon | I had just sent an email to the private thread, which I understood folks had the action to review and reply to? | 19:40 |
| vorlon | I haven't seen any responses yet :) | 19:40 |
| rbasak | Oh, right | 19:40 |
| rbasak | IIRC, we said we'd make it public today? | 19:41 |
| seb128 | yes, in fact I wanted to mention that, it's another of those action items I failed at acting on | 19:41 |
| vorlon | going back to meeting log to see what we said | 19:41 |
| seb128 | would people be ok to postpone until the next meeting? | 19:41 |
| vorlon | https://irclogs.ubuntu.com/2023/05/16/%23ubuntu-meeting.html#t19:10 | 19:42 |
| seb128 | Lukasz hasn't been around/commented on it | 19:42 |
| rbasak | Sure. The thread hasn't had any activity recently. Perhaps we could agree that all further discussion on that topic can be expected to be public? | 19:42 |
| vorlon | weeks were given and no objections were raised, so maybe "replay the thread but publicly" is the correct next action here? | 19:42 |
| rbasak | +1 | 19:42 |
| seb128 | wfm | 19:42 |
| amurray | +1 | 19:42 |
| vorlon | in which case I guess it would be an action for seb128 to kick it off? :) | 19:43 |
| vorlon | if I correctly understand what is meant by "replay" | 19:43 |
| rbasak | That was my wording IIRC, and yes I think you do. | 19:43 |
| seb128 | #agreed seb128 to resend 'core teams governance' email to the public techboard list | 19:44 |
| meetingology | AGREED: seb128 to resend 'core teams governance' email to the public techboard list | 19:44 |
| rbasak | Because if seb128 posts it, then I can provide basically the same reply I did privately, and then the public will be able to follow my position/opinion on it. | 19:44 |
| seb128 | #undo | 19:44 |
| meetingology | Removing item from minutes: AGREED | 19:44 |
| seb128 | #agreed seb128 to resend the 'core teams governance' email to the public techboard list | 19:44 |
| meetingology | AGREED: seb128 to resend the 'core teams governance' email to the public techboard list | 19:44 |
| seb128 | any other AOB? | 19:44 |
| amurray | nothing from me | 19:45 |
| vorlon | nor me | 19:45 |
| rbasak | None from me. | 19:45 |
| seb128 | ok, it's a wrap then, thanks everyone! | 19:45 |
| rbasak | Thank you all for a productive meeting! | 19:45 |
| seb128 | #endmeeting | 19:45 |
| meetingology | Meeting ended at 19:45:21 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2023/ubuntu-meeting.2023-05-30-19.01.moin.txt | 19:45 |
| sarnold | (heh "any other AOB" :) | 19:45 |
| vorlon | thanks, all! | 19:45 |
| seb128 | sarnold, :p | 19:45 |
| vorlon | sarnold: "AOOB" | 19:45 |
| sarnold | lol | 19:45 |
| amurray | thanks folks | 19:45 |
| === Bashing-1m is now known as Bashing-om | ||
| === bdrung_ is now known as bdrung | ||
| === JanC is now known as Guest503 | ||
| === JanC_ is now known as JanC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
