path: root/meeting-logs/20220313.txt

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: https://archives.gentoo.org/gentoo-project/message/35a3bd66aa5a6684fb481de468a4623c
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: https://www.theverge.com/2022/2/11/22928867/western-digital-nand-flash-storage-contamination
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 https://archives.gentoo.org/gentoo-project/message/35a3bd66aa5a6684fb481de468a4623c
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 https://archives.gentoo.org/gentoo-project/message/35a3bd66aa5a6684fb481de468a4623c
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> | https://bugs.gentoo.org/835013 "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 https://gitweb.gentoo.org/proj/devmanual.git/log/?qt=grep&q=pkgdev
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 https://github.com/gentoo/devmanual/pull/274
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 https://github.com/gentoo/devmanual/pull/274#pullrequestreview-907975588 ("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> | https://bugs.gentoo.org/834997 "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