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