path: root/meeting-logs/20210613.txt

14:05 <@WilliamH> Ok, let's get started.
14:05 <@WilliamH> The agenda is here: https://archives.gentoo.org/gentoo-project/message/2be6e27c946a5348e27d6e6ec338de04
14:05 <@WilliamH> rol call:
14:05  * WilliamH here
14:05  * slyfox here
14:05  * mattst88 here
14:05  * gyakovlev here
14:05  * dilfridge here
14:05  * Whissi here
14:05  * ulm here
14:06 <@WilliamH> Cool, we're all here. :-)
14:06 <@WilliamH> 2. EAPI 8 approval.
14:06 <@ulm> https://archives.gentoo.org/gentoo-project/message/26ec04fc812d1810b52424b1fe1809c2
14:06 <@WilliamH> Do we have anything to discuss on this?
14:07 <@ulm> should we have just one vote, or vote on changed features first?
14:07 <@WilliamH> It seems not, so let's vote: The council approves EAPI 8.
14:07 <@dilfridge> mgorny had some sort of status board, right?
14:07 <@mattst88> yes, on the Wiki
14:07 <@WilliamH> ah ok. let's wait for mgorny for a minute.
14:07 <@ulm> https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_8_tentative_features
14:07 <@gyakovlev> https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_8_tentative_features
14:07 <@dilfridge> mostly asking because that list still includes non-implemented features?
14:07 <@ulm> yes, it does
14:08 <@dilfridge> ok that's just "Variant of || ( ) with defined runtime behaviour"
14:08 <@ulm> "Variant of || ( ) with defined runtime behaviour" and "RESTRICT value for network-restricted tests" have been dropped
14:08 <@ulm> "Empty working directory in pkg_* phases" and "Ban useq, hasq, and hasv functions" added
14:09 <@dilfridge> ok
14:09 <@dilfridge> good, we have this in the log now
14:09 <@ulm> :)
14:09 <@WilliamH> So do we need to vote on each feature or do we just do one vote for the EAPI?
14:09 <@slyfox> i'm ok for all set
14:09 <@dilfridge> one vote should be fine
14:10 <@gyakovlev> WilliamH: let's do a full vote, if there are disagreements we can go in detail
14:10 <@gyakovlev> by saying full I mean one-for-all
14:10 <@dilfridge> not all-for-one? :D
14:11 <@WilliamH> sounds good to me.
14:11 <+sam_> I was worried for a minute..
14:11 <@WilliamH> let's vote: The council approves EAPI 8.
14:11  * slyfox yes
14:11  * gyakovlev yes
14:11  * dilfridge yes
14:11 <@ulm> with features as listed in https://archives.gentoo.org/gentoo-project/message/26ec04fc812d1810b52424b1fe1809c2
14:11  * mattst88 yes
14:11  * WilliamH yes
14:12  * ulm yes
14:12 <@mattst88> Whissi: you still here?
14:12 <@WilliamH> the motion passes.
14:12 <@Whissi> I am here. Just checking mail
14:12 <@WilliamH> moving on:
14:12 <@WilliamH> 3. glep 82.
14:12 <+mgorny> i'm around now
14:12 <@WilliamH> bug 793164
14:12 < willikins> WilliamH: https://bugs.gentoo.org/793164 "GLEP 82: Repository configuration file (layout.conf)"; Documentation, New GLEP submissions; CONF; mgorny:glep
14:12  * Whissi is confused because it said restrict network-restricted was dropped but it is in the mail?
14:13 <@Whissi> s/it/ulm/
14:13 <@ulm> Whissi: it has been implemented as optional token in PROPERTIES
14:13 <+sam_> retrospectively
14:13 <@gyakovlev> WilliamH: we did not get Whissi's voice yet.
14:13 <@ulm> so it doesn't need to be EAPI dependent
14:13  * Whissi yes
14:13 <@WilliamH> gyakovlev: ok, 
14:13 <@gyakovlev> now we did it.
14:13 <@ulm> unanimous then
14:13 <@WilliamH> Now we did, so unanimous.
14:13 <@ulm> thank you folks :)
14:14 <@WilliamH> now moving on. 
14:14 <+sam_> does it count if the vote was closed? :)
14:14 <@WilliamH> 3. glep 82 (bug 793164)...
14:14 < willikins> WilliamH: https://bugs.gentoo.org/793164 "GLEP 82: Repository configuration file (layout.conf)"; Documentation, New GLEP submissions; CONF; mgorny:glep
14:14 <@gyakovlev> sam_: tsss, that's a bikeshed for a month or two.
14:15 <@dilfridge> sam_: that topic is deferred to the next council
14:16 <@WilliamH> Do we have anything to discuss on glep 82 ?
14:16 <@mattst88> I'm happy with GLEP82. It's just codifying what we've been doing for the last 10 years
14:16 <@dilfridge> ++
14:16 <@WilliamH> Ok, let's vote: The council approves glep 82.
14:16  * slyfox yes
14:16  * WilliamH yes
14:16  * dilfridge yes
14:16  * Whissi yes
14:16  * gyakovlev yes
14:16  * mattst88 yes
14:17 <@WilliamH> We're missing a vote.
14:17 <@slyfox> ulm: ^
14:17 <+sam_> he's too busy pushing dates to git ;)
14:17  * ulm yes
14:17 <+sam_> [20:15:56]  <+gentoovcs> ulm → proj/pms:eapi-8 (/) Cheat sheet: EAPI 8 approval date
14:17 <@gyakovlev> I had a suggestion for it but can propose it later as an addition after discussion with glep author.
14:18 <@WilliamH> unanimous again. :-)
14:18 <@WilliamH> 4. mark glep 72 final: bug 617612
14:18 < willikins> WilliamH: https://bugs.gentoo.org/617612 "GLEP 72: Architecture stability status file"; Documentation, New GLEP submissions; IN_P; dilfridge:glep
14:19 <@dilfridge> not much left to do here
14:19 <@WilliamH> dilfridge: ok.
14:19 <@gyakovlev> dilfridge: just say yes of it and that's it? afaik it's been working in the wild for long time by now.
14:19 <@mattst88> We're just voting to make it "Final", right?
14:19 <@dilfridge> exactly
14:19 <@dilfridge> it's already in use
14:20 <@WilliamH> Let's vote. the council approves marking glep  72 final.
14:20 <@ulm> yep, jsut about status update
14:20  * slyfox yes
14:20 <@ulm> *just
14:20  * dilfridge yes
14:20  * gyakovlev yes
14:20  * mattst88 yes
14:20  * ulm yes
14:20  * WilliamH yes
14:20  * Whissi yes
14:20 <@WilliamH> unanymous.
14:20 <@WilliamH> grr typo
14:21 <@dilfridge> that was the anonymoose typing
14:21 <@WilliamH> ... moving on.
14:21 <@slyfox> +1
14:21 <@WilliamH> open bugs with council participation.
14:22 <@WilliamH> bug 779451
14:22 < willikins> WilliamH: https://bugs.gentoo.org/779451 "Request to add Gentoo developer business card to Gentoo Artwork"; Gentoo Foundation, Artwork approval; UNCO; alicef:artwork
14:22 <@WilliamH> We are still on that bug.
14:23 <@dilfridge> hmm I think we already decided to close that?
14:24 <+sam_> what is the council actually doing there?
14:24 <@WilliamH> We didn't say to close it, just that we can't do anything one way or another. I will look and put the update on it we came up with last meeting if it isn't there. 
14:24 <@dilfridge> not sure
14:24 <@dilfridge> ok why not just un-cc us?
14:24 <@dilfridge> I mean... 
14:25 <@mattst88> yes, agreed. let's just un-cc council@
14:25 <@WilliamH> Ok I can do that.
14:25 <@slyfox> thanks
14:25 <@WilliamH> bug 751010
14:25 < willikins> WilliamH: https://bugs.gentoo.org/751010 "Missing summaries for 20210314 council meetings"; Gentoo Council, unspecified; CONF; ulm:council
14:25 <@WilliamH> I'm up to date with mine.
14:26 <@gyakovlev> 2021-03-14 is still missing, dilfridge
14:26 <@gyakovlev> rest are uploaded.
14:26 <@dilfridge> ah
14:26 <@dilfridge> ok sorry, I thought I was done
14:26 <@dilfridge> the rest is all complete by now
14:26 <@gyakovlev> log is there, just not summary
14:26 <@dilfridge> yes
14:26 <@WilliamH> dilfridge: cool, close this after your latest one is in.
14:26 <@gyakovlev> just 1 small one and we can pass a clean state to next council =)
14:27 <@WilliamH> bug 784710
14:27 < willikins> WilliamH: https://bugs.gentoo.org/784710 "Remove SHA512 hash from Manifests"; Gentoo Council, unspecified; CONF; mgorny:council
14:27 <@Whissi> We also had this one
14:28 <+sam_> an interesting part is how much it'd reduce manifests by
14:28 <@gyakovlev> sam_: especially for go packages
14:28 <@gyakovlev> which can be 2000 lines long
14:28 <@mattst88> I'd prefer some sort of macro-level performance data (if that's what we're claiming is improved) or the manifest size changes for the whole repo, etc
14:28 <+sam_> gyakovlev: exactly
14:28 <+sam_> but as a non-voting person, it might be nice to see some numbers on the bug before a final decision is made 
14:29 <+sam_> (however it is obvious it'll be > ~50%)
14:29 <@mattst88> I think the argument that we should have multiple hashes in case one is broken is specious
14:29 <@gyakovlev> sys-cluster/minikube:<master> $ wc -l Manifest 
14:29 <@gyakovlev> 2410 Manifest
14:29 <@mattst88> holy...
14:30 <+sam_> gyakovlev: could you quickly use cut to get the size with 1st and 2nd hash and compare?
14:30 <@gyakovlev> mattst88: it takes good 15 minutes to download, 30 seconds to build
14:30 <+sam_> no worries if not
14:30 <@WilliamH> gyakovlev: the line count isn't going to change, but the character count would.
14:30 <@slyfox> the whole ::gentoo is 187MB. I would say it's not a lot.
14:30 <@gyakovlev> WilliamH: yeah by a lot
14:30 <@dilfridge> huettel@pinacolada ~/Gentoo/gentoo/dev-texlive/texlive-latexextra $ wc -l Manifest 
14:30 <@dilfridge> 6880 Manifest
14:31 <@Whissi> mattst88: Exactly. Given that some distfiles are also not publicly available (fetch restriction), in case we need to switch hash because of an emergency, we would put some files at risk for no reason.
14:31 <+sam_> I think you're disagreeing with matt, no?
14:31 <+mgorny> $ find -name Manifest -exec cat {} + | wc -l
14:31 <+mgorny> 106451
14:31 <@mattst88> I think so as well; specious == superficially plausible, but actually wrong according to google
14:31 <@Whissi> And robbat2 had the argument to have one hash used by upstream sometimes so you can compare manually, too.
14:32 <@gyakovlev> $ du -hs Manifest*
14:32 <@gyakovlev> 501K    Manifest
14:32 <@gyakovlev> 281K    Manifest.blakeonly
14:32 <@gyakovlev> $ du -hs --apparent-size Manifest*
14:32 <@gyakovlev> 809K    Manifest
14:32 <@gyakovlev> 489K    Manifest.blakeonly
14:32 <+sam_> Whissi: I think robbat2 was saying that it's less important nowadays because upstreams are not using uniform hashes
14:32 <@Whissi> No.
14:32 <@Whissi> That was not was he was saying.
14:32 <@Whissi> *what
14:32 <@ulm> we don't use upstream hashes
14:32 <+sam_> oh, I see, yes
14:32 <+mgorny> removing SHA512 means removing 136 bytes from every line
14:32 <@ulm> that's a separate issue
14:33 <@Whissi> But anyway, this was not the main argument.
14:33 <+sam_> ulm: it's not, because robbat2's argument (I agree with Whissi's interpretation now) was that it's useful to have the same hash algorithm as a lot of upstreams, but this is really a convenience thing.
14:33 <+mgorny> so if my math is correct, 13.8 MiB
14:33 <+mgorny> (of apparent size)
14:34 <@gyakovlev> mgorny: it's not much but it's honest work =)
14:34 <@WilliamH> So what is the most common upstream hash?
14:34 <@Whissi> SHA512
14:34 <+sam_> my view is that it's a convenience thing and it doesn't really matter
14:34 <+sam_> all it takes is a few upstreams to not use the same hash and you have to adapt tooling anyway
14:34 <+mgorny> Whissi: [citation needed]
14:34 <@gyakovlev> Whissi: do you have statistic for that?
14:34 <+sam_> it's not a reason to bloat Manifests and I'm not sure if it is definitely SHA512..
14:35 <@ulm> sam_: it's a different question, and we don't have any mechanism in place to records what hash is used by upstreams
14:35 <@ulm> *record
14:35 <+sam_> ulm: indeed, just a convenience thing, it's not really an argument per se
14:35 <@Whissi> gyakovlev: No statistics... but look for GNU projects. If you will find .md5 files, you will also find .sha256 and .sha512 files.
14:35 <@WilliamH> The more I think about it, I'm not really sure it matters either.
14:35 <@gyakovlev> Whissi: I agree it's more common than blake2b in upstreams, but not the most common among all.
14:35 <@mattst88> I don't know either; X.Org release announcements contain SHA256 and SHA512. GNOME uses SHA256
14:35 <+sam_> I think we'd do best to leave out this population count stuff..
14:35 <+mgorny> Whissi: i dare guess sha1 is more common
14:36 <@ulm> if Manifest size was an armument we'd use md5 :p
14:36 <@ulm> *argument
14:36 <@Whissi> mgorny: Right. But we don't provide SHA1.
14:36 <+sam_> ulm: MD5 and SHA1!
14:36 <@Whissi> I only looked at what we have.
14:36 <+sam_> Right, let's rewind for a moment
14:36 <+sam_> this is about whether we want to have 2 hashes in the manifest
14:36 <+sam_> it's not about choosing a new one
14:36 <+sam_> popularity is mostly irrelevant in terms of upstream usage
14:36 <+sam_> (we have no evidence right now in terms of that)
14:37 <@WilliamH> Do we know if one is more vulnerable than the other to being compromised?
14:37 <@gyakovlev> we should be more like paludis and not have manifests at all!
14:37 <@slyfox> that's a question for security@
14:37  * gyakovlev hides
14:37 <@mattst88> We're not cryptographers, so no
14:37 <+sam_> what mattst88 said
14:37 <+sam_> if either were weak, we'd know and it'd be public
14:37 <@Whissi> These are competing algorithms at least. Not the same family, which is good.
14:38 <@Whissi> So if one will fail, the other will hopefully not be affected.
14:38 <+sam_> this is really like saying all developers should have PGP keys of two different types
14:38 <+sam_> RSA and EC
14:38 <+sam_> it's voodoo
14:38 <+sam_> it's true, but it's not really meaningful
14:38 <+sam_> ultimately, if one of these got broken, everyone (inc. us) would be in a lot of trouble
14:38 <@Whissi> There is an important difference: Developer could at any point create a new key. But re-hashing all distfiles in an emergency is impossible.
14:39 <@mattst88> I really don't care if we have multiple hashes. 13.8M seems like a lot, but it's probably < 10% of the whole tree. I'm happy to stop debating and just keep the status quo for now
14:39 <+sam_> that's definitely true, although I suspect we'd have other problems in such a case
14:39 <@dilfridge> let's keep the status quo and close the bug.
14:39 <@Whissi> +1
14:39 <+sam_> I don't think there's a strong case for doing anything
14:39 <+mgorny> Whissi: how probable it is that one hash will be broken in such a horrible way to make it easy to create a meaningful distfile with the same size and matching format?
14:39 <@WilliamH> Personally I don't care either way. ;-)
14:40 <@dilfridge> exactly, it's not that important
14:40 <@ulm> if there was a strong case, we'd have switched to binary or base64 long time ago
14:40 <+mgorny> i don't find it important either but i'd rather not reject it based on Whissi's pseudoarguments
14:40 <@Whissi> mgorny: I dunno. I wouldn't expect a breakage but I'd like to stay prepared. I mean, what do we gain from dropping a second hash? What's the benefit? Just 15mb?
14:41 <@Whissi> In this case it isn't worth it.
14:41 <@ulm> it's 15 MB
14:41 <+mgorny> the benefit is that a package manager doesn't have to implement two hashes
14:41 <@ulm> and I think users can disable hashes in their config
14:41 <@Whissi> In case Python would drop SHA512 support and we would need to pull in an additional lib which bad depgraph just for everyone... that's a different story for example.
14:41 <@ulm> so there's not really a speedup
14:41 <@Whissi> But I don't see something like that.
14:42 <@mattst88> mgorny: python has all of these built-in, right? import hashlib?
14:42 <+sam_> ... does anyone else do 1/2/N hashes?
14:42 <+mgorny> mattst88: think of paludis!
14:42 <@mattst88> lol
14:42 <+sam_> I know Fedora just does one (SHA512)
14:42 <@mattst88> FWIW: python3 -c 'import hashlib; print(hashlib.algorithms_available)'
14:43 <@mattst88> (has blake2b and sha512)
14:43 <@Whissi> And isn't SHA512 the one with better hardware acceleration? *duck*
14:43 <+sam_> Not on my Celeron!
14:43 <@Whissi> In mean in general :p
14:43  * dilfridge joins the Ah Forget It Tendency
14:44 <+sam_> I think so too
14:44 <+mgorny> Whissi: haven't seen anyone reporting blake to be slower
14:45 <+sam_> I'm torn here because I don't really care about arguing on this, but I also feel like we're keeping it even when nobody else is just to feel warm 
14:46 <+sam_> does *anyone* feel strongly? :)
14:46 <@Whissi> For keeping, yes.
14:46 <@mattst88> I don't feel strongly one way or another
14:46 <@WilliamH> Not me really.
14:47 <@WilliamH> I don't think there's a strong argument either way.
14:47 <@mattst88> I think this is a pretty good example of bikeshedding, tbh
14:47 <@WilliamH> mattst88: heh
14:47 <@slyfox> i don't care. adding new hashes is natural if we need to transit. having a steady state policy would be nice, but i'd like security@ to declare what is it.
14:47 <@Whissi> Remember that verify-sig discussion? I think mgorny also asked me how likely it is, that a malicious GPG key... I would have said "very likely"... few weeks later we learned about bug 767814 =)
14:47 < willikins> Whissi: https://bugs.gentoo.org/767814 "<dev-libs/libgcrypt-1.9.1: Exploitable buffer overflow (CVE-2021-3345)"; Gentoo Security, Vulnerabilities; IN_P; hanno:security
14:48 <@mattst88> approved EAPI=8 7-0 in less than 2 minutes. debated something no one really cares about for 15
14:48 <@Whissi> s/very likely/very unlikely/
14:48 <+sam_> to be fair, a cryptographic break isn't the same thing as an implementation issue
14:48 <+sam_> but yeah, I get it
14:49 <@Whissi> Let's move on
14:49 <@WilliamH> Ok, let's not close the bug and  move on.
14:49 <@Whissi> Not closing?
14:49 <@Whissi> You want to continue next month?
14:49 <@WilliamH> one sec.
14:49 <+sam_> please no..
14:49 <@gyakovlev> yeah gotta leave something unpainted for next council.
14:49 <@slyfox> let's not discuss it next time
14:49 <@WilliamH> lol
14:49 <@WilliamH> one sec
14:50 <@WilliamH> bug 774489
14:50 < willikins> WilliamH: https://bugs.gentoo.org/774489 "GLEP 67: add proxied-maint="" attribute"; Documentation, GLEP Changes; CONF; mgorny:glep
14:50 <@WilliamH> That should be closed.
14:50 <@Whissi> yes
14:51 <@WilliamH> bug 736760
14:51 < willikins> WilliamH: https://bugs.gentoo.org/736760 "Application to Software Freedom Conservancy"; Gentoo Foundation, Proposals; CONF; mgorny:trustees
14:51 <@WilliamH> Why are we still on this bug?
14:51 <+sam_> I think it's just an FYI thing
14:51 <@WilliamH> ok.
14:51 <@WilliamH> no updates then.
14:52 <@WilliamH> moving on.
14:52 <@WilliamH> open floor:
14:52  * WilliamH listens
14:52 <+mgorny> well, yesterday i came up with this idea that it would be nice to somehow summarize the Council term
14:52 <+mgorny> (but it was too late to put it on agenda)
14:53 <+mgorny> still, maybe someone wants to say something
14:53 <@mattst88> Can we ask GSoC admins to form a Gentoo project, make a wiki page, create a mail alias, etc?
14:53 <+sam_> (I have two points to make, but I'll do so in a minute ^^)
14:53 <+sam_> (new topic)
14:53 <@Whissi> There's a mail alias. *duck*
14:53 <@mattst88> It would be nice to know who is involved in GSoC from year to year
14:53 <@slyfox> Creating a project sounds nice. Do they have informal leader?
14:53 <@mattst88> Whissi: ??
14:53 <@Whissi> Wiki lists gentoo-soc@lists.gentoo.org
14:54 <@mattst88> that's not an alias
14:54 <+sam_> that looks public
14:54 <+sam_> (I had to check)
14:54 <@gyakovlev> that does not look like an alias
14:54 <@Whissi> Ah sorry, you asked about alias.
14:54 <@gyakovlev> damn lag
14:54 <@Whissi> Sorry!
14:54 <+sam_> honestly I didn't realise that existed
14:54 <+sam_> i'm not sure it should exist
14:54 <+sam_> it seems like it'd be much more useful to have us all aware of what's happening
14:55 <+sam_> we could offer help if a student is struggling in e.g. their progress report, and so on
14:55 <@mattst88> so, anyone against asking them to form a real project?
14:55 <@slyfox> nope
14:55 <@gyakovlev> not at all
14:55 <@WilliamH> no
14:55 <@gyakovlev> full on in favor
14:55 <@Whissi> I don't see how a formal project with lead election would work but... 
14:55 <@mattst88> great
14:55 <@Whissi> Not sure if a porject must have a lead
14:56 <@WilliamH> Well, I wouldn't necessarily worry about a lead election.
14:56 <@mattst88> Whissi: the same way any regular project would? in fact, since GSoC is a yearly thing, there's a pretty opportune time to select a leader
14:56 <@mattst88> but yeah, I don't really care about that. I just want to be able to know who's involved and contact them
14:56 <@Whissi> mattst88: I would be surprised seeing anyone making a 1y commitment in time =)
14:56 <@Whissi> But sure, go on
14:57 <@gyakovlev> Whissi: why do you always disagree on something?
14:57 <@mattst88> I'd imagine they'd just select a leader immediately before the GSoC process starts for the year?
14:57 <@WilliamH> moving on, next topic:
14:57 <@mattst88> that seems like a pretty obvious thing to do, doesn't it?
14:57 <@Whissi> gyakovlev: If you see having an opinion as disagreement, *shrug*
14:58 <@mattst88> so can I say "Council asks GSoC admins to form a project"?
14:58 <@Whissi> yes
14:58 <@WilliamH> fwm
14:58 <@mattst88> Whissi: it's that you just bring up trivial problems that don't really block anything, and then we spend a lot of time trying to figure out if you're actually against something or not
14:59 <@Whissi> Because people often do quick solutions without thinking to the end and I don't like that.
14:59 <@gyakovlev> Whissi: but having different opinion is disagreement =)
15:00 <+sam_> It might help if, when playing devil's advocate, we say so
15:00 <+sam_> "I agree/disagree with X, but can we just talk about Y for a minute?"
15:00 <+sam_> that way, we're a bit clearer on where people are coming from
15:00 <@Whissi> A different opinion would be "I am against..." - I just said that I don't see how a project would fit at all and shared why but as said, I am not blocking.
15:01 <+sam_> (maybe people interpret some things as agree/disagreement, if you're just trying to explore a topic, so making it clearer could help)
15:01 <@slyfox> i assume there is someone in contact with google each year
15:01 <@slyfox> that would be a natural point of contact to list (leader or not)
15:01 <@WilliamH> slyfox++
15:01 <+sam_> not sure if that's one or many people
15:01 <@gyakovlev> well, 6 people see value, 1 don
15:01 <+sam_> but agreed
15:01 <@gyakovlev> t
15:01 <@gyakovlev> idk...
15:02 <+sam_> (I mean: natural choice is definitely that person(s) speaking to Google)
15:02 <@gyakovlev> there should be official entry point to avoid something, you know =)
15:02 <+sam_> okay okay
15:02 <+sam_> all happy with asking GSoC to officially form a project?
15:02 <@dilfridge> let's ask the other way around, what reason is there *not* to have a normal project?
15:02  * dilfridge yes
15:02 <@WilliamH> brb stepping away for a second
15:03  * slyfox yes
15:03  * mattst88 yes
15:03  * ulm yes
15:03 <+sam_> let's wait for whissi and WilliamH but I think they both already expressed a view
15:04 <@dilfridge> more than one?
15:04 <+sam_> (and gyakovlev)
15:04  * Whissi yes
15:04  * gyakovlev yes
15:04 <@mattst88> sam_: did you have something else you wanted to bring up?
15:04 <+sam_> hi, yes!
15:04 <@mattst88> I'd say go ahead
15:04 <+sam_> it's a two-parter about EAPIs
15:05 <+sam_> 1. Would council be willing to declare EAPI 6 deprecated after 27th June? (That's when it's been 3 years).
15:05 <+sam_> 2. I'd like to include an unofficial request re EAPI 8: we should try clean up eclasses and take the opportunity before adding new EAPI support. i.e. we should encourage people to put the EAPI 8 support patches to the ML, even if it's e.g. cmake.eclass (which is sometimes seen as kde@'s purview), in order to ensure we maximise such opportunities to cleanup indirect inherits and so on. 
15:05 <@WilliamH> I don't have a strong opinion, but a project would be helpful.
15:05 <+sam_> ----
15:06 <@ulm> sam_: let's wait for eapi 8 to go live, before deprecating 6
15:06 <+amadio> Hi, I think the mail alias is soc-mentors@gentoo.org
15:06 <+sam_> ulm: completely fine with me, I just wanted to raise it
15:06 <@gyakovlev> sam_: also, maybe it's more QA territory, I'd like for eclasses to add future guards against new EAPIs. ALL eclasses, no matter what they do.
15:06 <@slyfox> deprecating EAPI=6 sounds like a good agenda item for next council meeting. I'd also suggest posting to -dev@ ML
15:06 <@ulm> otherwise we may end up with 6 -> 7 -> 8 updates when it could be 6 -> 8 directly
15:07 <@mattst88> amadio: I thought that might be the case as well, but it's not clear and the name suggests that it might not include the administrators
15:07 <@dilfridge> let's deprecate 6 when 8 becomes acceptable for stable?
15:07 <@mattst88> amadio: I guess we'll figure it out when we ask them :)
15:07 <@gyakovlev> sam_: I've seen to many eclasses without future eapi guard break silently and unexpectedly. this should not be the norm.
15:07 <@ulm> dilfridge: something like that, yes
15:07 <+sam_> gyakovlev: 100% agreed, let's take it to QA first and go from there
15:07 <+sam_> dilfridge, ulm, slyfox: that sounds fine with me, thanks for comments guys
15:08 <@dilfridge> also, we still have EAPI=5 around and it will take a bit to remove it
15:08 <@dilfridge> about 1500 ebuilds
15:08 <+sam_> yeah, give me a few weeks.. ;)
15:08 <@ulm> yes, time to ban 5
15:08 <@dilfridge> ^^
15:08 <@gyakovlev> sam_: can you put my item as part of your item 2 maybe?
15:08 <+amadio> I think forming a project is a good idea. I've just co-mentored a project in the past, so I'm in the mailing lists.
15:08 <+sam_> gyakovlev: ok, one sec
15:08 <@gyakovlev> amadio: thanks for real feedback 
15:08 <@dilfridge> ++
15:08 <@gyakovlev> from an actual participant
15:08 <+sam_> (please hold...)
15:09 <@dilfridge> (elevator music)
15:09 <+sam_> 2. I'd like to include an unofficial request re EAPI 8. We should try clean up eclasses before adding EAPI 8 support to them. This includes adding future EAPI guards on changes, but also clean up indirect inherits and so on. We encourage people to put the EAPI 8 support patches to the ML, even if it's e.g. cmake.eclass (which is sometimes seen as kde@'s purview), in order to ensure we maximise such opportunities.
15:10 <+sam_> would council be willing to endorse that statement?
15:10 <@mattst88> I'm fine with that
15:10 <@dilfridge> sounds ok to me
15:10 <+sam_> (note: EAPI guards are important because it means we don't have to audit them in a hurry to make sure we're not breaking something retrospectively, and forces us to do a check and modernise them at the point of a new EAPI, which is a nice periodic refresh.)
15:11 <@slyfox> do we still have nontrivial eclasses without guards?
15:11 <@gyakovlev> yes, i'd even go as far as not having an EAPI=9 guard on adding EAPI=8 support a bug.
15:11 <@gyakovlev> slyfox: there were cases, yes
15:11 <+sam_> I have been working to include these, but we still have some
15:11 <@gyakovlev> idk as of right now, but worth checking
15:12 <@slyfox> maybe pkgcheck should test for eclass sourcability with EAPI=nonexistent :)
15:12 <@mattst88> not a bad idea
15:12 <@gyakovlev> I know a couple of java ones that still confuse BDEPEND and RDEPEND and break on that ground, because nobody guarded EAPI=7
15:12 <+sam_> that's a cute idea actually
15:12 <+sam_> thanks slyfox 
15:12 <@dilfridge> yes, good idea
15:12 <+sam_> slyfox: if you don't, I will file a bug for this with pkgcheck
15:12 <@WilliamH> We could actually clean up some of the guards too.
15:13 <@slyfox> please do file a bug
15:13 <@gyakovlev> slyfox: even EAPI=9 should be illegal imo
15:13 <+sam_> ofc
15:13 <@slyfox> gyakovlev: not for long perhaps :)
15:13 <+sam_> WilliamH: agreed, full cleanup time (without bikeshedding, just doing as much as we can)
15:13 <@WilliamH> I've seen eclasses with two different guards... one for "too old" eapis and one for "unknown eapis" or similar...
15:13 <@gyakovlev> WilliamH: it should be the norm
15:13  * sam_ nods
15:14 <@WilliamH> I've always thought it should just have valid eapis the eclass supports and die for all others.
15:14 <+sam_> yeah, that's what I'd like to enforce going forward
15:14 <@gyakovlev> but helpful message is nice though
15:14 <+sam_> or at least 'kindly request' ;)
15:14 <@gyakovlev> saying if it's too old or unknown
15:14 <@WilliamH> gyakovlev: sure, but not two messages. 
15:14 <+sam_> honestly, I dare say that's something for QA policy
15:15 <+sam_> not saying I agree/disagree, but it's a nit :)
15:15 <@WilliamH> Basically I've seen things like (pseudo code)....
15:15 <@ulm> it's normally clear, so IMHO no need for two messages
15:15 <+sam_> let's not worry about the exact details of phrasing of dies
15:15 <@WilliamH> if eapi is valid...
15:15 <@WilliamH> no message
15:15 <@WilliamH> if it is an old eapi
15:15 <@WilliamH> one message
15:15 <@WilliamH> else
15:15 <@WilliamH> another message saying it is unsupported
15:15 <@WilliamH> So you just need one message.
15:16 <@mattst88> okay guys. I'm bored :)
15:16 <+sam_> I think on balance I'd prefer one but it's orthogonal here
15:16 <@WilliamH> ulm++
15:16 <+sam_> let's move on
15:16 <+sam_> is everyone happy endorsing, or no?
15:16 <@WilliamH> any more topics?
15:16 <@slyfox> sure
15:16  * gyakovlev yes
15:16  * mattst88 yes
15:16 <@ulm> fine with me
15:16 <@WilliamH> fwm
15:16 <@dilfridge> wfm
15:17 <@gyakovlev> Whissi: ? you still here?
15:17  * Whissi yes
15:17 <@WilliamH> any more topics?
15:17 <+sam_> all good, back to you WilliamH 
15:17 <+sam_> thanks guys
15:17  * WilliamH listens for a minute.
15:18  * WilliamH bangs the gavel
15:18 <@WilliamH> meeting closed