path: root/meeting-logs/20180513.txt

19:00 <@tamiko> slyfox: *ping*
19:00 <@slyfox> \o/
19:00 <@slyfox> !proj council
19:00 <+willikins> (council@gentoo.org) dilfridge, k_f, mgorny, slyfox, tamiko, ulm, williamh
19:01 <@slyfox> I hereby declare meeting to start
19:01  * ulm here
19:01 <@slyfox> Today's agenda: https://archives.gentoo.org/gentoo-project/message/cf34f0f6345127953d42ecd741a8d360
19:01  * WilliamH here
19:01 <@slyfox> 1. Roll call
19:01  * slyfox here
19:01  * K_F here
19:01  * tamiko here
19:01  * WilliamH here
19:02 <@slyfox> dilfridge, mgorny ^
19:02 <@slyfox> give them 2 minutes?
19:02 <@K_F> sure
19:04 <@slyfox> -ETIMEDOUT
19:04 <@slyfox> 2. Deprecating EAPI 5 (leftover from previous meeting) by mgorny@
19:04 <@slyfox>     https://archives.gentoo.org/gentoo-project/message/e453732a4613485ea26bf754c40df087
19:05 <@tamiko> So the last time we didn't quite reach a consensus here.
19:06 <@slyfox> AFAIU the question is about expanding 'eapis-deprecated = 0 2 3 4' to 'eapis-deprecated = 0 2 3 4 5'
19:06  * WilliamH is ok with it
19:06 <@ulm> I still think that we shouldn't deprecate EAPI 5 for profiles
19:06 <@ulm> _all_ profiles are at EAPI 5
19:06 <@WilliamH> ulm: we can probably migrate profiles to eapi 6?
19:06 <@ulm> why?
19:06 <@WilliamH> How long has eapi 6 been stable?
19:07 <@ulm> EAPI 6 has not a single feature that would be useful for profiles
19:07  * dilfridge here
19:07 <@dilfridge> sorry, EBEERGARDEN
19:07 <@K_F> dilfridge: happy birthday :)
19:07 <@dilfridge> thanks! :)
19:07 <@K_F> ulm: I agree, lets limit discussion to ebuilds, not profiles
19:07 <@K_F> we already did that last meeting
19:07 <@WilliamH> ulm: whether it has a useful feature for profiles or not isn't relevant. Does it break profiles to migrate them to eapi 6?
19:07 <@tamiko> dilfridge: Happy birthday!
19:08 <@slyfox> AFAIU mechanically this change does not enforce anything yet
19:08 <@slyfox> what will soon be enforced is addition of new ebuilds
19:08 <@ulm> WilliamH: there is no reason for bumping them to 6
19:08 <@dilfridge> tamiko: thank you
19:08 <@ulm> it would only introduce more complexity
19:08 <@K_F> WilliamH: bumping can only be negative, there is no need to bump, and it can only reduce backwards compat
19:08 <@slyfox> bug #655118
19:08 <+willikins> https://bugs.gentoo.org/655118 "repoman should reject attemt to commit fresh ebuilds with deprecated EAPIs (changing existing should be fine)"; Portage Development, Repoman; CONF; slyfox:dev-portage
19:09 <@dilfridge> WilliamH: 1) there is no technical need to bump to 6, since it introduces no changes for profiles
19:09 <@dilfridge> 2) however, having a portage too old for your profiles is about the worst failure mode imaginable,
19:09 <@ulm> eapis-deprecated in layout.conf doesn't affect profiles, I think?
19:09 <@slyfox> deprecation does not mean removal, but addition of new
19:09 <@dilfridge> which is an argument against just bumping everything from 5 to 6
19:10 <@K_F> lets limit it to new ebuilds
19:10 <@K_F> and for that matter, its a deprecation, so revbumps etc are still OK anyways for existing packages
19:10 <@WilliamH> ulm: I think you are right about layout.conf.
19:11 <@K_F> deprecation != banned
19:11 <@slyfox> How about "Deprecate EAPI=5 for new ebuilds: discourage addition of new ebuilds. Keep profiles at EAPI=5 including new profiles"?
19:11 <@ulm> slyfox: wfm
19:11 <@WilliamH> slyfox: Isn't that what layout.conf does?
19:12 <@slyfox> WilliamH: i think it's exactly what it does, yes
19:12 <@K_F> slyfox: I wonder if "discourage addition of new ebuilds" shouldn't be "new packages using EAPI=5"
19:12 <@WilliamH> K_F: same thing.
19:12 <@K_F> but it follows from EAPI=5 being deprecated to begin with, so somewhat redundant
19:12 <@WilliamH> K_F: a new ebuild always happens for a new package.
19:12 <@K_F> WilliamH: not for revbumps and new versions of existing packages
19:12 <@dilfridge> as it's only "discourage", new ebuilds should be fine (it's not that hard to port 5 -> 6)
19:12 <@K_F> WilliamH: no, it doesn't
19:13 <@WilliamH> K_F: so you can add a new package without a new ebuild?
19:13 <@slyfox> I would suggest steering people to bump to new EAPI even for revbumps unless it's burdensome
19:13 <@K_F> WilliamH: thats not the same the other way around
19:13 <@WilliamH> slyfox++
19:13 <@ulm> WilliamH: in theory you can have an empty package :)
19:13 <@dilfridge> slyfox++
19:14 <@ulm> it's sort of useless :)
19:14 <@K_F> slyfox: right, but deprecation doesn't mean that should be enforced
19:14 <@K_F> we've had some poor history of people forcing EAPI bumps in g-p-m etc
19:14 <@slyfox> you mean you propose repoman should not fail by default?
19:15 <@K_F> warning at most
19:15 <@WilliamH> K_F--
19:15 <@ulm> it outputs a warning for eapis-deprecated
19:15 <@slyfox> the problem with warning is there is no difference between new and existing packages
19:15 <@K_F> ulm: right, which makes sense
19:16 <@slyfox> (unless you are talking about a warning at commit time and commit time only)
19:16 <@K_F> slyfox: for a deprecated entity, it doesn't really matter, its not banned
19:16 <@K_F> you get the warning, you're told to expect suppor to be removed at some point
19:16 <@mgorny> i'm sorry, guys, i'm not feeling well today
19:16 <@K_F> but yes, I'm talking about warning at repoman run locally
19:17 <@ulm> we had that whole procedure several times, when deprecating EAPIs 0 to 4
19:17 <@slyfox> it means repoman would need 3 modes then: banned (existing), ~banned for new ebuilds (new, does not exist), deprecated (esists)
19:17 <@ulm> so why do we have to discuss it yet again?
19:17 <@tamiko> I have no idea.
19:17 <@K_F> ulm: right, I believe I'm stating the current deprecated mode
19:17 <@WilliamH> so let's just do it ;-)
19:17 <@tamiko> Seriously, this is quite advanced bikeshedding we're doing here.
19:17 <@mgorny> for the record, the item was about deprecating it for packages, not profiles
19:17 <@K_F> but people need to realize deprecated != banned
19:18 <@K_F> because there have been events in the past where that seems confusing
19:18 <@K_F> but deprecate EAPI=5 for ebuilds, no problem..
19:19 <@slyfox> How do you propose to amend existing wording: "Deprecate EAPI=5 for new ebuilds: discourage addition of new ebuilds. Keep profiles at EAPI=5 including new profiles"?
19:19 <@dilfridge> seriously, I dont think this is important enough for a long discussion
19:19 <@ulm> K_F: we can point them at https://www.merriam-webster.com/dictionary/deprecate
19:19 <@dilfridge> slyfox++
19:19 <@K_F> slyfox: don't even have to specify it more than "EAPI=5 is deprecated for ebuilds"
19:20 <@dilfridge> we do manage to migrate off old ebuilds, and "malicious old-eapi commits" are definitely not the problem there
19:20 <@dilfridge> s/old ebuilds/old eapis/
19:20 <@slyfox> Allring then if everyone on the same page i suggest voting on "Deprecate EAPI=5 for new ebuilds"
19:20  * WilliamH yes
19:20  * dilfridge yes
19:20  * K_F yes
19:20  * tamiko yes
19:20  * slyfox yes
19:20  * mgorny yes
19:21  * ulm yes (with the understanding that it doesn't affect profiles)
19:21 <@slyfox> *nod*. It does not. I'll explicitly state it in summary
19:21 <@ulm> +1
19:21 <@tamiko> FInally!
19:21 <@slyfox> Moving on to next topic:
19:21 <@slyfox> 3. Remove hppa@ support (or move to experimental) from Gentoo by zlogene@
19:21 <@slyfox>     https://archives.gentoo.org/gentoo-project/message/e55ca6dd7eb1f951e8845fdb13e8839d
19:21 <@slyfox>     https://bugs.gentoo.org/629554
19:21 <@tamiko> It's dead Jim, it's dead.
19:22 <@mgorny> apparently hppa already did it, so i don't think there's anything for us to do here
19:22 <@dilfridge> damn, i'm a doctor, jim, not a pa-risc archaeologist!
19:22  * WilliamH votes for wholesale removal
19:22 <@slyfox> Over the week i've already downgraded hppa@ to exp prifiles: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0dbb698b2a25aa175868a2d33fe6c9cd39c740ae
19:22 <@WilliamH> It is a completely dead arch
19:22 <@K_F> mgorny: I'd tend to agree, moving to exp is right thing to do.. it might've been done in a rushed way by the arch without proper announcement...
19:22 <@K_F> but there is nothing more for us to do
19:22 <@dilfridge> well, we can't really complain if the arch team does it itself
19:22 <@K_F> exept maybe setting up a policy for removing stable arches in general
19:22 <@slyfox> WilliamH: 1. toolchain works (including new release), 2. gentoo has a machines capable of building .sios
19:22 <@ulm> is it known if hppa still has users?
19:23 <@slyfox> hppa still has uses on @gentoo-hppa
19:23 <@slyfox> on #gentoo-hppa
19:23 <@dilfridge> ulm: maybe 2 or 3
19:23 <@ulm> k
19:23 <@WilliamH> Isn't that support completely gone in other linuxes now?
19:23 <@dilfridge> WilliamH: does that matter?
19:23 <@dilfridge> because if it's gone they will all come to us :)
19:24 <@WilliamH> dilfridge: I heard some talk about the kernel even removing hppa support
19:24 <@mgorny> let me put it like this: if there are people who want to support hppa, i see no reason to block them from supporting it
19:24 <@K_F> WilliamH: then lets discuss it if kernel removes support
19:24 <@dilfridge> well, when kernel and glibc remove hppa support, it's probably time for us too
19:24 <@mgorny> as long as it doesn't cause others harm, i see no reason to remove it
19:24 <@K_F> before that, arch has moved it to exp. thats fine, nothing for us to do
19:24 <@dilfridge> update bugzilla arch list
19:24 <@dilfridge> mgorny: ^
19:24 <@slyfox> ok, let's move on to next topic
19:24 <@mgorny> dilfridge: will do
19:24 <@dilfridge> ++
19:24 <@K_F> mgorny: thanks
19:25 <@WilliamH> Yeah, we can't  complain about what the arch team does
19:25 <@slyfox> 4. Open bugs with council involvement
19:25 <@slyfox>     https://wiki.gentoo.org/wiki/Project:Council#Open_bugs_with_Council_participation
19:25 <@slyfox> https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&email2=council%40gentoo.org&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype2=substring&list_id=3932450&query_format=advanced
19:25 <@slyfox> 637328 Document GLEP Cha security@gentoo.org IN_P --- GLEP 14 needs to be updated 
19:25 <@K_F> right, we've been prioritizing other things, but that is still ongoing
19:26 <@slyfox> *nod*. please post it to bug as well
19:26 <@slyfox> 642072 Gentoo C unspecif council@gentoo.org CONF --- Joint venture to deal with copyright issues 
19:26 <@slyfox> Subject for this meeting or no?
19:26 <@mgorny> we're moving forward on it
19:26 <@mgorny> ulm does a lot of owrk
19:27 <@ulm> mgorny: others too
19:27 <@ulm> but yeah, it's no actionable item for the council at this point
19:27 <@slyfox> will the final goal be to have something to proofread/agree/approve by council eventually?
19:28 <@slyfox> *nod*
19:28 <@ulm> not entirely clear yet
19:28 <@dilfridge> slyfox: for technical reasons your search skipped this one
19:28 <@dilfridge> 653304 	Communit 	User Rel 	comrel@gentoo.org 	UNCO 	--- 	Code of Conduct bans against general public restrict Free Speech
19:28 <@slyfox> hm
19:28 <@ulm> presumably, approval by both council and trustees
19:28 <@mgorny> how can it be a council bug if council members can't read it?
19:29 <@dilfridge> it's also council in cc (I just un-restricted it... wltjr filed it as a restricted bug, and immediately complained that it's restricted.)
19:29  * slyfox looks
19:29 <@tamiko> We vote on removing council?
19:29 <@slyfox> i can read the bug but i didn't see it a minute ago :)
19:29  * ulm proposes to close all bugs with "FREE SPEECH" in their summary as invalid
19:29 <@dilfridge> well, I'm fine with closing it RESOLVED BULL ...
19:30 <@K_F> it is a misunderstanding of freedom of speech and using gentoo as a platform
19:30 <@tamiko> Let's vote on closing as invalid.
19:30 <@tamiko> K_F++
19:30 <@K_F> but certainly nothing for council to get involved in
19:30 <@mgorny> rather for un-CC ing council, i guess
19:30 <@mgorny> there are also trustees there
19:30 <@slyfox> I suggest on unCC-ing council@ from bug and leave assignee to deal with the bug
19:30 <@dilfridge> slyfox: the search silently skips bugs that you dont have privileges for... only the council alias was in cc, but not the council members, which is kinda counterproductive in that case
19:31 <@K_F> dilfridge: well, aliases for any restricted bug is counterproductive..
19:31 <@dilfridge> yes
19:31 <@K_F> in any case, unCC council@
19:31 <@slyfox> ACK. doing
19:31 <@dilfridge> wfm
19:31 <@WilliamH> Free Speech really only applies to  the government.
19:31 <@WilliamH> I think (I'm no lawyer though).
19:32 <@slyfox> UN-CCed. Moving on
19:32 <@slyfox> 650964 Gentoo I Mailing infra-bugs@gentoo.org IN_P --- gentoo-dev ML: Implement council decision on user whitelisting 
19:32 <@slyfox> I guess this need a status update from infra@
19:32 <@K_F> I must say, I'm dissapointed it hasn't moved forward more quickly
19:33 <@K_F> as I understand it we have the technical implementation in place, it just hasn't been enabled
19:33 <@ulm> would be a good time for it now
19:33 <@tamiko> Should be close to being enabled.
19:33 <@ulm> because it's very quiet
19:33 <@slyfox> [ on the bright side there is a 2 weeks old update: https://bugs.gentoo.org/650964#c14 ]
19:34 <@K_F> I'd say we request infra implement it... again
19:34 <@slyfox> Asked for update: https://bugs.gentoo.org/650964#c15
19:35 <@K_F> any notification etc can be updated as we go
19:35 <@K_F> also, the initial list is already present in the bug for it
19:35 -!- antarus [~antarus@smtp.gentoo.org] has joined #gentoo-council
19:35 <@slyfox> \o/
19:36 <@K_F> but even without that it doesn't matter, as long as the whitelisting procedure is in place (which it is)
19:36 < antarus> I emailed you folks about a procedure and never heard back
19:36 <@tamiko> Did antarus get any answer to his e-mail from us? :-)
19:37 <@slyfox> The "[DRAFT] Gentoo-dev whitelisting"
19:37 <@slyfox> right?
19:37 <@tamiko> antarus: The e-mail was well worded. I think everyone here agrees that we can proceed with it. :-)
19:37 <@K_F> antarus: procedure is clear, git repo that people can add addresses to
19:38 < antarus> slyfox: ya
19:38 <@slyfox> So, should everyone take a few minutes to read Alec's proposal and agree on it right now or doing it offline? (but promise to do it today :)
19:38 <@tamiko> Right now.
19:39 <@dilfridge> the text is fine
19:39  * WilliamH is reading
19:39 <@mgorny> antarus: no reply = silent approval ;-)
19:39 <@mgorny> you didn't say you want a reply
19:40 <@mgorny> it sounded to me 'this is a draft, i'll do it in N days if nobody opposes'
19:40 <@tamiko> antarus: I guess your e-mail sounded a bit like that you gave a short grace period before proceeding for comments. Not that you wanted to have feedback :-)
19:40 <@K_F> we should include the archive URI for summary purposes in log
19:40 <@K_F> anyone have it handy?
19:41 <@slyfox> it was sent to infra@ and council@. I imagine those don't have an archive
19:41 <@K_F> ah, true
19:41 <@slyfox> Once antarus sends it to -dev@ it will be there
19:41 <@ulm> are we to approve only the text of the mail message, or the instructions on the wiki page too?
19:42 <@K_F> the wiki page is informational only, not something to approve
19:42 <@slyfox> I'd say only email wording
19:42 <@K_F> unless we have opinion on mass-changes like @debian.org
19:42 <@K_F> in all fairness, even the email wording isn't something for council to approve
19:42 <@K_F> that should be possible to modify as we go along without a big process
19:43 <@ulm> so just state that there is consensus?
19:43 <@ulm> without an explicit vote
19:43 <@K_F> that'd work
19:43 <@WilliamH> Seems reasonable to me.
19:43  * antarus isn't specifically looking for approval
19:43 <@slyfox> How about "Agree to 'Gentoo-dev whitelisting' plan"?
19:43 <@tamiko> :-)
19:43 < antarus> I just don't want to send an email that contradicts you
19:43 <@tamiko> Let's not vote a fourth time on that :-D
19:43 < antarus> that would look silly
19:44 <@K_F> the one thing I wonder about on the wiki page though is "Currently mail that is not via whitelisted posters goes to the mailing list moderators. It's their role to inform people how to get whitelisted. "
19:44 <@tamiko> antarus: On the contrary. E-mail is well worded.
19:44 <@K_F> it likely should just be rejected
19:44 <@slyfox> Allright. I assume there is no major objections. Let's move on to next item
19:44 <@tamiko> antarus: I think we do not want to specify "punitive actions", etc. Under the assumption that everyone behaves rational.
19:44 < antarus> well thats m ypoint right
19:45 <@K_F> tamiko: right, if someone misbehaves on that it is comrel territory
19:45 < antarus> the punishment for violation is nothing?
19:45 < antarus> but I digress ;)
19:45 <@K_F> antarus: no, it can go to comrel
19:45 <@slyfox> Next item
19:45 <@slyfox> 654262 Gentoo C unspecif council@gentoo.org IN_P --- EAPI 7 approval 
19:45 <@K_F> and result in punitive action against the dev approving
19:45 <@slyfox> This one is FYI, right? Already voted
19:45 < antarus> K_F: I aim for simplicity here, rejecting is too hard, so I'll only do it if the moderators receive a high volume of mail
19:45 <@ulm> I just kept this open so that it's on record
19:45 < antarus> (moderators == me)
19:45 <@slyfox> *nod*
19:45 <@ulm> slyfox: will close it now
19:46 <@slyfox> thank you!
19:46 <@slyfox> Next item
19:46 <@slyfox> 655118 Portage Repoman dev-portage@gentoo.org CONF --- repoman should reject attemt to commit fresh ebuilds with deprecated EAPIs (changing existing should be fine) 
19:46 <@K_F> this goes back to previous discussion, deprecated != banned
19:47 <@K_F> repoman should warn, as it does today, nothing more
19:47 <@mgorny> i think this is something for dev-portage to decide
19:47 <@tamiko> Jup.
19:47 <@mgorny> no reason for us to get involved at this point
19:47 <@tamiko> I don't think we have to micromanage everything :-)
19:47 <@mgorny> s/point/reason/
19:48 <@slyfox> allright. Un-CCing
19:48 <@mgorny> eh, i wrote 'reason' ;-D
19:48 <@K_F> well, the status of EAPIs in tree is council territory, not really PM specific
19:48 <@K_F> if anything it'd be a QA matter
19:48 <@slyfox> true
19:48 <@mgorny> council already decided on status of EAPIs
19:48 <@WilliamH> mgorny++
19:49 <@WilliamH> how portage or any other pm wants to handle that status is not our territory.
19:49 <@slyfox> *nod*. Moving on
19:49 <@slyfox> 5. Open floor
19:50 <@mgorny> ftr, i've pushed updated bugzilla template to the repo
19:50 <@K_F> mgorny: thanks
19:50 <@slyfox> Shentino: are you around? If you want to chat about games@ status
19:50 <@slyfox> (a bit sad you did get no response from games@)
19:52  * slyfox gives people 5 more minutes to come up with any topic before declaring victory
19:53 <@ulm> *yawn*
19:53 <@K_F> prometheanfire: seems to be missing a date in the email :)
19:57 <@slyfox> -ETIMEDOUT. I hereby declare meeting finished!