summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMichał Górny <mgorny@gentoo.org>2021-10-10 22:06:35 +0200
committerMichał Górny <mgorny@gentoo.org>2021-10-10 22:06:35 +0200
commit5ff928246285b6beb79f220fc7b8028c39976277 (patch)
tree90fd9cf7517cbc78edc3f565e19d0f8c05b7cbde
parent20210912: add meeting summary (diff)
downloadcouncil-5ff928246285b6beb79f220fc7b8028c39976277.tar.gz
council-5ff928246285b6beb79f220fc7b8028c39976277.tar.bz2
council-5ff928246285b6beb79f220fc7b8028c39976277.zip
20211010: add meeting log
Signed-off-by: Michał Górny <mgorny@gentoo.org>
-rw-r--r--meeting-logs/20211010.txt327
-rw-r--r--meeting-logs/20211010.txt.asc11
2 files changed, 338 insertions, 0 deletions
diff --git a/meeting-logs/20211010.txt b/meeting-logs/20211010.txt
new file mode 100644
index 0000000..0229ac6
--- /dev/null
+++ b/meeting-logs/20211010.txt
@@ -0,0 +1,327 @@
+[21:00:16] <@mgorny> !expn council
+[21:00:17] <willikins> council = dilfridge,gyakovlev,marecki,mattst88,mgorny,sam,ulm,
+[21:00:21] <@mgorny> zlogene: ^
+[21:00:27] -*- sam_ here
+[21:00:27] -*- zlogene here
+[21:00:31] -*- dilfridge here
+[21:00:33] -*- Marecki here
+[21:00:38] -*- gyakovlev here
+[21:00:49] -*- mgorny here
+[21:00:59] -*- ulm here
+[21:01:08] <@mgorny> ok, that was ^ 1. roll call
+[21:01:14] <@mgorny> ftr, zlogene is here for mattst88
+[21:01:21] <@mgorny> agenda: https://archives.gentoo.org/gentoo-project/message/6b68ca6577a2b343d1b5d9f76695330a
+[21:01:35] <@mgorny> next:
+[21:01:37] <@mgorny> 2. Operating model of Gentoo project and Gentoo Foundation [1] (from last month's agenda)
+[21:01:46] <@mgorny> https://archives.gentoo.org/gentoo-project/message/2fea68fbd3a193098fd97ddac04a3e3d
+[21:01:49] <@mgorny> antarus: the floor is yours
+[21:02:35] <@dilfridge> seems like antarus is floored
+[21:02:36] <+antarus> my basic question currently is like, is the Council willing to be the body that decides how to spend Gentoo's money
+[21:03:11] <@mgorny> i think it's more like 'unevitable' eventually
+[21:03:22] <+antarus> because in the ideal scheme the Foundation would go away (dissolve) and the assets would be held in an umbrella; the umbrellas typically have some liason for the volunteer part of the organization
+[21:03:23] -*- dilfridge would answer that question yes as far as himself is concerned
+[21:03:39] <+antarus> currently thats nominally the elected board of trustees of the Foundation
+[21:03:44] <@ulm> antarus: formally the board would still have to acknowledge any requests I think?
+[21:03:50] <@dilfridge> and "unevitable" meets it too
+[21:03:54] <@ulm> because the council isn't a legal entity
+[21:03:59] <+antarus> I seem to recall ulm having objections aroud the council being 'technical' and not administrative
+[21:04:14] <@dilfridge> ulm: if there is no board and only an umbrella org...
+[21:04:14] <+antarus> ulm: sure, but that would be pro forma
+[21:04:26] <@ulm> antarus: wfm then
+[21:04:31] <@dilfridge> ... then it would at most be the board of the umbrella
+[21:04:32] <@mgorny> i think that for the time being it would be best to have two layers
+[21:04:36] <@mgorny> council first, trustees confirm
+[21:04:40] <+antarus> ulm: like obviously teh board (and umbrella) would reject illegal requests ;)
+[21:05:14] <@Marecki> mgorny: Why this particular way?
+[21:05:33] <@ulm> someone has to sign the cheque :)
+[21:05:36] <@dilfridge> because it paves the way for the second layer going away
+[21:05:46] <@ulm> and the council cannot
+[21:05:47] <@mgorny> Marecki: what dilfridge said
+[21:05:48] <+antarus> Marecki: I think most of the judgement is up front (the council decides asset allocation)
+[21:05:53] <@sam_> right, and it also helps "council driven development" or whatever
+[21:06:12] <+antarus> Marecki: the board (or umbrella) is mostly, signing the cheques as mentioned
+[21:06:42] <@Marecki> Just to clarify, I do not object. I just wanted to hear the rationale.
+[21:07:02] <@dilfridge> I am fully aware that this will increase council workload somewhat, but that is fully countered by the fact that technical and financial decisions can go hand in hand
+[21:07:39] <@mgorny> should we vote on that?
+[21:07:53] <@gyakovlev> I'm not a lawyer, but does in make council a legan entity in any way?
+[21:08:15] <@sam_> dilfridge++
+[21:08:30] <@sam_> (also, make us work for our non-existent money!)
+[21:08:46] <+antarus> gyakovlev: currently the board is the legal entity
+[21:08:49] <@Marecki> Any time frame for when this arrangement would be expected to be replaced by council-only decisions?
+[21:08:55] <@dilfridge> I suspect we'd end up for example with an in-between half-month meeting, which does only finance discussion as preparation for the real one where decisions are made
+[21:09:17] <+antarus> gyakovlev: we will change the boards decision making process to be 'whatever the council decides to spend money on, plus pro forma legal review'
+[21:09:28] <+antarus> gyakovlev: the umbrellas tend to operate similarly.
+[21:09:51] <@mgorny> antarus: for the record, how many financial decisions does the Foundation handle annually?
+[21:09:55] <@dilfridge> gyakovlev: you can buy and sell bitcoin depending on the actions of a hamster. that doesnt make the hamster an investment banker.
+[21:10:01] <@mgorny> (that would move to the Council)
+[21:10:23] <+soap> dilfridge: correct, the hamster if mroe intelligent than an investment banker
+[21:10:23] <+antarus> mgorny: excluding our auto-pay expenses, probably < 1 per month.
+[21:10:30] <@gyakovlev> wfm then, I can't be a member of an org with financial power (yet)
+[21:10:38] <@dilfridge> https://www.bbc.com/news/technology-58707641 for reference
+[21:10:57] <+antarus> (infra pays various sponsors automatically; these are typically not reviewed at all and just fall into an annual infra-budget.)
+[21:11:00] <@mgorny> i suppose we can hold a new Council election when we transition to an umbrella
+[21:11:14] <@ulm> gyakovlev: same problem for me, but I don't think that the council would qualify as a corporation by any definition
+[21:11:22] <@ulm> IANAL though
+[21:11:25] <@sam_> we're advising the foundation on what to do
+[21:11:29] <@sam_> and later, possibly an umbrella
+[21:11:42] <@gyakovlev> ulm: well you are certainly more laywer than me lol
+[21:11:47] <@sam_> they still have to do due diligence and so on
+[21:11:50] <@gyakovlev> as in non-being a lawyer
+[21:11:59] <+antarus> The Foundation also has various operating expenses (mail, telephone, fax, etc) that we will likely continue to pay with little oversight
+[21:12:06] <+antarus> but just FYI those amount to < 100$/y
+[21:12:43] <+antarus> Infra is happy to submit an actual budget if needed.
+[21:12:55] <+antarus> Its been pretty informal, but robin and I are on infra and on the board.
+[21:13:55] <@gyakovlev> ok so basically antarus's plan is turn us into a hamster.
+[21:14:10] <+antarus> your words sir, not mine ;)
+[21:14:13] <@sam_> this all sounds pretty reasonable and like a good way forward
+[21:14:16] <@sam_> anyone got any concerns?
+[21:14:18] <@dilfridge> ++
+[21:14:32] <@gyakovlev> seems ok to me
+[21:14:48] <@mgorny> should i put a motion to vote on
+[21:14:49] <@mgorny> ?
+[21:14:51] <@Marecki> I repeat my question about the time frame, if any, for switching to council-only decisions
+[21:15:12] <@ulm> what about assets like the gentoo trademark? any change there?
+[21:15:22] <+antarus> Marecki: so structurally, even with an umbrella the umbrella still has oversight
+[21:15:42] <@dilfridge> for now, not, I guess... what happens if we go to an umbrella is worth further discussion
+[21:15:43] <+antarus> Marecki: if you spend all the gentoo money hiring a hitman; obviously if they know that they will reject that txn.
+[21:16:05] <+antarus> Marecki: if you are asking when we are moving to the umbrella I don't think I have a timeframe in mind
+[21:16:06] <@sam_> right, what dilfridge said. atm, no, not really
+[21:16:08] <@dilfridge> antarus: you need to sell it as "support for the friends of the italian opera"
+[21:16:13] <@Marecki> antarus: Let me clarify: I meant phasing out the trustee-review part, which the others have already mentioned.
+[21:16:47] <@Marecki> <dilfridge> because it paves the way for the second layer going away
+[21:17:14] <+antarus> ulm: the goal is for the umbrella to hold the trademarks (as well as other assets)
+[21:17:15] <@mgorny> Marecki: i think there's a misunderstanding here, we really meant it's going to be replaced by umbrella reviewing expenses
+[21:17:15] <@sam_> that can't go away until there's an umbrella which may never happen
+[21:17:20] <@sam_> right
+[21:17:51] <@Marecki> mgorny: Okay, so the trustee review would go away as soon as we've joined an umbrella, if we do?
+[21:18:16] <@mgorny> Marecki: + some overlap time, i suspect
+[21:18:17] <@ulm> trustees would go away completely IIUC
+[21:18:56] <@Marecki> OK, clear enough for me now. No further questions.
+[21:21:46] <@mgorny> how does the following motion sound? "The Council will be responsible for approving Gentoo expenses going forward (with Trustees/umbrella reviewing Council decisions)"
+[21:22:13] <@dilfridge> works for me
+[21:22:19] <+zlogene> +1
+[21:23:08] <@mgorny> ok, so please vote
+[21:23:11] <@mgorny> motion: The Council will be responsible for approving Gentoo expenses going forward (with Trustees/umbrella reviewing Council decisions)
+[21:23:26] -*- sam_ yes
+[21:23:28] -*- zlogene yes
+[21:23:32] -*- Marecki yes
+[21:23:39] -*- dilfridge yes
+[21:23:39] -*- mgorny yes
+[21:23:41] -*- ulm yes
+[21:23:57] -*- gyakovlev yes
+[21:24:15] <@mgorny> passed unanimously
+[21:24:29] <+antarus> superb, thanks
+[21:24:31] <@mgorny> antarus: anything else or should we move to the next item?
+[21:24:42] <+antarus> No practical issues
+[21:24:58] <+antarus> (there is a theoretical issue of fundraising, but practically Gentoo has had sufficient user donations to cover all expenses)
+[21:25:06] <+antarus> so its not a real issue unless we ramp up spending IMHO
+[21:25:17] <+antarus> so table it and move on and I get to eat brunch ;)
+[21:25:28] <@mgorny> ok, cool
+[21:25:38] <@mgorny> 3. Open bugs with Council participation
+[21:26:08] <@mgorny> Bug 736760 - Application to Software Freedom Conservancy
+[21:26:09] <willikins> https://bugs.gentoo.org/736760 "Application to Software Freedom Conservancy"; Gentoo Foundation, Proposals; CONF; mgorny:trustees
+[21:26:29] <@mgorny> sam_ has pinged, no reply so far
+[21:26:34] <@mgorny> antarus: ^ you still here?
+[21:27:55] <@sam_> i'd appreciate an update on what's happening wrt trustees + umbrella in general
+[21:27:59] <@sam_> but maybe that's for next time
+[21:27:59] <@mgorny> maybe we should just un-cc council? it's not like we're reiterating a bug for any other option every meeting
+[21:28:03] <@sam_> yeah
+[21:28:17] <@Marecki> Might as well...
+[21:29:00] <@mgorny> ok, will do
+[21:29:10] <@mgorny> Bug 786105 - access to manage projects on GH
+[21:29:11] <willikins> mgorny: https://bugs.gentoo.org/786105 "access to manage projects on GH"; Gentoo Infrastructure, GitHub; CONF; vapier:github
+[21:29:20] <@dilfridge> sigh
+[21:29:28] <@mgorny> this has been also raised on the ml, 4 days prior to the meeting
+[21:29:46] <@mgorny> formally speaking, i'd prefer if we deferred this until the next meeting to give time for a public discussion
+[21:29:57] <@mgorny> (but i do not insist)
+[21:30:11] <@ulm> is it just about this particular case, or about a general policy if only infra can create repos there?
+[21:30:18] <@sam_> i don't think i mind any of it in principle but given nobody has said.. anything about it on the ML, I'm not sure it's ready for us to decide on it
+[21:30:20] <@mgorny> https://archives.gentoo.org/gentoo-project/message/ec2b560480627371a7bda5c85924eddd
+[21:30:21] <@ulm> in contrast to any dev
+[21:30:57] -*- ulm isn't entirely certain if he understands its current policy
+[21:31:01] <@dilfridge> I dont really see vapier's attitude here helpful. Disappears for ages and then wants special treatment and all.
+[21:31:19] <@gyakovlev> FTR: I and some other projects already use workflows, tags, PRs and other features. it already works fine. what else is needed?
+[21:31:31] <@mgorny> ulm: the request on ml suggests any dev but i suppose infra will still grant requests per-repo
+[21:31:31] <@gyakovlev> primary repos are still on infra, I can push tags there
+[21:31:39] <@gyakovlev> but it does not stop worflows from working
+[21:31:42] <@sam_> gyakovlev: ... right
+[21:31:43] <+zlogene> dilfridge: honestly we gain nothing and loose nothing, it turns out actions are not locked in our org
+[21:31:57] <@dilfridge> also, we now have a functioning setup with github (^ see the remark about actions).
+[21:32:03] <@sam_> gyakovlev: i think MAYBE he can't make proper 'releases'
+[21:32:20] <@sam_> but the distfiles hosting bit is misleading I think
+[21:32:20] <@dilfridge> github "releases" are an abomination in most cases
+[21:32:22] <@gyakovlev> idk about releases and how it works, but isn't tag just enough?
+[21:32:26] <@sam_> yeah i just use tags
+[21:32:28] <@mgorny> the request started with the OP requesting additional powers on github repo
+[21:32:48] <@mgorny> he wanted to create releases on gh and attach files there as the source of truth
+[21:33:03] <@mgorny> (i.e. presumably to use in SRC_URI)
+[21:33:10] <@gyakovlev> additional powers needs to be discussed with infra and github team, so it needs more bikeshedding with people involved.
+[21:33:19] <@sam_> mgorny: I suspect part of this was his misunderstanding in the bug, btw, because he seemed to think we can't use d.g.o for that
+[21:33:20] <@gyakovlev> other features from request already work fine.
+[21:33:25] <@sam_> mgorny: because of some outdated wiki link we should fix
+[21:33:28] <+zlogene> if he needs it to setup actions, then he does not need it, if he wants releases, then why?
+[21:33:30] <@dilfridge> as far as I understand it, our current treatment of gh has the big advantage that it's mostly "stateless"
+[21:33:36] <@sam_> gyakovlev++
+[21:33:44] <@Marecki> ...which is the part I am not a fan of. I know this is very much an arbitrary division but I wouldn't like to have any gentoo/ repo host its files there.
+[21:34:01] <@dilfridge> exactly.
+[21:34:07] <@mgorny> he didn't provide any rationale why he can't use d.g.o like any other developer
+[21:34:12] <@gyakovlev> cgit distfiles from tags work fine
+[21:34:13] <@Marecki> For me, our GitHub mirrors serve only one purpose: to increase our interaction with users familiar with it.
+[21:34:16] <@sam_> mgorny: he did, but I think it was based on a misunderstanding
+[21:34:22] <@sam_> mgorny: he linked to a random infra wiki page which is obsolete/outdated
+[21:34:31] <@gyakovlev> I'm just trying to understand what releases bring to the table
+[21:34:35] <@sam_> he seemed to think devs should use mirror://gentoo (now forbidden) or an external source, not d.g.o
+[21:34:42] <@sam_> i think that's the root of this, but we can't be sure obviously
+[21:34:46] <@dilfridge> the discussion on whether to use d.g.o or not has raged back and forth for decades
+[21:34:46] <@mgorny> not that d.g.o is perfect but i don't think we need to add another intermediate solution before infra fiinally adds proper distfile hosting
+[21:35:06] <@Marecki> Nothing more. It WOULD be nice if we could have our own Gitlab instance but it's not that we can't live with the current set-up.
+[21:35:10] <@gyakovlev> https://gitweb.gentoo.org/proj/${PN}.git/snapshot/${P}.tar.bz2
+[21:35:10] <@gyakovlev> ^^^
+[21:35:14] <@dilfridge> but the current recommendation is clearly, "put stuff into https://dev.gentoo.org/~developer/..."
+[21:35:22] <@sam_> yes
+[21:35:25] <@gyakovlev> what's wrong with cgit snapshots?
+[21:35:26] <+zlogene> gyakovlev: release is created from the tag
+[21:35:31] <@sam_> gyakovlev: not stable necessarily
+[21:35:32] <@mgorny> gyakovlev: i think it's actually about generated tarballs
+[21:35:35] <@mgorny> e.g. when you use autotools
+[21:35:37] <@sam_> oh and that too
+[21:35:43] <@dilfridge> gyakovlev: nothing, works as well, as long as you dont need autoconf/automake/...
+[21:35:44] <@sam_> dilfridge: i'll follow up with infra people / fix the wiki page myself too btw
+[21:36:07] <@gyakovlev> dilfridge: to skip autoreconf invocation?
+[21:36:13] <@dilfridge> yes
+[21:36:30] <@dilfridge> ie. basesystem where that is verboten
+[21:36:35] <@sam_> (re https://bugs.gentoo.org/786105#c20)
+[21:36:42] <@sam_> or maybe for other distros, which is important for say pax-utils
+[21:36:46] <@gyakovlev> that is a usecase indeed, I've seen github projects providing tarballs with pre-generated autostuff in addition to snapshot tarball.
+[21:37:09] <@sam_> _in any case_
+[21:37:13] <@dilfridge> ok from the discussion
+[21:37:18] <@dilfridge> we have two options
+[21:37:18] <@sam_> the fact that this discussion is going on so far means that there's no consensus
+[21:37:22] <@sam_> i think we want ML discussion first
+[21:37:24] <@dilfridge> 1) decline, 2) back to ml
+[21:37:38] <@ulm> back to ml IMHO
+[21:37:46] <@gyakovlev> yeah 2) - back to ML, for clarifications. seems most of the stuff is already supported.
+[21:37:46] <@mgorny> ftr iirc the current github admins are me and robin
+[21:37:56] <@sam_> back to ML please and we can speak to infra and such if needed about alternatives or if it's feasible to allow anything he wants via other means or via github, etc
+[21:38:02] <@sam_> this needs more people speaking to each other
+[21:38:05] <@sam_> like gyakovlev said
+[21:38:05] <@Marecki> Were this only up to me I would decline but I feel that wouldn't be fair. Back to ML, please.
+[21:38:08] <@dilfridge> works for me, but in the end the ^ github admins need to do the work.
+[21:38:11] <+zlogene> mgorny: you can add me so I assist via github internals :p
+[21:38:14] <@ulm> we need to understand what his request is, and why
+[21:38:30] <@mgorny> back to the ml then
+[21:38:42] <@dilfridge> ulm: we can also ask him "just do it the same way as everyone else, ffs"
+[21:38:49] <@mgorny> fun item incoming
+[21:38:56] <@mgorny> Bug 807193 - virtual/udev: switch to sys-fs/udev as primary provider on musl
+[21:38:57] <willikins> mgorny: https://bugs.gentoo.org/807193 "virtual/udev: switch to sys-fs/udev as primary provider on musl"; Gentoo Linux, Current packages; CONF; soap:council
+[21:39:06] -*- dilfridge yes
+[21:39:09] <@dilfridge> next
+[21:39:16] <@ulm> that's already done in the ebuild
+[21:39:17] -*- Marecki yes
+[21:39:20] <@gyakovlev> idk why it's even on council agenda,
+[21:39:23] <@ulm> why do we have to vote on it?
+[21:39:32] <@gyakovlev> it's kinda yes indeed, there's no way around it.
+[21:39:34] <@dilfridge> ulm: to sprinkle it with our blessing
+[21:39:35] <@sam_> i did raise this in private before
+[21:39:37] <@mgorny> apparently someone referenced bug 575718
+[21:39:38] <willikins> mgorny: https://bugs.gentoo.org/575718 "Request for council decision RE virtual/udev default provider"; Gentoo Linux, [OLD] Core system; RESO, FIXE; rich0:council
+[21:39:39] <@Marecki> gyakovlev: For historic reasons only.
+[21:39:45] <@sam_> let me clarify real quick: we said musl in the bug summary there but this is actually about formal reversal of the original decision for all profiles
+[21:40:02] <@sam_> this has already happened because nobody realised it was even decided by the council (or mentioned it)
+[21:40:04] <@ulm> we cannot reverse the previous decision
+[21:40:10] <@sam_> you know what I mean..
+[21:40:15] <@ulm> we switched to eudev
+[21:40:38] <@mgorny> so, do we need to vote on anything here, or just close the bug?
+[21:40:42] <@ulm> that doesn't imply that we need another decision to switch back
+[21:40:54] <@sam_> i'd say it does given the council had to bless the original change
+[21:41:00] -*- dilfridge is getting a migraine
+[21:41:00] <@mgorny> (vote may be faster than discussing whether we need to vote..)
+[21:41:03] <@sam_> ^^
+[21:41:06] <@gyakovlev> ^
+[21:41:08] <@dilfridge> this
+[21:41:11] <@sam_> also, again, nobody objected to this when I mentioned it in private
+[21:41:17] <@ulm> I'd be tempted to vote no :p
+[21:41:18] <@sam_> this is really just a formality
+[21:41:44] <@mgorny> motion: approve switching the default virtual/udev provider to sys-fs/udev
+[21:41:53] -*- dilfridge yes
+[21:41:55] -*- gyakovlev yes
+[21:41:58] -*- zlogene yes
+[21:41:59] -*- mgorny yes
+[21:42:01] -*- ulm abstains
+[21:42:04] -*- sam_ yes (it's already happened and the eudev doesn't wish to continue anymore)
+[21:42:07] -*- Marecki yes
+[21:42:18] <@mgorny> ok, 6 yes votes, 1 abstention, motion passed
+[21:42:34] <@mgorny> 4. Open floor
+[21:42:35] <@sam_> thanks
+[21:43:25] <@mgorny> regarding umbrellas, i think it's one of these things that will happen suddenly when someone starts doing stuff
+[21:43:58] <+zlogene> mgorny: has anybody replied our requests ever?
+[21:44:11] <@mgorny> zlogene: could you be more specific? you mean umbrellas?
+[21:44:39] <+zlogene> mgorny: oh yes
+[21:44:46] <@mgorny> yes
+[21:45:29] <@mgorny> SFC replied negatively ;-)
+[21:45:40] <@mgorny> SPI i think stopped replying at some point
+[21:45:55] <@mgorny> IIRC we had some videochat with LF and it's rather positive
+[21:46:51] <@mgorny> and the one whose name i don't recall is basically waiting for our decision
+[21:47:02] <+antarus> the opencollective one?
+[21:47:05] <@mgorny> yes
+[21:47:27] <@ulm> that one didn't look like a perfect fit to me
+[21:47:48] <@mgorny> it feels like online budget management tool
+[21:47:57] <@mgorny> with other services being handled manually
+[21:48:10] <@sam_> yeah
+[21:48:12] <@Marecki> Oh, I've got one. vapier has mentioned Gentoo Gitlab in the bug, are there in fact any plans to have it?
+[21:48:31] <+antarus> gitlab.gentoo.org exists ;)
+[21:48:48] <+antarus> we don't have currently any plans to offer it though
+[21:49:01] <@dilfridge> that was, kinda, rollercoasterish
+[21:49:25] <+antarus> I'd be interested in a team to manage it
+[21:49:28] <@gyakovlev> gitlab is quite labour intensive to implement and maintain properly. just sayin.
+[21:49:36] <+antarus> afaik its just like 5% me, and some of ajak's time
+[21:49:39] <@gyakovlev> yeah it may need a team indeed.
+[21:50:07] <+antarus> we are running the omnibus container with ..ldap auth, afaik?
+[21:50:12] <+antarus> or keycloak? I forget honestly ;)
+[21:50:37] <@Marecki> antarus: Fair enough. And should we start moving in this direction I would be willing to work on it, seeing as I've been managing (to various degree) Gitlab instances for my last three jobs :-)
+[21:50:55] <+antarus> great
+[21:51:32] <+antarus> I do not believe there are actually any technical imitations stopping you from using gitlab.g.o, fwiw
+[21:51:47] <+antarus> other than like, there are no backups, no CI, no proper setup, etc :)
+[21:51:52] <@dilfridge> we should probably start testing it with some low-traffic stuff
+[21:52:05] <@Marecki> dilfridge: Like pax-utils? :-)
+[21:52:12] <@dilfridge> for example!
+[21:52:46] <@Marecki> The fact we've already got an instance of Gitlab will be relevant in the upcoming flamefe... I mean, ML discussion, then!
+[21:52:52] <@dilfridge> hrhr
+[21:53:23] <+antarus> I think our next steps on that was setting up a terraform repo
+[21:53:27] <+antarus> to manage the groups and permissions
+[21:53:54] <+antarus> ideally then we make that repo RO to devs, with merge power in gitlab, so you can just send PRs to another dev to +1
+[21:54:00] <+antarus> login to the UI is all ldap / SSO
+[21:54:29] <@dilfridge> please make it some 2fa
+[21:54:32] <+antarus> we laso probably need some external identity solution (e.g. allow Github and external gitlab users to auth)
+[21:54:36] <@mgorny> antarus: will users be able to login, fork and make merge requests?
+[21:54:59] <+zlogene> Marecki: I believe arzano (who primarily maintained gitlab) has given up
+[21:55:03] <@dilfridge> antarus: at least for devs, please enforce 2fa ... :(
+[21:55:27] <+antarus> dilfridge: we would need to pursue 2fa in our SSO solution
+[21:55:40] <+antarus> note we don't ahve 2FA for other stuff (mail, bugs, etc.)
+[21:55:54] <@dilfridge> bugs doesnt use ldap
+[21:56:00] <@gyakovlev> dilfridge: there will be that one guy who will refuse to install app on their phone ;-)
+[21:56:10] <+antarus> you can 2fa from the CLI
+[21:56:13] <@dilfridge> that guy can go home
+[21:56:16] <@Marecki> antarus: Could you write all of this (what we have, how to use it, what we want to do, etc.) up on the Wiki? Assuming you haven't yet.
+[21:56:27] <@mgorny> having bugs support SSO would be nice
+[21:56:28] <+antarus> Marecki: sure, but not today
+[21:56:40] <@Marecki> gyakovlev: I mostly use TOTP via a separate Keepass database :-)
+[21:56:43] <@mgorny> i think there might be even an existing extension for that
+[21:56:59] <+antarus> mgorny: we looked and didn't see an openID solutoin that looked maintained ;(
+[21:57:15] <@dilfridge> ok anyway
+[21:57:22] <@dilfridge> we should probably discuss this outside the meeting
+[21:57:51] <@sam_> aye
+[21:57:57] <@Marecki> antarus: We'll probably have to go through keycloak then.
+[21:58:01] <@sam_> not that i think discussing like this is bad in council meetings
+[21:58:05] <@mgorny> antarus: what, infra uses maintained software?
+[21:58:06] <@Marecki> That said, I think it's indeed enough of this for here and now.
+[21:58:07] <@sam_> but i think we've reached a natural end
+[21:58:24] <@dilfridge> lol
+[21:58:32] <@Marecki> We know we've got a Gitlab instance, we'll have it documented. Let's leave the details for later.
+[21:58:42] <@mgorny> ok, any more items for open floor?
+[22:00:02] -*- mgorny bangs the gavel
+[22:00:07] <@mgorny> thank you all
+[22:00:11] <@sam_> thank you
+[22:00:14] <@gyakovlev> thanks for chairing
+[22:00:31] <@Marecki> Cheers!
+[22:00:49] <@dilfridge> thanks!
diff --git a/meeting-logs/20211010.txt.asc b/meeting-logs/20211010.txt.asc
new file mode 100644
index 0000000..315d2ee
--- /dev/null
+++ b/meeting-logs/20211010.txt.asc
@@ -0,0 +1,11 @@
+-----BEGIN PGP SIGNATURE-----
+
+iQEzBAABCAAdFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmFjR74ACgkQY5ra4jKe
+JA4quQgAhQFE0MKDdiSjyjIf8G7BLbv2Yj+OsO5iV0Ppb+1q4k3khN3uO4Mb33uc
+RwFDUPJFoGaEoeQG4tgPGuhPgVkI7r5K1Cld6VbgSJ210ZdOpUlHtwzK3wdoU9iN
+ukmpuKfvZD+BDATlAo65axiSAK/6YRutQyJJrC3Agk6iGPQUJI+sZN3/xA6lLYBQ
+6C+Dx9ccrdFTDn73GFZWUroHXCOcqSF7q8IKHtjApjTyI/D8DnxpuUtxXanvXJFM
+8R28Hb+wCXeRTLEMDRpMx1G/WY2yxjEkoqb6RjW0E7eH9Rv+ZEHqqlpmIunuzuZa
+HKoGsgcFRPA9GDB2FfKOYO5lQfyJag==
+=S1Ce
+-----END PGP SIGNATURE-----