council/meeting-logs: add 20180513 logs summary

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

2 files changed, 295 insertions, 0 deletions

diff --git a/meeting-logs/20180513.txt b/meeting-logs/20180513.txt
new file mode 100644
index 0000000..a547a48
--- /dev/null
+++ b/meeting-logs/20180513.txt
@@ -0,0 +1,289 @@
+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!
diff --git a/meeting-logs/20180513.txt.asc b/meeting-logs/20180513.txt.asc
new file mode 100644
index 0000000..c7b3cb8
--- /dev/null
+++ b/meeting-logs/20180513.txt.asc
@@ -0,0 +1,6 @@
+-----BEGIN PGP SIGNATURE-----
+
+iF0EABECAB0WIQSZKa0VG5avZRlY01hxoe52YR/zqgUCWviU4gAKCRBxoe52YR/z
+qmw/AJ9d4XxjamYkjrzVRpmaaCa43q5nIACeJli7f2zacYU6IlHmuo0smD/Sw/o=
+=Ma+q
+-----END PGP SIGNATURE-----