diff options
Diffstat (limited to 'meeting-logs/20220313.txt')
| -rw-r--r-- | meeting-logs/20220313.txt | 285 |
1 files changed, 285 insertions, 0 deletions
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: 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 |