diff options
15 files changed, 1113 insertions, 0 deletions
diff --git a/meeting-logs/20220313-summary.txt b/meeting-logs/20220313-summary.txt
new file mode 100644
index 0000000..8ac75c2
--- /dev/null
+++ b/meeting-logs/20220313-summary.txt
@@ -0,0 +1,49 @@
+Summary of Gentoo council meeting 13 March 2022
+1. Roll call
+2. Server purchases [1]
+3. Deprecating repoman [2]
+4. Open bugs with council involvement
+5. Open floor
+Roll Call
+Present: dilfridge, gyakovlev, mattst88, arthurzam (proxy for marecki), mgorny, sam, ulm
+Server Purchases
+robbat2 proposed purchasing two servers for Gentoo's infrastructure to replace
+some aging systems.
+Motion: Approve purchase of servers outlined in [1]
+Accepted 6-0
+Deprecating Repoman
+mattst88 proposed deprecating repoman [2] and provided a suggested plan for
+doing so. Specifics of the plan discussed and some feedback incorporated.
+Motion: pkgcheck is now considered the primary Gentoo tool for ebuild QA.
+ repoman is no longer considered sufficient. Council condones the
+ deprecation and removal of repoman by the portage team.
+Accepted 6-0
+Open bugs with council involvement
+- Bug 834997 "Missing summaries for 20211114 and 20211212 council meetings"
+ 12:38 <@dilfridge> my fault
+ 12:38 <@dilfridge> soon
+Open floor
+dilfridge mentions that he mailed "council@ pr@ releng@ artwork@, about the
+This work is licensed under the CC BY-SA 4.0 License.
diff --git a/meeting-logs/20220313-summary.txt.asc b/meeting-logs/20220313-summary.txt.asc
new file mode 100644
index 0000000..cdeceae
--- /dev/null
+++ b/meeting-logs/20220313-summary.txt.asc
@@ -0,0 +1,10 @@
+Version: GnuPG v2
diff --git a/meeting-logs/20220313.txt b/meeting-logs/20220313.txt
new file mode 100644
index 0000000..02c6e18
--- /dev/null
+++ b/meeting-logs/20220313.txt
@@ -0,0 +1,285 @@
+12:00 <@ mattst88> | meeting time!
+12:00 <@ mattst88> | Roll Call!
+12:00 * | mattst88 here
+12:00 * | sam_ here
+12:00 * | arthurzam here (proxy for Marecki)
+12:00 <+ robbat2> | not a council member, but here for the line server line item
+12:00 <+ robbat2> | s/line server/server/
+12:00 * | ulm here
+12:00 * | dilfridge here
+12:01 <@ mattst88> | I think we're expecting mgorny to be here in 2 minutes. let's wait for him
+12:01 * | mgorny here
+12:01 <@ mgorny> | sorry
+12:01 <@ mattst88> | not expecting gyakovlev
+12:01 <@ mattst88> | np
+12:01 * | dilfridge hears running water in the background
+12:01 <@ mattst88> | alright, that's everyone we're expecting
+12:02 <@ mattst88> | first order of business: Server purchases
+12:02 <@ mattst88> | robbat2's email is here:
+12:03 <@ mattst88> | are there any concerns?
+12:03 <@ mattst88> | robbat2: anything you want to say?
+12:03 <+ arthurzam> | Marecki asked "why exactly we have ended up on the higher end of pre-approved cost in spite of having gone for the cheaper vendor"
+12:03 <@ sam_> | no concerns at all from me, just praise that we're moving forward, and keen to do so before any prices change or quotes expire! ;)
+12:03 * | mgorny is not a hardware expert, would like to hear what others has to say
+12:03 <@ dilfridge> | not really (and I trust robbat2 and infra to do this properly)
+12:03 <+ robbat2> | as I noted, I had hoped to shave costs by getting a quote that included QLC-based NVME drives; but the cost of NVME seems to have an upward trend due to WD's factory issue
+12:03 <@ dilfridge> | oops
+12:04 <+ robbat2> | this news specifically regarding WD factory:
+12:04 <+ robbat2> | i think that Thinkmate has *not* yet adjusted their pricing upwards, but will do so soon
+12:04 * | Marecki here, belatedly
+12:04 <+ arthurzam> | OK, I see. That is all the questions from me
+12:04 <@ dilfridge> | yeah, that was somewhat coming
+12:04 <+ robbat2> | if we drop to just 2x NVME drives, then we're under the $25k target
+12:05 <+ robbat2> | but leaves me slightly worried about capacity
+12:05 <@ mgorny> | i don't think that's necessary
+12:05 <@ sam_> | i don't see a reason to cut costs there given if anything, i want us to have more VM capacity
+12:05 <+ antarus> | arthurzam: I don't think the goal is really to contain cost
+12:05 * | dilfridge wonders if there's an ETC on NAND chips
+12:05 <@ sam_> | (spinning up things for dev experiments, as well as internal infra re-arrangements)
+12:05 <+ antarus> | provided we think we can get value for our spend
+12:05 <@ Marecki> | In the end, the computer room is the warmest one in the house - so I might as well take part.
+12:06 <@ Marecki> | Had a feeling it might have had something to do with the SSDs, thanks for clarifying robbat2.
+12:06 <+ robbat2> | some vendors are still listing the drives at lower prices
+12:06 <+ robbat2> | but I feel it's old stock they haven't repriced
+12:07 <@ dilfridge> | I fully agree that the price will go up, possibly soon
+12:07 <@ mattst88> | yeah, I think we should pull the trigger
+12:08 <@ sam_> | +1
+12:08 * | arthurzam steps down as Marecki is here
+12:08 <@ dilfridge> | robbat2: so basically the vote is now about 2 x the quotation, right?
+12:08 <+ robbat2> | yes, quantity 2
+12:08 <@ mattst88> | good, thanks for clarifying
+12:09 <@ mattst88> | hearing no concerns, let's vote. Motion: Approve purchase of servers outlined in
+12:09 <@ mattst88> | (or suggestions to reword the motion)
+12:09 <+ robbat2> | and that shipping & taxes aren't included, but i hope for them to be minimal (oregon has no sales tax, but new mexico & north carolina do, and i'm not sure which address we'd be taxed based on)
+12:10 <@ mattst88> | robbat2: typically it's where the server is being shipped, right?
+12:10 <+ robbat2> | *should* be, but i don't follow the intricites of US sales taxes
+12:10 <@ mattst88> | heh, I hadn't considered that this is another good reason to have things hosted at OSUOSL :)
+12:10 <@ dilfridge> | :)
+12:11 <@ dilfridge> | now imagine the german 19% or the finnish 20%
+12:11 <@ mattst88> | Motion: Approve purchase of servers outlined in
+12:11 * | mattst88 yes
+12:11 * | dilfridge yes
+12:11 * | sam_ yes
+12:11 * | Marecki yes
+12:11 * | mgorny yes
+12:11 * | ulm yes
+12:11 <@ mattst88> | motion passes: 6-0
+12:11 <@ mattst88> | \o/
+12:11 <+ robbat2> | thanks!
+12:11 <@ mattst88> | thank you, robbat2!
+12:11 <@ dilfridge> | ++
+12:11 <@ sam_> | thank you for doing the running around (and blueknight, antarus)
+12:11 <@ mattst88> | it'll be exciting to get some additional capacity for VMs :)
+12:11 <@ dilfridge> | oh yes
+12:12 <@ mattst88> | next topic: deprecating repoman
+12:12 <@ mattst88> | I filed a bug outlining my plan: bug 835013
+12:12 < willikins> | "Deprecate repoman"; Gentoo Council, unspecified; CONF; mattst88:council
+12:13 <@ mattst88> | for the record, the details are:
+12:13 <@ mattst88> | The devmanual has already been updated to contain information about pkgdev, in March 2021. See
+12:13 <@ mattst88> | I have opened a devmanual pull request to remove references to repoman that might suggest that it is still an appropriate tool to use. See
+12:13 <@ mattst88> | The next steps once the devmanual change is committed, I think, are
+12:13 <@ mattst88> | - Give the wiki similar treatment as the devmanual, replacing and removing references to repoman that would suggest it is an appropriate tool to use.
+12:13 <@ mattst88> | - Modify repoman to emit a warning informing users of its deprecation
+12:13 <@ mattst88> | - After some period of time, maybe 6 months, give last rites to repoman
+12:13 <@ mattst88> | - Delete repoman from portage.git
+12:13 <@ mattst88> | (and of course adding any features/behaviors we find lacking in pkgdev, et al)
+12:13 <@ mattst88> | discussion, suggestions, objections... go!
+12:13 <@ ulm> | TBH, I still don't see why we should stop devs from using functions like repoman manifest or repoman commit
+12:14 <@ mgorny> | i see hackport depends on repoman
+12:14 <@ ulm> | they should use pkgcheck as qa tool
+12:14 <@ sam_> | i'm slightly on the fence about whether it's worth actually killing repoman itself, but i see the value (and agree with) making gentoo developers use pkgcheck as part of their workflow
+12:14 <@ ulm> | otherwise, repoman is simply a tool like several others
+12:14 <@ sam_> | (it'd be nice to see whether repoman removal actually allows any cleanups of hacks within portage.git or if it's just removing the repoman dir, which isn't so exciting)
+12:14 <@ Marecki> | What sam has just said.
+12:14 <@ ulm> | no reason to delete all traces of it
+12:14 <@ mattst88> | ulm: if you're already using pkgdev for other things, what purpose is there in retaining repoman?
+12:15 <@ ulm> | gentoo is about choice :)
+12:15 <@ Marecki> | ulm: I was going to say exactly the same thing :-P
+12:15 <@ mattst88> | I think I'm right when I claim that as long as repoman continues to exist, people who aren't paying attention will continue to use it and will continue to commit things that pkgcheck would have caught
+12:15 <@ dilfridge> | well, we've got a history of keeping half-dead solutions alive
+12:15 <@ mattst88> | ulm: I think that's really a cop out answer
+12:16 <@ dilfridge> | I'm all for pushing to implement all missing features and wishes
+12:16 <@ ulm> | if the portage team wants to continue maintaining it, we cannot forbid them to do so
+12:16 <@ mgorny> | ulm: but they aren't
+12:16 <@ ulm> | that would be micro-management
+12:16 <@ dilfridge> | the problem right now is, people use repoman, commit stuff where repoman says "it's fine", and then the ci starts screaming at them
+12:16 <@ Marecki> | Seriously though, if the better tool is the recommended (and documented) solution yet there are old-school devs who DO do a good-enough job using repoman, why bother killing it just on principle.
+12:16 <@ mattst88> | yeah, no one is working on repoman anymore
+12:17 <@ mattst88> | Marecki: that's the problem -- they don't go a good-enough job using repoman
+12:17 <@ sam_> | I do fully agree with the idea of deprecating it as a workflow, but then I sort of think that's a QA matter (people still using repoman when we shouldn't be)
+12:17 <@ sam_> | A compromise might be to not impose removal of it from portage.git (as ulm just said ^) but definitely remove it from workflow docs?
+12:17 <@ Marecki> | If it turns out repoman continues to fall behind, it will wither and die on its own. No need for an administrative decision.
+12:17 <@ sam_> | by the way: we still need to update quizzes (bug 792924)
+12:17 <@ ulm> | well, we can say that the new workflow is strongly recommended
+12:17 <@ mattst88> | sam_: ah, thanks. could you leave a comment on the bug to remind me?
+12:17 < sam_> | mattst88; on it
+12:17 <+ antarus> | I wholly expect repoman to be removed from portage.git
+12:17 <+ antarus> | and so the conversation is mostly moot
+12:17 <@ ulm> | but we cannot forbid devs to maintain a package
+12:17 <+ antarus> | unless someone else picks it up
+12:18 <@ mgorny> | fwics last meaningful change in repoman was a year ago
+12:18 <@ sam_> | antarus: right, this is where it sort of descends into hypotheticals, because nobody I know of is actually interested in maintaining repoman
+12:18 <@ sam_> | and I think we could have a different conversation if someone was
+12:18 <@ sam_> | but uh, they ain't
+12:18 <@ sam_> | i think we can just leave that part to the portage team even though we know what's going to happen there
+12:18 <@ mattst88> | ulm: do we have agreement on this point?
+12:18 <@ mattst88> | > - Give the wiki similar treatment as the devmanual, replacing and removing references to repoman that would suggest it is an appropriate tool to use.
+12:18 <@ mgorny> | perhaps the vote should be on making pkgcheck obligatory prior to committing
+12:19 <@ Marecki> | What ulm has just said. And the "but they trip QA by using repoman" argument applies just as well to people who use a fully manual approach.
+12:19 <@ sam_> | (i.e. let's just drop the "remove it from portage.git" from the decision, and just make it advisory)
+12:19 < ulm> | mattst88: sure, update the wiki
+12:19 <@ mattst88> | mgorny: hold on... let's not jump to half measures yet
+12:19 <@ ulm> | GLEP 66 needs an update too
+12:19 <@ Marecki> | Or have I missed a memo and it is now MANDATORY to use Gentoo-specific tooling to commit to the tree?
+12:19 <@ mattst88> | ulm: okay, thanks
+12:19 <@ dilfridge> | it's not
+12:19 <@ mgorny> | Marecki: you're expected not to make QA violations
+12:19 <@ mattst88> | do we also have agreement on this?
+12:19 <@ mattst88> | > - Modify repoman to emit a warning informing users of its deprecation
+12:20 <@ ulm> | Marecki: I think you can use any tooling you like, but if you break things, you'll have to keep the pieces :)
+12:20 <@ Marecki> | mgorny: That's what I thought.
+12:20 <@ mattst88> | Marecki: right, there's not a requirement. it's just that people have muscle memory to use repoman and it's bad
+12:20 < ulm> | mattst88: that's just noise
+12:20 <@ ulm> | I'm against having the tool emit a warning
+12:20 <@ mgorny> | well, i somewhat can agree that it feels weird about council telling portage team to lastrite repoman
+12:20 <@ mattst88> | ulm: printing a deprecation warning is just noise?
+12:20 <@ mgorny> | ...but then, i'm on portage team after all
+12:20 <@ ulm> | just announce it widely
+12:20 <@ mattst88> | as tamiko showed, almost everyone has stopped using repoman
+12:20 <@ sam_> | i think maybe we're discussing a few points at once (which i'm guilty of making worse)
+12:21 <@ mgorny> | and i think we as portage team can just do it
+12:21 <@ mattst88> | so we're on the trailing edge of people still using it
+12:21 < sam_> | mattst88: ok, so which point are we talking about right now?
+12:21 <@ ulm> | sure, it's up to the portage team
+12:21 <@ mgorny> | i'm pretty sure there are some devs who will say "repoman didn't complain, so why are you bothering me?"
+12:21 <@ mattst88> | ulm: kumba specifically requested that it print a deprecation notice; as we've seen, people don't read documentation, nor the mailing list, nor blogs, etc
+12:22 <@ mattst88> | sam_: - Modify repoman to emit a warning informing users of its deprecation
+12:22 <+ antarus> | I'd rather go with pmasking it
+12:22 <+ antarus> | (assuming that happens)
+12:22 <@ mattst88> | sure, I'm totally okay with that. I'm just trying to find consensus
+12:22 <@ dilfridge> | that, of course, works too
+12:22 <@ mattst88> | I'm happy to skip that step if that's what others want to do
+12:23 < mgorny> | mattst88: i really think a formal motion of expecting people to use pkgcheck should be good enough
+12:23 <@ mgorny> | worded in some nice way
+12:23 <@ mattst88> | mgorny: and then we can leave it to the portage team to give last rites and remove repoman from the codebase?
+12:23 <@ mgorny> | yep
+12:23 <@ mattst88> | (if so, works for me)
+12:23 <@ ulm> | ok with pmasking, but maybe should be more than one month transition perios?
+12:23 <@ Marecki> | I'm with antarus here. pmasking - message appears once, people either switch to pkgcheck or unmask it. Deprecation warning - message appears every time repoman is run.
+12:23 <@ mattst88> | ulm: sure, sounds good
+12:23 <@ mgorny> | "developers are expected to ensure that their work meets QA requirements as indicated by pkgcheck prior to committing"
+12:23 <@ ulm> | *period
+12:24 <@ ulm> | mgorny: that's the core of what we want, yes
+12:24 <@ mattst88> | mgorny: if you feel confident that we can deprecate and remove repoman using only the portage team's authority, then that works for me
+12:24 <@ mgorny> | maybe it could be worded even better
+12:24 <@ sam_> | yes, agreed with mgorny
+12:24 <@ mattst88> | it seemed to me like there was only one person in the discussion who was having a fit about the idea of not having repoman
+12:25 <@ mattst88> | that is, generally broad consensus
+12:25 <@ ulm> | well, we had a few meetings at CLT this weekend, and my impression is that most people know only the repoman workflow
+12:25 <@ mgorny> | alternatively: "pkgcheck is now considered the primary Gentoo tool for ebuild QA. repoman is no longer considered sufficient"
+12:25 <@ ulm> | several developers included
+12:26 <@ mattst88> | ulm: if we approve something like mgorny's motion, are you going to continue to be against removing references to repoman from the devmanual?
+12:26 <@ mgorny> | ulm: that's what i'd have expected. that's why i believe we need to make an official push to change people's workflows
+12:27 < ulm> | mattst88: I was opposed against removing of exactly one reference, namely the one about commit tags
+12:27 <@ ulm> | rest is fine IMO
+12:27 <@ mattst88> | ulm: oh. I took your message in ("I don't see a compelling reason to remove all mentions of the latter.") to indicate a more general disagreement
+12:27 <@ mattst88> | so I'm glad to hear I was mistaken
+12:27 <@ mgorny> | i don't mind "deprecating" it as a Council decision but I think that should be a deprecation of the workflow rather than the package
+12:28 < ulm> | mattst88: there's very little documentation of it in the devmanual, to start with :)
+12:28 <+ antarus> | clearly we need annual mandatory developer training ;p
+12:28 <@ mattst88> | mgorny: could you explain why you think that?
+12:28 <@ sam_> | for me it's a principle thing but shouldn't make a difference in practice
+12:28 <@ mattst88> | e.g. what is wrong with council approving the deprecation of repoman?
+12:28 <@ sam_> | i.e. council shouldn't be saying we must remove the code
+12:28 <@ sam_> | but portage team will do this as a result of the deprecation
+12:28 <@ mattst88> | oh, yes
+12:29 < mgorny> | mattst88: what was said before, it feels like stepping over portage team without giving them a chance
+12:29 <@ ulm> | we deprecate the workflow => package won't be essential => portage team can deprecate it
+12:29 <@ mattst88> | I'm not asking council to force the removal of repoman, just to *approve* it
+12:29 <@ sam_> | ok, cool
+12:29 <@ ulm> | with some transition time please :)
+12:29 <@ mattst88> | okay, sounds like I just was unclear -- problem solved :)
+12:29 <@ mgorny> | ah, i suppose that's ok, we just need to word it carefully
+12:29 <@ mattst88> | yeah
+12:30 <@ mgorny> | our goal is for primarily for devs to start using pkgcheck
+12:30 <@ mgorny> | as portage team, it would be nice if they stopped using repoman at all, so we could remove it
+12:30 <@ mattst88> | do we feel good about 't"
+12:30 <@ mattst88> | ugh, clipboard
+12:30 <@ sam_> | (I have a minor point to throw in which is just an advisory thing: I think we should try to band together and add any relevant stuff in pkgcheck (which is already in the motion) that it turns out are missing but including triaging the old repoman bugs to see if there's some relevant stuff there)
+12:31 <@ sam_> | I also think we should probably have a fork or mirror of pkgcore/* on our infra
+12:31 <@ sam_> | that's minor stuff and easily done though
+12:32 <@ mattst88> | how about this?
+12:32 <@ mattst88> | pkgcheck is now considered the primary Gentoo tool for ebuild QA. repoman is no longer considered sufficient. Council approves (but does not mandate) the deprecation and removal of repoman from ::gentoo and from portage.git.
+12:32 <@ ulm> | sam_: good point, if it's going to be our primary qa tool then it should be hosted on infra
+12:32 <@ dilfridge> | "Council recommends and encourages the deprecation and removal of repoman from ::gentoo and from portage.git."
+12:33 <@ mattst88> | that works for me
+12:33 <@ sam_> | I think we can tack this on to the plan and we'll add it as a blocker bug to the migration bug mattst88 filed
+12:33 <@ ulm> | dilfridge: too strong
+12:33 <@ mgorny> | what's the difference between "recommends" and "encourages"?
+12:33 <@ dilfridge> | none I think
+12:33 <+ antarus> | mgorny: are you pkgcheck / pkgcore upstream now?
+12:33 <@ mattst88> | ulm: concretely... how?
+12:33 <@ mgorny> | maybe just "Council does not see any obstacles towards deprecating and removing it"?
+12:33 <@ ulm> | "council condones deprecation and removal of repoman by the portage team"
+12:34 <@ mgorny> | antarus: yes but i'd welcome more people
+12:34 <@ dilfridge> | that works
+12:34 <+ antarus> | mgorny: I guess I meant in terms of mirroring it on gentoo infra
+12:34 <@ mattst88> | ulm: that's basically what I said :)
+12:34 <+ antarus> | I think most of our mirrors are the other way?
+12:34 <@ mattst88> | condones == approves
+12:34 <+ antarus> | but we can follow up
+12:34 < ulm> | mattst88: yeah, your wording wfm
+12:34 <@ ulm> | dilfridge's doesn't
+12:35 <@ dilfridge> | whatever, not so important to me
+12:35 <@ sam_> | fine with either, prefer dilfridge's but not a blocker
+12:35 <@ mgorny> | antarus: well, not sure how radhermit would feel about it but i really don't care whether it's hosted on gh or git.g.o
+12:35 <@ mattst88> | Okay, let's do this then. Motion: Council condones deprecation and removal of repoman by the portage team
+12:35 <@ ulm> | mgorny: gitlab :)
+12:35 <@ mgorny> | after all, it wasn't supposed to be part of core Gentoo
+12:35 <@ mattst88> | any last suggestions to the wording/
+12:35 <@ mattst88> | ?
+12:36 < mgorny> | mattst88: without the first part?
+12:36 <@ mgorny> | (i.e. the one about pkgcheck)
+12:36 <@ dilfridge> | "pkgcheck is now considered the primary Gentoo tool for ebuild QA. repoman is no longer considered sufficient. "
+12:36 < ulm> | mattst88: yes, what about the first part
+12:36 <@ mattst88> | Motion: pkgcheck is now considered the primary Gentoo tool for ebuild QA. repoman is no longer considered sufficient. Council condones the deprecation and removal of repoman by the portage team.
+12:36 * | dilfridge yes
+12:36 * | mgorny yes
+12:37 * | mattst88 yes
+12:37 * | Marecki yes
+12:37 * | sam_ yes (but let's do the mirroring bits)
+12:37 <@ mattst88> | (cool, I wasn't sure if we had agreement on the first bits of the text :)
+12:37 * | ulm yes
+12:37 <@ mattst88> | Motion passes 6-0 \o/
+12:37 <@ mgorny> | let's add a footnote about mirroring to the meeting summary
+12:37 <@ mgorny> | s/foot/
+12:37 <@ mattst88> | sam_: agreed. I'd love it if we could get gitlab going sooner rather than... never
+12:37 <@ mattst88> | mgorny: will do
+12:38 <@ sam_> | yes, me too
+12:38 <@ mattst88> | okay, I think those were really the only two topics I knew about
+12:38 <@ mattst88> | we don't have any bugs assigned to us other than the repoman one
+12:38 <@ mattst88> | open floor time?
+12:38 <@ ulm> | missing summaries bug?
+12:38 <@ dilfridge> | right
+12:38 <@ mattst88> | assigned to dilfridge :)
+12:38 <@ dilfridge> | my fault
+12:38 <@ dilfridge> | soon
+12:39 <@ ulm> | bug 834997 (so it's in the log)
+12:39 < willikins> | "Missing summaries for 20211114 and 20211212 council meetings"; Gentoo Council, unspecified; CONF; ulm:dilfridge
+12:39 <@ mattst88> | thanks
+12:40 <@ mattst88> | oh, just so we've got it on record, I'm not planning to mark gyakovlev as a slacker for missing this meeting -- I think he's got a pretty good reason for not being around
+12:40 <@ mattst88> | any objections?
+12:40 <@ mattst88> | feel free to respond in #-private if you wish
+12:40 <@ dilfridge> | sgtm
+12:40 <@ mattst88> | anyway, open floor. any topics?
+12:41 <@ dilfridge> | minor mention
+12:41 <@ sam_> | nothing from me I think
+12:41 <@ dilfridge> | I sent a mail to council@ pr@ releng@ artwork@, about the livegui
+12:42 <@ dilfridge> | would be great to get some feedback there what you think of that (not yet public) plan
+12:42 <@ mattst88> | neat, thank you!
+12:44 <@ mattst88> | okay, hearing no topics for open floor, I think we can consider this meeting adjourned
+12:44 <@ mattst88> | thank you all! \o/
+12:44 <@ sam_> | thank you!
+12:44 <@ mgorny> | thanks
+12:44 <@ dilfridge> | thanks everyone
+12:44 <@ ulm> | thanks
diff --git a/meeting-logs/20220313.txt.asc b/meeting-logs/20220313.txt.asc
new file mode 100644
index 0000000..3a7a262
--- /dev/null
+++ b/meeting-logs/20220313.txt.asc
@@ -0,0 +1,10 @@
+Version: GnuPG v2
diff --git a/meeting-logs/20220410-summary.txt b/meeting-logs/20220410-summary.txt
new file mode 100644
index 0000000..1223f3d
--- /dev/null
+++ b/meeting-logs/20220410-summary.txt
@@ -0,0 +1,73 @@
+Summary of Gentoo council meeting 2022-04-10
+1. Roll call
+2. Utilizing GH functionality that Gentoo infra does not provide [1][2]
+3. Open bugs with Council participation
+4. Open floor
+Roll call
+Present: dilfridge, gyakovlev, mattst88, marecki, mgorny, sam, ulm
+Utilizing GH functionality that Gentoo infra does not provide [1]
+Resolution: not actionable, more information needed.
+It was noted that currently GH CI functionality can already be used by adding
+.github directory with proper yaml configuration, some gentoo projects already
+use that.
+Also tags made on gentoo infra git are already mirrored to github.
+As no more discussion happened on this topic and it's not clear which projects
+proposition author wants to use that on, council could not approve or reject
+this motion.
+antarus mentioned that gitlab instance is in the works too, and it will be
+much more preferred once implemented.
+Open bugs with council participation [2]
+- Bug 786105 - access to manage projects on GH
+ Discussion happened above on separate agenda item.
+- Bug 176186 - "Gentoo projects file hosting"
+ robbat2 has reached out to the team who manage their
+ kup (dev-util/kup) instance and received their Perl code to
+ handle gluing it to gitolite.
+ No action required from council.
+- Bug 835152 - "Mirror pkgcore/* repos from github"
+ Progressing, council agreed to continue monitoring the bug.
+- Bug 834997 - "Missing summaries for 20211114 and 20211212 council meetings"
+ dilfridge said wip.
+Open floor
+distfile hosting problem
+ sam is looking into kup[4]
+ progress is reported on bug
diff --git a/meeting-logs/20220410-summary.txt.asc b/meeting-logs/20220410-summary.txt.asc
new file mode 100644
index 0000000..dee7787
--- /dev/null
+++ b/meeting-logs/20220410-summary.txt.asc
@@ -0,0 +1,17 @@
diff --git a/meeting-logs/20220410.txt b/meeting-logs/20220410.txt
new file mode 100644
index 0000000..71f7080
--- /dev/null
+++ b/meeting-logs/20220410.txt
@@ -0,0 +1,224 @@
+[12:00:02 pm] <@gyakovlev> !proj council
+[12:00:03 pm] <willikins> ( dilfridge, gyakovlev, marecki, mattst88, mgorny, sam, ulm
+[12:00:08 pm] <@gyakovlev> meeting time!
+[12:00:23 pm] <@gyakovlev> agenda for today:
+[12:00:33 pm] <@gyakovlev> 1) Roll call
+[12:00:37 pm] -*- mattst88 here
+[12:00:37 pm] -*- gyakovlev here
+[12:00:41 pm] -*- sam_ here
+[12:00:43 pm] -*- ulm here
+[12:00:45 pm] -*- mgorny here
+[12:01:27 pm] -*- Marecki here
+[12:01:58 pm] <@gyakovlev> dilfridge: ping
+[12:02:17 pm] <@dilfridge> here
+[12:02:27 pm] <@gyakovlev> nice, everyone is here. moving on.
+[12:02:35 pm] <@gyakovlev> 2) Utilizing GH functionality that Gentoo infra does not provide
+[12:03:08 pm] <@gyakovlev> here has been a discussion on #g-project
+[12:03:19 pm] <@dilfridge> (or, "vapier wants an extrawurst")
+[12:04:02 pm] <@mattst88> I don't understand the requirement to be hosted on gentoo infra, tbh
+[12:04:13 pm] <@mattst88> e.g. why is it okay for OpenRC to be hosted on Github?
+[12:04:52 pm] <@dilfridge> shrug, because we can run away to Gretna Green with systemd at any moment?
+[12:05:06 pm] <@dilfridge> dunno either
+[12:05:19 pm] <@sam_> OpenRC isn't a gentoo project
+[12:05:24 pm] <@mattst88> and what horrible thing would happen if we started using Github releases for sandbox? (sandbox is an example because it's something that vapier releases)
+[12:05:30 pm] <@mgorny> mattst88: we've abandoned openrc fwir
+[12:05:48 pm] <@mattst88> sam_: I think that's a lazy argument -- it certainly started as a Gentoo project
+[12:05:49 pm] <@sam_> openrc is very much not a gentoo project, and william is quite clear on that, _but_ there is a valid point about "gentoo depending on things we don't host ourselves"
+[12:05:55 pm] <@sam_> yes, but it's beside the point
+[12:06:01 pm] <@sam_> it's not relevant to comparison with sandbox/pax-utils
+[12:06:09 pm] <@sam_> william is very clear it's disconnected with gentoo and they host bugs on github too
+[12:07:14 pm] <@gyakovlev> we already talked about this one before, I still don't get what exactly is needed? =)
+[12:07:14 pm] <@gyakovlev> anyone can commit .github directory with some yaml voodoo for CI.
+[12:07:14 pm] <@gyakovlev> I'm against on relying on GH tarball hosting for pure gentoo projects though.
+[12:07:14 pm] <@gyakovlev> it's ok to grab a tag, and mark it as release on github - sure.
+[12:07:14 pm] <@gyakovlev> but primary SRC_URI should be gitweb tarball imo.
+[12:07:14 pm] <@gyakovlev> mirror system syncs tags already.
+[12:07:42 pm] <@mattst88> I wish vapier had replied to me with info on what projects he would like to change
+[12:08:30 pm] <@mattst88> gyakovlev: but why? in what case can you foresee a problem relying on a github tarball for SRC_URI?
+[12:08:31 pm] <@Marecki> With GitHub, I would be VERY careful about vendor lock-in. Much easier to migrate to GH than off it.
+[12:09:05 pm] <@Marecki> Unlike Gitlab, which you can basically take with you.
+[12:09:12 pm] <@mgorny> my main concern is long-term reliability
+[12:09:21 pm] <@mattst88> I mean, anything can happen. we've had plenty of source sites shut down, like
+[12:09:30 pm] <@mgorny> we've been hit by this before
+[12:09:32 pm] <@dilfridge> mgorny: that is a two-edged sword
+[12:09:34 pm] <@sam_> free CI is nice and I don't mind that, I just don't really get the benefit or need to make official releases on GH or anything
+[12:09:51 pm] <@gyakovlev> mattst88: not a problem per-se, just feels wrong long term.
+[12:09:51 pm] <@gyakovlev> what's the difference specifying infra SRC_URI instead of github?
+[12:09:51 pm] <@mgorny> if we host stuff on gentoo infra, we at least can have backups that we can acces
+[12:10:05 pm] <@dilfridge> but yes, what nobody has mentioned yet is, there is a reason why gentoo github was essentially locked down
+[12:10:06 pm] <@mattst88> sam_: agreed. maybe we just table this today and let more discussion happen
+[12:10:13 pm] <@gyakovlev> there's 0 difference if you specify tagged tarball
+[12:10:23 pm] <@gyakovlev> both systems support tags
+[12:10:25 pm] <@dilfridge> and that reason is still valid
+[12:10:36 pm] <@mgorny> i don't have problem with people running CI on github or filing pull requests (though i would prefer our own hosted system for that)
+[12:10:44 pm] <@mgorny> because if we lose that, it's not critical
+[12:10:45 pm] <@mattst88> (FWIW, if was totally ready, I'd just say use it)
+[12:10:47 pm] <@sam_> the thing about CI on github + PRs is that it's additive; we're not relying on it
+[12:10:49 pm] <@sam_> yes, exactly
+[12:11:00 pm] <@mgorny> but i don't want to be recovering release tarballs from mirrors because backing github up is hard
+[12:11:15 pm] <@sam_> mattst88: yeah, the person driving the discussion needs to input more I think; I'm not sure any of us really get what's desired here (or why, anyway)
+[12:11:18 pm] <@sam_> feels a bit X-Y problemish
+[12:11:28 pm] <@dilfridge> so, how about we just tell everyone who wants to use additional github features, "focus your energy on getting our gitlab running"?
+[12:11:29 pm] <@mattst88> and I kind of share vapier's skepticism of our infra. remember the forums migration?
+[12:12:06 pm] <@dilfridge> infra_2
+[12:12:39 pm] <@mattst88> dilfridge: sounds good to me.
+[12:13:11 pm] <@sam_> what i do accept is the frustration and issue with e.g. devs retiring and tarballs they hosted going away, for projects we host
+[12:13:21 pm] <@ulm> another aspect is that any discussion happening in github pull requests and issues may be lost at some time, and we don't have control
+[12:13:24 pm] <@sam_> and I think even an imperfect solution to bug 176186 would be great
+[12:13:25 pm] <willikins> sam_: "Gentoo projects file hosting"; Gentoo Infrastructure, Other; IN_P; dsd:infra-bugs
+[12:13:36 pm] <@mattst88> sam_: that's really freaking ridiculous, tbh.
+[12:13:47 pm] <@mgorny> yes, i still wish we had something like 90s ftp server
+[12:13:56 pm] <@sam_> mattst88: it looks awful too because pax-utils is used by external projects, and then when slyfox retires, 404!
+[12:14:04 pm] <@mgorny> but infra doesn't bother with such non-enterprise solutions
+[12:14:15 pm] <@sam_> or they have to know that they have to try both vapier's and my devspace or something
+[12:14:30 pm] <@sam_> yes, an FTP server would be better than nothing
+[12:14:38 pm] <@sam_> i'm very close to just trying out kup myself and seeing what happens
+[12:14:47 pm] <@dilfridge> anything would be better than current state
+[12:15:04 pm] <@dilfridge> public git-lfs instance
+[12:15:29 pm] <@mattst88> alright, so we're okay kicking this back to the gentoo-project@ thread for more discussion?
+[12:15:38 pm] <@dilfridge> no we kill it outright
+[12:15:39 pm] <@sam_> i hate that i actually like the ftp idea
+[12:15:50 pm] <@sam_> it shows the situation we're in is poor
+[12:15:57 pm] <@Marecki> I feel tempted to suggest xrootd, it's a thing from HEP which aside from its native protocol supports WebDAV. With authentication, TLS, the whole works.
+[12:16:11 pm] <@dilfridge> subversion
+[12:16:22 pm] <@dilfridge> does webdav too
+[12:17:28 pm] -*- mgorny checks if he accidentally ended up on overcomplex idea contest
+[12:18:54 pm] <@Marecki> mgorny: My main point here is that one really doesn't have to fall back to FTP nowadays. A WebDAV server isn't THAT hard to deploy any more.
+[12:19:19 pm] <@mgorny> i wasn't serious about using FTP protocol ;-)
+[12:19:20 pm] <@mattst88> Marecki: I think he was just saying that even a plain old FTP would be better than what we have now
+[12:19:25 pm] <@mgorny> just a shared dir available over SSH
+[12:19:58 pm] <@dilfridge> or a solution for ~/public_html that is backed up
+[12:20:05 pm] <@dilfridge> and archived
+[12:20:13 pm] <@mgorny> dilfridge: we need to move it outta woodpecker
+[12:20:14 pm] <@gyakovlev> and without username in the URI
+[12:20:34 pm] <@mgorny> i also need some file hosting for bin kernels
+[12:20:38 pm] <@mgorny> but github won't work there
+[12:20:54 pm] <@dilfridge> a kernel bin, so to say :P
+[12:21:22 pm] <@mgorny> i'm pretty sure they wouldn't be happy about a weekly dose of ~1 GiB
+[12:21:32 pm] <@sam_> right
+[12:21:35 pm] <@mattst88> (do we have more topics?)
+[12:21:49 pm] <@sam_> i think we probably need to ask infra what the blocker is on that bug, and if we can get a something > nothing solution, even if it's a PoC to get feedback
+[12:21:55 pm] <@gyakovlev> mattst88: just generic ones, like bugs and open floor
+[12:21:55 pm] <@sam_> and i think we also need to ask vapier for more information
+[12:22:29 pm] <@Marecki> What, again? And hope we'll actually get it this time?
+[12:22:36 pm] <@dilfridge> that is pointless
+[12:22:47 pm] <@gyakovlev> so kicking it back to ML? does not look actionable right now, but has some valid points without solutions.
+[12:22:47 pm] <@sam_> i'm fine with moving on too given we've done it before
+[12:23:08 pm] <@sam_> i think the hosting is a real thing we should figure out, but that's not really related to approving doing more on github
+[12:23:20 pm] <@sam_> so yes i'm fine with just saying no given this is the second time we've tried
+[12:23:26 pm] *** Mode #gentoo-council +v xgqt by ChanServ
+[12:23:46 pm] <@mgorny> did vapier finally say which projects he wants to move to github?
+[12:23:53 pm] <@sam_> honestly, it borderline feels like a discussion about nothing
+[12:23:56 pm] <@sam_> there's insufficient substance
+[12:24:07 pm] <@mgorny> i don't really mind people hosting one-man projects on github (like i do)
+[12:24:21 pm] <@mgorny> but if we have a major project that's coop between many devs, it should stay within gentoo infra
+[12:24:34 pm] <@dilfridge> the point that vapier tries to make is very unspecific, my guess would be he objects that github is locked down so much
+[12:24:37 pm] <@mgorny> with bugs on bugzilla and not github issues
+[12:24:47 pm] <@dilfridge> but there's a reason for that, and it's very valid
+[12:24:54 pm] <@mattst88> yeah, agreed
+[12:25:12 pm] <@mgorny> next thing you know, people can't join project X because they refuse to use github
+[12:25:24 pm] <@dilfridge> mgorny: yes
+[12:27:56 pm] <@gyakovlev> ok, motion ( though I still feel it's not actionable in current state.
+[12:27:56 pm] <@gyakovlev> Utilizing GH functionality that Gentoo infra does not provide
+[12:27:56 pm] <@gyakovlev> 1) yes
+[12:27:56 pm] <@gyakovlev> 2) no
+[12:28:23 pm] <@mgorny> i think that's too generic
+[12:28:36 pm] <@gyakovlev> that's the problem with the whole thing
+[12:28:43 pm] <@gyakovlev> it's not actionable as is
+[12:28:49 pm] <@mgorny> if we're to allow anything, we need to make it clear what things can be used and under what circumstances
+[12:28:50 pm] <@ulm> it's not really actionable at this point
+[12:28:52 pm] <@gyakovlev> and I don't think we can make it one.
+[12:29:01 pm] <@gyakovlev> with current info
+[12:29:25 pm] <@sam_> all I'd like is to not have to talk about this again in 3 months if no more information is given, like last time
+[12:29:36 pm] <@mattst88> ++
+[12:29:39 pm] <@sam_> i don't think we're any clearer than when we asked for more info last time
+[12:30:33 pm] <@gyakovlev> ok kicking it back for more details and clear actionable definition.
+[12:30:33 pm] <@gyakovlev> if it's 3 month away - another council will have to deal with it ahahah.
+[12:31:14 pm] <@mgorny> yeah, exact details what is required and with example projects that will use it and how
+[12:31:30 pm] <@gyakovlev> eveyone ok with moving on? say if no, otherwise I'll me moving to next agenda item in a min.
+[12:31:41 pm] <@sam_> yes
+[12:31:56 pm] <@ulm> move on please
+[12:32:03 pm] <@gyakovlev> 3) Open bugs with Council participation
+[12:32:03 pm] <@gyakovlev>
+[12:32:06 pm] <@gyakovlev> bug 786105
+[12:32:07 pm] <willikins> gyakovlev: "access to manage projects on GH"; Gentoo Infrastructure, GitHub; CONF; vapier:github
+[12:32:10 pm] <@sam_> hahahaha
+[12:32:11 pm] <@gyakovlev> this is what we just discussed
+[12:32:12 pm] <@sam_> no!!
+[12:32:20 pm] <@mattst88> lol
+[12:32:22 pm] <@gyakovlev> next one =)
+[12:32:23 pm] <@gyakovlev> bug 835152
+[12:32:24 pm] <willikins> gyakovlev: "Mirror pkgcore/* repos from github"; Gentoo Infrastructure, Git; CONF; sam:infra-bugs
+[12:32:47 pm] <@gyakovlev> sam_: any updates on it? seems related =)
+[12:32:53 pm] <@mattst88> I think we're working on that in the context of
+[12:32:55 pm] <@mgorny> i think we've pretty much agreed we can move the primary repos to gentoo infra
+[12:33:03 pm] <@sam_> arthurzam: ^^
+[12:33:08 pm] <@mgorny> but tbh i don't know what to do about existing bugs
+[12:33:12 pm] <@mgorny> on github issues
+[12:33:31 pm] <@mattst88> gitlab can import all of that from a github repo
+[12:33:37 pm] <@sam_> oh nice
+[12:33:54 pm] <@mgorny> hmm, though i think we're currently relying on repo access in github actions to make releases
+[12:34:42 pm] <@gyakovlev> please just update bug and we can move on , looks like things are happening
+[12:34:43 pm] <@mattst88> dunno. I don't know what council has to contribute in that regard though
+[12:34:52 pm] <@sam_> ack
+[12:34:54 pm] <@gyakovlev> just monitoring?
+[12:34:57 pm] <@gyakovlev> anyway,
+[12:34:58 pm] <@mattst88> yes
+[12:34:59 pm] <@gyakovlev> bug 834997
+[12:35:00 pm] <willikins> gyakovlev: "Missing summaries for 20211114 and 20211212 council meetings"; Gentoo Council, unspecified; CONF; ulm:dilfridge
+[12:35:08 pm] <@sam_> it's important for us to monitor but not actionable
+[12:35:26 pm] <@gyakovlev> dilfridge: looks like your meetings? sorry if I'm worng, memory is hazy on meeting hosts
+[12:35:31 pm] <@dilfridge> sorry
+[12:35:32 pm] <@dilfridge> wip
+[12:35:51 pm] <@gyakovlev> that's it for council bugs.
+[12:36:01 pm] <@gyakovlev> 4) Open floor
+[12:36:40 pm] -*- gyakovlev will wait 4 minutes until 19:40 UTC
+[12:36:54 pm] <@sam_> only thing from me is I think we should ask infra to look into the projects hosting via kup, even if it's a PoC
+[12:36:55 pm] <@sam_> [20:21:48] <@sam_> i think we probably need to ask infra what the blocker is on that bug, and if we can get a something > nothing solution, even if it's a PoC to get feedback
+[12:37:04 pm] *** Mode #gentoo-council +v antarus by ChanServ
+[12:37:21 pm] <@mgorny> let's put in the summary that sam_ will look into distfile hosting problem
+[12:37:26 pm] <@sam_> sure
+[12:37:30 pm] <@sam_> (already looking into kup bits)
+[12:37:41 pm] <@gyakovlev> I think what you've mentioned before is a good action plan?
+[12:37:41 pm] <@gyakovlev> investigate first and take it to infra if it looks promising.
+[12:37:47 pm] <@sam_> sounds good
+[12:37:52 pm] <@dilfridge> looks more complicated than ftp
+[12:37:52 pm] <@gyakovlev> nice
+[12:38:02 pm] <@mgorny> mgorny will continue his uneven fight with python
+[12:38:07 pm] <@sam_> dilfridge: i have some gitolite experience which helps a bit
+[12:38:09 pm] <@sam_> we'll see
+[12:38:10 pm] <@mgorny> in the world that has moved on
+[12:38:38 pm] <@dilfridge> perl 5.36 will be out soon
+[12:38:43 pm] <@gyakovlev> ftp seems completely dead tbh
+[12:38:56 pm] <@gyakovlev> even browsers dropped support for it =)
+[12:39:04 pm] <@sam_> ftp would actually work with https serving the directories
+[12:39:07 pm] <@dilfridge> hey, at least then it's secure
+[12:39:07 pm] <@sam_> but eh
+[12:39:08 pm] <@ulm> what's wrong with it for hosting distfiles?
+[12:39:22 pm] <@ulm> that are validated after download
+[12:39:24 pm] <@mgorny> well, i'd be perfectly happy with being able to scp into some https server's shared directory
+[12:39:48 pm] <@gyakovlev> I think kup does that + verification + signatures
+[12:39:53 pm] <@gyakovlev> sam_: ^ ?
+[12:39:56 pm] <@sam_> yes
+[12:40:30 pm] <@gyakovlev> ok any other items?
+[12:40:33 pm] <@ulm> we could use gopher :)
+[12:40:52 pm] <@mgorny> what about cleanup of old distfiles?
+[12:41:16 pm] <@mgorny> kernels would some way of removing old distfiles
+[12:41:18 pm] <@ulm> mgorny: just don't?
+[12:41:41 pm] <@mgorny> ulm: well, not sure if infra is willing to sacrifice that much disk space
+[12:41:59 pm] <@ulm> most upstream projects keep their distfiles forever
+[12:42:23 pm] <@mgorny> one kernel version is ~250M of binpackages
+[12:42:35 pm] <@mgorny> right now we build 4 versions per each release set
+[12:42:39 pm] <@dilfridge> one libreoffice-bin is 10Gbyte
+[12:42:41 pm] <@mgorny> i.e. 1G per release set
+[12:42:46 pm] <@ulm> that's huge of course
+[12:42:58 pm] <@mgorny> lately it's gotten rarer but it used to be twice a week
+[12:43:28 pm] <@gyakovlev> so we are looking at least 50G per year? more like 70?
+[12:43:29 pm] <@mgorny> that's roughly ~100G per year
+[12:44:08 pm] <@dilfridge> well, I just bought an 18T disk, it's right here on my desk... something like 300€
+[12:44:13 pm] <@mgorny> i mean, i suppose we can buy a few TiB every few years
+[12:44:28 pm] <@mgorny> but i'm not really convinced that there's much value in keeping binpkgs of vulnerable kernels
+[12:44:45 pm] <@mgorny> especially that they can be rebuilt from source if someone really cares
+[12:44:50 pm] <@gyakovlev> anyway, this can be discussed later in the scope of distfile hosting.
+[12:45:03 pm] -*- gyakovlev bangs the gong.
+[12:45:13 pm] <@gyakovlev> meeting colsed, thanks for participation!
diff --git a/meeting-logs/20220410.txt.asc b/meeting-logs/20220410.txt.asc
new file mode 100644
index 0000000..01045e2
--- /dev/null
+++ b/meeting-logs/20220410.txt.asc
@@ -0,0 +1,17 @@
diff --git a/meeting-logs/20220508-summary.txt b/meeting-logs/20220508-summary.txt
new file mode 100644
index 0000000..ff1e35d
--- /dev/null
+++ b/meeting-logs/20220508-summary.txt
@@ -0,0 +1,79 @@
+Summary of Gentoo council meeting 2022-05-08
+1. Roll call
+2. Open bugs with council participation [1]
+3. Signoff behaviour of the pkgdev tooling (proposed change is to
+disable signoff by default, but allow opt in via configuration) [2]
+4. Open floor
+Roll call
+Present: dilfridge, gyakovlev, mattst88, marecki, mgorny, sam, ulm
+Open bugs with council participation
+- Bug 835165 - "Reimbursement for SSD purchase for Infra 3/14/2022"
+ sam explained the background to the bug as a recap for the purposes
+ of the meeting log (an SSD had failed unexpectedly and a replacement
+ was needed urgently; the official Foundation funds could not be used
+ directly because of an erroneous card block triggered by a purchase
+ attempt for this item). These details are reflected in the bug.
+ All council members voted Yes on the bug - 7 yes, 0 no, 0 abstentions.
+- Bug 176186 - "Gentoo projects file hosting"
+ robbat2 has reached out to the team who manage their
+ kup (dev-util/kup) instance and received their Perl code to
+ handle gluing it to gitolite.
+ No action required from council.
+- Bug 835152 - "Mirror pkgcore/* repos from github"
+ Progress is being made by infra on gitlab work, so no discussion was
+ had.
+- Bug 786105 - "access to manage projects on GH"
+ Given no further discussion has occurred on the ML, and no reply from
+ the original poster, council agreed to be un-CC'd from the bug.
+- Bug 834997 - "Missing summaries for 20211114 and 20211212 council meetings"
+ dilfridge said he'd handle the missing summaries soon.
+Signoff behaviour of the pkgdev tooling
+Arthur Zamarin (arthurzam@) requested that the council approve
+of a change in pkgdev's behavior to default to no-signoff (i.e. sign-off
+becomes opt-in).
+It was raised because it may impact developer experience.
+- This was approved by acclamation with no objections.
+Open floor
+- Roy Bamford (NeddySeagoon) raised the topic of the next election cycle
+ and asked Council whether it had any preferences for the next date, within
+ the window allowed. He later followed up on the mailing list [3]
+ Council didn't express any preference.
diff --git a/meeting-logs/20220508-summary.txt.asc b/meeting-logs/20220508-summary.txt.asc
new file mode 100644
index 0000000..7d7d0ef
--- /dev/null
+++ b/meeting-logs/20220508-summary.txt.asc
@@ -0,0 +1,9 @@
diff --git a/meeting-logs/20220508.txt b/meeting-logs/20220508.txt
new file mode 100644
index 0000000..e4f8a8e
--- /dev/null
+++ b/meeting-logs/20220508.txt
@@ -0,0 +1,159 @@
+[2022-05-08T20:00:08+0100] <@sam_> ok!
+[2022-05-08T20:00:27+0100] <@sam_> hi all, and welcome to the 225th meeting of the Gentoo Council
+[2022-05-08T20:00:30+0100] <@sam_> agenda:
+[2022-05-08T20:00:42+0100] <@sam_> apologies for sending it out late; I'd got confused because I'd sent out the call-for-requests delayed
+[2022-05-08T20:00:45+0100] <@sam_> and then got mixed up
+[2022-05-08T20:00:50+0100] <@sam_> it's a simple lot today though
+[2022-05-08T20:00:53+0100] <@sam_> so..
+[2022-05-08T20:00:57+0100] <@sam_> roll call!
+[2022-05-08T20:01:02+0100] • dilfridge: here
+[2022-05-08T20:01:02+0100] <@sam_> dilfridge: gyakovlev: Marecki: mattst88: mgorny: ulm:
+[2022-05-08T20:01:03+0100] • sam_: here
+[2022-05-08T20:01:05+0100] • Marecki: here
+[2022-05-08T20:01:06+0100] • mattst88: here
+[2022-05-08T20:02:27+0100] • ulm: here
+[2022-05-08T20:02:37+0100] • gyakovlev: here
+[2022-05-08T20:02:41+0100] <@sam_> mgorny:
+[2022-05-08T20:03:34+0100] <@sam_> we'll give him 5 minutes
+[2022-05-08T20:03:45+0100] <@gyakovlev> agenda on our archives, for log purposes:
+[2022-05-08T20:03:45+0100] <@gyakovlev>
+[2022-05-08T20:05:56+0100] <@mgorny> sorry
+[2022-05-08T20:05:57+0100] • mgorny: here
+[2022-05-08T20:05:59+0100] <@sam_> \o/
+[2022-05-08T20:06:03+0100] <@sam_> ok, let's proceed
+[2022-05-08T20:06:04+0100] <@mgorny> trying to figure out qmake
+[2022-05-08T20:06:18+0100] <@sam_> the agenda is in a slightly unusual order but let's go with it (I did bugs before the pkgdev item)
+[2022-05-08T20:06:29+0100] <@sam_> 2. Open bugs with council participation
+[2022-05-08T20:06:41+0100] <@sam_>
+[2022-05-08T20:06:46+0100] <@sam_>
+[2022-05-08T20:06:48+0100] <@sam_> the main thing is bug 835165
+[2022-05-08T20:06:49+0100] <willikins> sam_: "Reimbursement for SSD purchase for Infra 3/14/2022"; Gentoo Foundation, Reimbursements; CONF; antarus:trustees
+[2022-05-08T20:06:57+0100] <@sam_> Marecki: dilfridge: you still need to vote on it, unless you want to discuss it here
+[2022-05-08T20:07:17+0100] <@dilfridge> done
+[2022-05-08T20:07:34+0100] <@sam_> the gist is just that antarus had to emergency pay from his pocket for infra costs
+[2022-05-08T20:08:07+0100] <@sam_> robbat2, antarus, and IIRC some other members did some shopping around, and couldn't find any better deals
+[2022-05-08T20:08:16+0100] <@sam_> it was also quite critical given it impaired woodpecker and other core services
+[2022-05-08T20:09:05+0100] <@mattst88> 6 votes in favor. let's move on and if Marecki has comments we can discuss it later
+[2022-05-08T20:09:08+0100] <@sam_> anyway, looks like Marecki has voted
+[2022-05-08T20:09:12+0100] <@sam_> mattst88: patience
+[2022-05-08T20:09:17+0100] <@sam_> I was just giving him a moment to speak here on IRC too
+[2022-05-08T20:09:37+0100] <@sam_> but anyway, he's commented, and voted yes, so sounds good - 7 votes in favour
+[2022-05-08T20:09:42+0100] <@sam_> passes
+[2022-05-08T20:09:50+0100] <@sam_>
+[2022-05-08T20:09:52+0100] <@sam_> bug 176186
+[2022-05-08T20:09:53+0100] <willikins> sam_: "Gentoo projects file hosting"; Gentoo Infrastructure, Other; IN_P; dsd:infra-bugs
+[2022-05-08T20:10:11+0100] <@sam_> We discussed this in the last meeting; the gist is that we wanted to go with kup if possible
+[2022-05-08T20:10:34+0100] <@sam_> robbat2 reached out to to find out the missing glue for gitolite authentication with kup
+[2022-05-08T20:11:01+0100] <@sam_> we've had a reply with a dump of their internal code
+[2022-05-08T20:11:10+0100] <@sam_> we just need to process it and try wire it up
+[2022-05-08T20:11:21+0100] <@sam_> so, nothing for us to do there, just wanted to keep us informed
+[2022-05-08T20:11:27+0100] <@sam_>
+[2022-05-08T20:11:33+0100] <@sam_> bug 835152
+[2022-05-08T20:11:34+0100] <@mattst88> cool
+[2022-05-08T20:11:35+0100] <willikins> sam_: "Mirror pkgcore/* repos from github"; Gentoo Infrastructure, Git; CONF; sam:infra-bugs
+[2022-05-08T20:11:40+0100] <@sam_> I think we're making progress on gitlab, nothing more to say there really
+[2022-05-08T20:11:53+0100] <@sam_> I think the intention is to host everything for pkgcore on gitlab if possible
+[2022-05-08T20:11:59+0100] <@sam_>
+[2022-05-08T20:12:02+0100] <@sam_> bug 786105
+[2022-05-08T20:12:03+0100] <willikins> sam_: "access to manage projects on GH"; Gentoo Infrastructure, GitHub; CONF; vapier:github
+[2022-05-08T20:12:11+0100] <@sam_> the latest ML discussion fizzled out, with no reply from vapier again
+[2022-05-08T20:12:24+0100] <+antarus> vapier wanted to have lunch, but I am not on the east coast
+[2022-05-08T20:12:27+0100] <@sam_> we could argue it's blocked on gitlab but I don't think this is for council anymore
+[2022-05-08T20:12:31+0100] <@sam_> unCC for now?
+[2022-05-08T20:12:42+0100] <@mattst88> sounds fine to me
+[2022-05-08T20:12:49+0100] <@sam_> great
+[2022-05-08T20:12:52+0100] <@dilfridge> unCC
+[2022-05-08T20:13:19+0100] <@sam_> done
+[2022-05-08T20:13:30+0100] <@sam_>
+[2022-05-08T20:13:31+0100] <@sam_> finally, bug 834997
+[2022-05-08T20:13:33+0100] <willikins> sam_: "Missing summaries for 20211114 and 20211212 council meetings"; Gentoo Council, unspecified; CONF; ulm:dilfridge
+[2022-05-08T20:13:39+0100] <@sam_> looks like it's for you dilfridge
+[2022-05-08T20:13:40+0100] <@dilfridge> yeah, soon
+[2022-05-08T20:13:45+0100] <@sam_> nothing for us to discuss there
+[2022-05-08T20:13:51+0100] <@sam_> alright
+[2022-05-08T20:13:54+0100] <@sam_>
+[2022-05-08T20:13:56+0100] <@sam_> 3. Signoff behaviour of the pkgdev tooling (proposed change is to =
+[2022-05-08T20:13:56+0100] <@sam_> disable signoff by default, but allow opt in via configuration)
+[2022-05-08T20:14:00+0100] <@sam_> arthurzam: ^^
+[2022-05-08T20:14:11+0100] <@sam_> I think this is essentially about us consenting to the change or raising any significant concerns
+[2022-05-08T20:14:33+0100] <@sam_> ulm started the discussion in #gentoo-qa and it went from there; the gist being that some feel the sign-off part should be opt-in rather than opt-out, or it's meaningless
+[2022-05-08T20:14:36+0100] <@mattst88> have we had people submit patches, and then when we ask them for a sign-off and agreement to the DCO they say no?
+[2022-05-08T20:14:41+0100] <@dilfridge> honestly, whoever pushes to gentoo.git should be able to handle a change in default behaviour
+[2022-05-08T20:15:05+0100] <@sam_> mattst88: the only time people say no in my experience is if I ask for real name, not for giving a DCO
+[2022-05-08T20:15:11+0100] <@mattst88> yeah, same here
+[2022-05-08T20:15:14+0100] <@dilfridge> and yes it makes sense to have the SOB off or undefined by default and to make it a conscious decision out of principle
+[2022-05-08T20:15:21+0100] <@gyakovlev> I'm ok if it's explicit opt in via configuration, like repoman always was.
+[2022-05-08T20:15:24+0100] <@sam_> to be honest, I think we've sort of reached consensus on this, even if it's not ideal to have churn, it is what it is
+[2022-05-08T20:15:31+0100] <@gyakovlev> especially if it's done on .git/config basis
+[2022-05-08T20:15:33+0100] <@sam_> obviously we'll have a few moments for folks to discuss
+[2022-05-08T20:15:37+0100] <@gyakovlev> not on global basis
+[2022-05-08T20:15:40+0100] • antarus: shrugs
+[2022-05-08T20:15:46+0100] <@mattst88> yeah, can't you just configure SoB in .git/config?
+[2022-05-08T20:15:48+0100] <@dilfridge> just have people switch it on once
+[2022-05-08T20:15:49+0100] <@sam_> I think arthur just wanted some backing as he's handling the responsibility of a lot of tooling here
+[2022-05-08T20:15:50+0100] <+antarus> one mans churhc is another mans progress
+[2022-05-08T20:15:56+0100] <+antarus> churn*
+[2022-05-08T20:15:59+0100] <@sam_> mattst88: no, sadly, because of git ideological mess
+[2022-05-08T20:16:00+0100] <@mattst88> if you can do that, let's just do it and end the discussion :)
+[2022-05-08T20:16:06+0100] <@gyakovlev> mattst88: git itself used to have such thing, but they removed it.
+[2022-05-08T20:16:07+0100] <@sam_> mattst88: but arthur has added the equivalent to pkgdev config
+[2022-05-08T20:16:13+0100] <@ulm> mattst88: you cannot turn it on in git be default, for good reason
+[2022-05-08T20:16:16+0100] <+arthurzam> Yes, exactly - with some extra help from other devs, we currently have a very good behaviour design we can do for transition and ease of setup config
+[2022-05-08T20:16:16+0100] <+arthurzam> Just some were against this (they were quiet since) so wanted back support as I see this global main tool of gentoo
+[2022-05-08T20:16:17+0100] <@ulm> *by
+[2022-05-08T20:16:19+0100] <@sam_> so I think we're all good, unless someone objects, which I'll give a few minutes for, and then we're moving on
+[2022-05-08T20:16:30+0100] <@sam_> (then I'll call a vote, just for formality)
+[2022-05-08T20:16:41+0100] <@dilfridge> who's formality?
+[2022-05-08T20:16:44+0100] <@sam_> :p
+[2022-05-08T20:16:47+0100] <@mgorny> you know what would be cool? if pkgdev printed the text on the first run, and asked for approval
+[2022-05-08T20:16:54+0100] <@ulm> oh please, do we really need a vote on this?
+[2022-05-08T20:17:04+0100] <@sam_> not if nobody objects, no
+[2022-05-08T20:17:04+0100] <@ulm> micromanagement :(
+[2022-05-08T20:17:14+0100] <@dilfridge> I'm fine with no vote
+[2022-05-08T20:17:16+0100] <@sam_> but at least one person hasn't spoken yet :)
+[2022-05-08T20:17:30+0100] <@dilfridge> Marecki is still busy on the ssd bug
+[2022-05-08T20:17:40+0100] <@Marecki> I really don't care either way.
+[2022-05-08T20:17:42+0100] <@sam_> I think we can do this by acclamation then
+[2022-05-08T20:17:57+0100] <@sam_> we're happy with arthurzam's prerogative and the change is reasonable
+[2022-05-08T20:18:02+0100] <@dilfridge> ack
+[2022-05-08T20:18:04+0100] • ulm: acclaims :)
+[2022-05-08T20:18:06+0100] <@sam_> :)
+[2022-05-08T20:18:13+0100] <@sam_> excellent
+[2022-05-08T20:18:16+0100] <@sam_> now, finally
+[2022-05-08T20:18:18+0100] <+arthurzam> OK, that is good enough for me, I will implement it soon and do a release with announcement. Thank you all
+[2022-05-08T20:18:25+0100] <@sam_> thanks a lot arthurzam!
+[2022-05-08T20:18:29+0100] <@sam_> 4. Open floor
+[2022-05-08T20:18:32+0100] <@sam_> Anyone got any topics to raise?
+[2022-05-08T20:18:42+0100] • NeddySeagoon: raises a hand
+[2022-05-08T20:18:47+0100] <@sam_> NeddySeagoon: What's up?
+[2022-05-08T20:19:52+0100] <+NeddySeagoon> Next month is the last meeting before the election. I can just call it if you want. Council has a few weeks to influnce the timing.
+[2022-05-08T20:20:01+0100] <+NeddySeagoon> What does the team think?
+[2022-05-08T20:20:33+0100] <+NeddySeagoon> I don't need a response tody
+[2022-05-08T20:20:37+0100] <+NeddySeagoon> today*
+[2022-05-08T20:20:55+0100] <@sam_> Define "just call it"? As in pick a date of your choosing, after the next meeting?
+[2022-05-08T20:20:56+0100] <@mattst88> I'm confused what you're asking
+[2022-05-08T20:21:00+0100] <@ulm> same time period as last year should be fine?
+[2022-05-08T20:21:03+0100] <@sam_> yep
+[2022-05-08T20:21:10+0100] <+NeddySeagoon> mattst88: yes
+[2022-05-08T20:21:26+0100] <+NeddySeagoon> ulm: sam_ that werks
+[2022-05-08T20:21:27+0100] <@mattst88> NeddySeagoon: that didn't help :)
+[2022-05-08T20:21:54+0100] <@sam_> ok, I don't think anything for us to do unless someone wants to speak up. We can always revisit anyway?
+[2022-05-08T20:22:00+0100] <@sam_> I think go ahead with normal planning like last year
+[2022-05-08T20:22:16+0100] <+NeddySeagoon> I'll do some prep over the next couple of weeks
+[2022-05-08T20:22:29+0100] <@sam_> I think it's somewhat minutiae (but thank you for asking), and I trust elections to handle it as they see fit
+[2022-05-08T20:22:34+0100] <@mgorny> I'd say whatever works for elections team
+[2022-05-08T20:22:36+0100] <@sam_> ^
+[2022-05-08T20:23:39+0100] <@sam_> so what were you actually asking for? whether we had a preferred date after the next meeting?
+[2022-05-08T20:23:45+0100] <@sam_> i don't think it matters too much
+[2022-05-08T20:24:00+0100] <@sam_> maybe if someone knew they would be unavailable
+[2022-05-08T20:24:23+0100] <+NeddySeagoon> Preferred dates. I'll propose something and email dev ML based on last yeal
+[2022-05-08T20:24:27+0100] <@sam_> sounds good
+[2022-05-08T20:24:34+0100] <@sam_> ok, anything else for open floor?
+[2022-05-08T20:25:40+0100] <@ulm> NeddySeagoon: timing is best when the last meeting isn't within the voting period, and when there's some time after the voting for the new council to organise a meeting in that month
+[2022-05-08T20:25:59+0100] <+NeddySeagoon> ulm: I remember.
+[2022-05-08T20:26:03+0100] <@ulm> which is a little contradictory, but has worked out in the last years
+[2022-05-08T20:26:44+0100] <@sam_> final call? nothing else?
+[2022-05-08T20:27:01+0100] <@mattst88> nothing from me
+[2022-05-08T20:27:17+0100] <@sam_> it's been a pretty quiet month tbh
+[2022-05-08T20:27:22+0100] <@sam_> I think we can call it then
+[2022-05-08T20:27:30+0100] • sam_: bangs the meeting gavel
diff --git a/meeting-logs/20220508.txt.asc b/meeting-logs/20220508.txt.asc
new file mode 100644
index 0000000..fd65768
--- /dev/null
+++ b/meeting-logs/20220508.txt.asc
@@ -0,0 +1,9 @@
diff --git a/meeting-logs/20220612.txt b/meeting-logs/20220612.txt
new file mode 100644
index 0000000..f98c788
--- /dev/null
+++ b/meeting-logs/20220612.txt
@@ -0,0 +1,160 @@
+[2022-06-12T20:00:06+0100] <@sam_> hello
+[2022-06-12T20:00:28+0100] <@sam_> !proj council
+[2022-06-12T20:00:33+0100] <willikins> sam_: ( dilfridge, gyakovlev, marecki, mattst88, mgorny, sam, ulm
+[2022-06-12T20:00:30+0100] <@sam_> ding ding, it's meeting time!
+[2022-06-12T20:00:35+0100] <@sam_> agenda:
+[2022-06-12T20:00:49+0100] <@dionysos> yippi-ka-yay-yay
+[2022-06-12T20:00:49+0100] <@sam_> 1. Roll call
+[2022-06-12T20:00:50+0100] • sam_: here
+[2022-06-12T20:00:57+0100] • ulm: here
+[2022-06-12T20:00:57+0100] • dionysos: here
+[2022-06-12T20:00:58+0100] • Marecki: here
+[2022-06-12T20:01:01+0100] • gyakovlev: here
+[2022-06-12T20:01:21+0100] • mattst88: here
+[2022-06-12T20:01:23+0100] <+antarus> brb
+[2022-06-12T20:01:22+0100] <@sam_> mgorny: ^
+[2022-06-12T20:01:32+0100] <@gyakovlev> dionysos: you omitted the second part of that saying ;-)
+[2022-06-12T20:01:31+0100] <@sam_> dionysos: maybe /nick dilfridge for log
+[2022-06-12T20:02:06+0100] dionysos is now known as dilfridge
+[2022-06-12T20:02:06+0100] <@sam_> <3
+[2022-06-12T20:02:10+0100] • dilfridge: here
+[2022-06-12T20:02:41+0100] <@sam_> we'll give mgorny until 5 past then crack on, he said he's had a few issues with pain today
+[2022-06-12T20:02:54+0100] <@sam_> can wait longer if that's appropriate though. Only second time chairing :)
+[2022-06-12T20:03:05+0100] <+sultan> maybe one of his cats joins shortly :p
+[2022-06-12T20:03:23+0100] <@dilfridge> cat > /dev/council
+[2022-06-12T20:03:39+0100] <@gyakovlev> I'd totally vote for cats in council though
+[2022-06-12T20:03:50+0100] <@dilfridge> you need to nominate one then!
+[2022-06-12T20:04:08+0100] <@gyakovlev> I can even nominate 3
+[2022-06-12T20:04:14+0100] <@dilfridge> meow
+[2022-06-12T20:04:39+0100] <@gyakovlev> but it'd be unfair to nominate only mgorny's 3 cats. will nominate mattst88's cat as well.
+[2022-06-12T20:04:59+0100] <@mattst88> hah, my cat will only accept if she gets treats as compensation
+[2022-06-12T20:05:12+0100] <@sam_> alrighty, we'll crack on, and hopefully mgorny can join us in a bit
+[2022-06-12T20:05:20+0100] <@sam_> 2. Approval of GLEP 68 update for language tags change (
+[2022-06-12T20:05:29+0100] <@sam_> this is IMO pretty straightforward
+[2022-06-12T20:05:41+0100] <@sam_> it's ulm's motion so I'll let him summarise
+[2022-06-12T20:06:04+0100] <@ulm> it's all in the commit message
+[2022-06-12T20:06:28+0100] <@ulm> basically will allow things like lang="pt-BR" in package and category metadata
+[2022-06-12T20:06:40+0100] <@mattst88> yeah, seems like an obvious and good change
+[2022-06-12T20:06:39+0100] <@sam_> it is, I dare say, a no-brainer
+[2022-06-12T20:07:01+0100] <@sam_> any questions? concerns?
+[2022-06-12T20:08:03+0100] <@sam_> motion: Approval of GLEP 68 update for language tags change
+[2022-06-12T20:08:07+0100] <@mattst88> nope, let's vote
+[2022-06-12T20:08:08+0100] • sam_: yes
+[2022-06-12T20:08:14+0100] • mattst88: yes
+[2022-06-12T20:08:22+0100] • Marecki: yes
+[2022-06-12T20:08:38+0100] • gyakovlev: yes
+[2022-06-12T20:09:03+0100] • dilfridge: yes
+[2022-06-12T20:09:08+0100] • ulm: yes
+[2022-06-12T20:09:12+0100] <@ulm> thank you
+[2022-06-12T20:09:24+0100] <@sam_> great, 6 yes, 1 abstention (not present in meeting), 0 no
+[2022-06-12T20:09:31+0100] <@sam_>
+[2022-06-12T20:09:33+0100] <@sam_> 3. Regular arch status review ("arch team health check") (
+[2022-06-12T20:09:48+0100] <@sam_> "The Council periodically reviews the activity of architecture-related activities, most notably but not exclusively the turnaround time of keywording/stabilisation requests. This takes place during June and December meetings, with additional sessions if required."
+[2022-06-12T20:09:59+0100] <@sam_>
+[2022-06-12T20:10:16+0100] <@sam_> I'm not aware of any specific complaints with this at the moment
+[2022-06-12T20:10:27+0100] <@sam_> mattst88 recently dropped alpha back to exp because of issues w/ python keywording
+[2022-06-12T20:10:37+0100] <@sam_> that would've been the only thing I'd have raised
+[2022-06-12T20:10:47+0100] <@gyakovlev> mattst88 dropped alpha to -exp I think
+[2022-06-12T20:11:03+0100] <@dilfridge> that recent spike in bugs for all arches, is that stabilization?
+[2022-06-12T20:11:06+0100] <@mattst88> I'd say everything looks rather healthy
+[2022-06-12T20:11:19+0100] <@Marecki> What's that spike visible across all arches?
+[2022-06-12T20:11:21+0100] <@gyakovlev> also we need mgorny on that topic, python stablereqs are like a canary for arch issues.
+[2022-06-12T20:11:23+0100] <+arthurzam> dilfridge: Yes, huge stablereq filing yesterday
+[2022-06-12T20:11:19+0100] <@sam_> yeah, I think it's mgorny filing a bunch of python bugs
+[2022-06-12T20:11:30+0100] <@Marecki> Stable ones, I mean
+[2022-06-12T20:11:39+0100] <@sam_> but yeah, definitely gyakovlev
+[2022-06-12T20:12:03+0100] <@sam_> I think we're all fine there for now
+[2022-06-12T20:12:08+0100] <@dilfridge> looks all good to me
+[2022-06-12T20:12:19+0100] • dilfridge: needs to add loong to the page
+[2022-06-12T20:12:18+0100] <@sam_> oh yes
+[2022-06-12T20:12:25+0100] <@Marecki> Slightly concerned about mips... No trend either way.
+[2022-06-12T20:12:32+0100] <@mattst88> mips is exp
+[2022-06-12T20:12:38+0100] <@dilfridge> any exp arch is bad
+[2022-06-12T20:12:38+0100] <@sam_> xen0n is going to be working on mips when his loong stuff is less busy too
+[2022-06-12T20:13:01+0100] <@dilfridge> so let's try to get stuff to stable, even if that means dropping keywords on a lot of software
+[2022-06-12T20:12:59+0100] <@sam_> so I'm not too worried about it, but yeah, exp is somewhat a vicious spiral
+[2022-06-12T20:13:08+0100] <@sam_> yeah, we recently got s390 (dilfridge and I) back to stable and it helped a lot
+[2022-06-12T20:13:21+0100] <@dilfridge> s390 was relatively easy because it's server based
+[2022-06-12T20:13:28+0100] <@dilfridge> mips would need a lot more work
+[2022-06-12T20:13:26+0100] <@sam_> mips is going to need a rather vicious set of culling
+[2022-06-12T20:13:47+0100] <@sam_> alright, nothing for us to do here then
+[2022-06-12T20:13:56+0100] <@mattst88> agreed
+[2022-06-12T20:13:52+0100] <@sam_>
+[2022-06-12T20:14:07+0100] <@sam_> 4. Open bugs with council participation
+[2022-06-12T20:14:15+0100] <@sam_>
+[2022-06-12T20:14:22+0100] • dilfridge: is suddenly busy elsewhere
+[2022-06-12T20:14:22+0100] <@sam_> lol
+[2022-06-12T20:14:23+0100] <@sam_>
+[2022-06-12T20:14:26+0100] <@sam_> bug 834997
+[2022-06-12T20:14:31+0100] <willikins> sam_: "Missing summaries for 20211114 and 20211212 council meetings"; Gentoo Council, unspecified; CONF; ulm:dilfridge
+[2022-06-12T20:14:30+0100] • sam_: glares at dilfridge
+[2022-06-12T20:14:42+0100] • dilfridge: glares... elsewhere
+[2022-06-12T20:14:49+0100] <@dilfridge> i will
+[2022-06-12T20:14:59+0100] <@sam_> we also have some logs missing from 2022-03-13
+[2022-06-12T20:15:03+0100] <@gyakovlev> I'm writing april one right now, will send today.
+[2022-06-12T20:15:07+0100] <@sam_> (see
+[2022-06-12T20:15:16+0100] <@sam_> brilliant, thanks, i sent draft for may earlier too
+[2022-06-12T20:15:24+0100] <@mattst88> I think one recent meeting is waiting on me
+[2022-06-12T20:15:31+0100] <@dilfridge> i should have the complete backlog
+[2022-06-12T20:15:45+0100] <@sam_> everyone seems to know what they need to do then
+[2022-06-12T20:15:59+0100] <@sam_> bug 835165
+[2022-06-12T20:16:04+0100] <willikins> sam_: "Reimbursement for SSD purchase for Infra 3/14/2022"; Gentoo Foundation, Reimbursements; CONF; antarus:trustees
+[2022-06-12T20:16:04+0100] <@sam_> we're done on that, so I'll drop us from CC
+[2022-06-12T20:16:19+0100] <@sam_>
+[2022-06-12T20:16:20+0100] <@sam_> bug 835152
+[2022-06-12T20:16:25+0100] <willikins> sam_: "Mirror pkgcore/* repos from github"; Gentoo Infrastructure, Git; CONF; sam:infra-bugs
+[2022-06-12T20:16:30+0100] <@sam_> while this is of interest to us, we can't do anything right now about it as council
+[2022-06-12T20:16:35+0100] <@sam_> someone should let us know if they feel we need to look into it
+[2022-06-12T20:16:40+0100] <@sam_> so i'd propose dropping us again there too
+[2022-06-12T20:16:58+0100] <@ulm> wfm
+[2022-06-12T20:17:03+0100] <@sam_>
+[2022-06-12T20:17:04+0100] <@sam_> bug 176186
+[2022-06-12T20:17:09+0100] <willikins> sam_: "Gentoo projects file hosting"; Gentoo Infrastructure, Other; IN_P; dsd:infra-bugs
+[2022-06-12T20:17:10+0100] <+arthurzam> Um, does count as done?
+[2022-06-12T20:17:08+0100] <@sam_> ditto, IMO.
+[2022-06-12T20:17:22+0100] <@sam_> arthurzam: it might do, actually, I wasn't sure if that was considered stable yet
+[2022-06-12T20:17:40+0100] <@sam_> but I think that's something we could talk about if it became an issue
+[2022-06-12T20:17:52+0100] <+arthurzam> OK, thanks
+[2022-06-12T20:17:51+0100] <@sam_> or if we abandoned gitlab efforts, etc
+[2022-06-12T20:18:00+0100] <@sam_> just want to avoid us having to look at these every month
+[2022-06-12T20:18:08+0100] <@sam_> doesn't mean we don't care about the issues per se, people are free to loop us in if we need to look at it
+[2022-06-12T20:18:21+0100] <@sam_>
+[2022-06-12T20:18:28+0100] <@sam_> 5. Open floor
+[2022-06-12T20:18:31+0100] <@sam_> Anything? :)
+[2022-06-12T20:19:51+0100] <@Marecki> Not a critical thing but - how is the server upgrade coming along?
+[2022-06-12T20:20:12+0100] <@sam_> I'm hoping antarus is back but not sure
+[2022-06-12T20:20:35+0100] <@sam_> At last check, I know that killdeer was at least physically racked, but not yet fully set up
+[2022-06-12T20:20:38+0100] <@sam_> (that's box #1)
+[2022-06-12T20:20:46+0100] <@sam_> I don't know about box #2, or if it arrived yet even
+[2022-06-12T20:20:55+0100] <@sam_> definitely a fair question though
+[2022-06-12T20:21:16+0100] <@mgorny> sorry
+[2022-06-12T20:21:17+0100] <+ajak> yeah, at least one of the servers is usable but not seen any work to get it to production ready yet
+[2022-06-12T20:21:20+0100] <@sam_> I can always add in an answer if we get one from antarus or robbat2 later and make it clear it was post-meeting
+[2022-06-12T20:21:25+0100] <@sam_> in the summary, that is
+[2022-06-12T20:21:33+0100] <@sam_> alright, anything else?
+[2022-06-12T20:21:40+0100] <@mgorny> things got delayed a little bit here ;-/
+[2022-06-12T20:22:06+0100] <@Marecki> Some sort of official status update would be nice... Not at the cost of the actual work, of course.
+[2022-06-12T20:22:17+0100] <@sam_> yeah, I think that's a fair request
+[2022-06-12T20:22:40+0100] <@sam_> we could do it by email or bug, would you mind handling it?
+[2022-06-12T20:22:45+0100] <@mgorny> as for arches, i don't have any major issues right now
+[2022-06-12T20:22:58+0100] <@mgorny> alpha was the only pain, and it's exp now, so not a problem anymore
+[2022-06-12T20:23:49+0100] <@sam_> yep
+[2022-06-12T20:23:50+0100] <@sam_> alright
+[2022-06-12T20:24:01+0100] <@mattst88> mgorny: do we have any updates on joining an umbrella?
+[2022-06-12T20:24:12+0100] <@mgorny> good one
+[2022-06-12T20:24:18+0100] <@mattst88> it appears that no progress has been made by the trustees
+[2022-06-12T20:24:35+0100] <@dilfridge> :)
+[2022-06-12T20:24:37+0100] <@sam_> I'm not really clear on what that's even waiting on
+[2022-06-12T20:24:43+0100] <@sam_> Is it "just" deciding what to go for?
+[2022-06-12T20:24:52+0100] <@mattst88> someone to do something, I think
+[2022-06-12T20:24:55+0100] <@mgorny> the only thing that happened is that sfconservancy has officially closed our request
+[2022-06-12T20:25:05+0100] <@dilfridge> on somebody to feel entitled to do it and to do it
+[2022-06-12T20:25:26+0100] <@mattst88> ISTR the president saying he was going to do stuff this time around
+[2022-06-12T20:25:42+0100] <@dilfridge> make gentoo great again?
+[2022-06-12T20:25:42+0100] <@sam_> feels like we end up in a cycle where it gets too close to a trustees election every time, then everyone talks about joining an umbrella beforehand, then distracted, then ...
+[2022-06-12T20:25:50+0100] <@mattst88> but I think it's time for another trustees election already?
+[2022-06-12T20:26:24+0100] <@dilfridge> yes, after council
+[2022-06-12T20:26:55+0100] <@sam_> alrighty
+[2022-06-12T20:26:57+0100] <@sam_> I think we're done
+[2022-06-12T20:27:11+0100] <@mattst88> yep
+[2022-06-12T20:27:10+0100] • sam_: bangs meeting gavel
diff --git a/meeting-logs/20220612.txt.asc b/meeting-logs/20220612.txt.asc
new file mode 100644
index 0000000..09c85c2
--- /dev/null
+++ b/meeting-logs/20220612.txt.asc
@@ -0,0 +1,9 @@
diff --git a/meeting-logs/README b/meeting-logs/README
index 1acc266..9089cc2 100644
--- a/meeting-logs/README
+++ b/meeting-logs/README
@@ -9,5 +9,8 @@ For the status of older summaries, please consult bug 700364 [2].
The Gentoo Council does not claim copyright for the raw IRC logs.
Depending on jurisdiction, they may or may not be copyrightable.
+Logs and summaries are signed using the following command:
+ gpg -u --detach-sign --armor yyyymmdd.txt