path: root/meeting-logs/20220814.txt

2022-08-14 19:00:01	@gyakovlev	!proj council
2022-08-14 19:00:03	willikins	(council@gentoo.org) ajak, dilfridge, gyakovlev, mattst88, mgorny, sam, ulm
2022-08-14 19:00:12	@gyakovlev	and jsmolic as proxy
2022-08-14 19:00:15	@gyakovlev	meeting time!
2022-08-14 19:00:25	 *	ajak here
2022-08-14 19:00:28	 *	mattst88 here
2022-08-14 19:00:32	 *	jsmolic here
2022-08-14 19:00:39	 *	gyakovlev here
2022-08-14 19:01:02	 *	ulm here
2022-08-14 19:01:19	 *	mgorny here
2022-08-14 19:01:46	 *	gyakovlev pokes sam with a stick
2022-08-14 19:02:08	@ajak	he told me he might be a minute
2022-08-14 19:02:12	@ajak	struggling with heat
2022-08-14 19:03:13	@gyakovlev	I almos rushed my cat to vet today - she's been breathing really fast with open mouth and tried to sneak into the fridge.
2022-08-14 19:03:21	 *	sam_ here
2022-08-14 19:03:26	@gyakovlev	30c inside...
2022-08-14 19:03:36	@gyakovlev	ok everyone is here
2022-08-14 19:03:43	@gyakovlev	agenda for today:
2022-08-14 19:03:43	@gyakovlev	https://archives.gentoo.org/gentoo-project/message/77286085094c5f747b6fff164717e000
2022-08-14 19:04:04	@gyakovlev	1. Roll call just happened, everyone is here, jsmolic is proxy for dilfridge
2022-08-14 19:04:16	@gyakovlev	2. Change the status of GLEP 13 to moribund (ulm) [1]
2022-08-14 19:04:57	@ulm	rationale is in bug 853166
2022-08-14 19:04:57	willikins	https://bugs.gentoo.org/853166 "GLEP 13 is obsolete"; Documentation, GLEP Changes; CONF; ulm:glep
2022-08-14 19:05:13	@gyakovlev	GuideXML is long gone afaik
2022-08-14 19:05:15	@ajak	makes sense to me
2022-08-14 19:05:22	@sam_	i'm surprised we didn't do that long ago
2022-08-14 19:05:23	@ulm	also there's no Gentoo Documentation Project any more
2022-08-14 19:05:38	@mattst88	let's vote and move on?
2022-08-14 19:05:38	@ajak	yeah, 6 years of de facto uselessness is a long time :)
2022-08-14 19:05:45	+jsmolic	Yep, makes sense to remove outdated files
2022-08-14 19:06:05	@gyakovlev	ok let's vote, motion: Change the status of GLEP 13 to moribund
2022-08-14 19:06:07	 *	gyakovlev yes
2022-08-14 19:06:10	 *	ajak yes
2022-08-14 19:06:12	 *	mgorny yes
2022-08-14 19:06:12	 *	sam_ yes
2022-08-14 19:06:16	 *	mattst88 yes
2022-08-14 19:06:17	 *	jsmolic yes
2022-08-14 19:06:18	 *	ulm yes
2022-08-14 19:06:22	@ulm	thanks
2022-08-14 19:06:40	@gyakovlev	motion passes with all y votes
2022-08-14 19:06:53	@gyakovlev	next item (also ulm)
2022-08-14 19:06:53	@gyakovlev	Approval of GLEP 83
2022-08-14 19:07:09	@gyakovlev	https://archives.gentoo.org/gentoo-project/message/f7d00cf127ff8ca96aeaaf2ee209010c
2022-08-14 19:07:25	@gyakovlev	it's the eapi deprecation one
2022-08-14 19:07:51	@ulm	text of the draft: https://www.gentoo.org/glep/glep-0083.html
2022-08-14 19:08:18	@ulm	this tries to standardise the criteria we've been using
2022-08-14 19:08:30	@sam_	to me, there's nothing controversial about it at all, just codification, which is a great thing indeed
2022-08-14 19:08:57	@sam_	it's a nice step in moving away from unwritten rules and such
2022-08-14 19:08:58	@ulm	gives pretty similar times for EAPIs 4 and 5, for the ones before it's somewhat off
2022-08-14 19:09:08	@mgorny	and i don't think there were any negative replies to the final version
2022-08-14 19:09:21	@sam_	yep
2022-08-14 19:09:34	@gyakovlev	ok lets vote?
2022-08-14 19:09:37	@ulm	I'd suggest to label it as "active" immediately
2022-08-14 19:09:42	-->	jstein (~jstein@gentoo/developer/jstein) has joined #gentoo-council
2022-08-14 19:09:42	--	Mode #gentoo-council [+v jstein] by ChanServ
2022-08-14 19:09:55	@gyakovlev	motion: approve grep 83 and label it active immediately
2022-08-14 19:09:56	@ulm	because there's no implementation that we must wait for
2022-08-14 19:09:59	 *	mgorny yes
2022-08-14 19:10:03	 *	gyakovlev yes
2022-08-14 19:10:05	@sam_	yeah, i don't see the point in burdening us with another vote later
2022-08-14 19:10:06	 *	ajak yes
2022-08-14 19:10:06	 *	sam_ yes
2022-08-14 19:10:08	 *	jsmolic yes
2022-08-14 19:10:15	 *	mattst88 yes
2022-08-14 19:10:16	 *	ulm yes
2022-08-14 19:10:27	@mattst88	(how will we know when an EAPI becomes deprecated?)
2022-08-14 19:10:46	@mattst88	since it's 24-months after ... -- do we need some kind of calendar or reminder?
2022-08-14 19:11:08	@ulm	yeah, I'll see if I can come up with some tooling that will remind us :)
2022-08-14 19:11:13	@mattst88	sounds good
2022-08-14 19:11:18	@gyakovlev	sgtm too
2022-08-14 19:11:35	@gyakovlev	ok motion passed with all y votes
2022-08-14 19:11:42	@gyakovlev	moving to next item:
2022-08-14 19:11:42	@gyakovlev	Multilib implementation finalization
2022-08-14 19:11:59	@gyakovlev	not sure if soap is here or needed
2022-08-14 19:12:04	@gyakovlev	rationale is here:
2022-08-14 19:12:04	@gyakovlev	https://archives.gentoo.org/gentoo-project/message/f49bee8e7ff58f8d28cba5d659b55b88
2022-08-14 19:12:24	@sam_	he's travelling at the moment 
2022-08-14 19:12:39	@gyakovlev	ah yeah, remember he mentioned the flight
2022-08-14 19:13:09	@mattst88	I look at this as codifying what is already the case, and has been for a long time
2022-08-14 19:13:31	@sam_	mattst88 can probably speak best about his experience with some of the bugs being filed for multilib-portage
2022-08-14 19:13:31	@ulm	IMHO item 2 there is micro-management. we should leave it to the portage project
2022-08-14 19:13:41	@gyakovlev	ok, so do we need a discussion on it? 
2022-08-14 19:13:42	@gyakovlev	seems like sensible thing to do, should have been done long ago.
2022-08-14 19:13:42	@gyakovlev	to me it's more like just setting in stone current situation.
2022-08-14 19:13:44	+jsmolic	yeah, especially points 2 and 3
2022-08-14 19:13:49	@sam_	(as GNOME in particular gets badly affected because of the introspection stuff)
2022-08-14 19:14:21	@mattst88	yeah, I've seen a number of bugs filed by the author of portage-multilib where he hides the fact that the reported issue is only reproducible with portage-multilib
2022-08-14 19:14:38	@mattst88	and it's just a waste of people's time to try to help in this case
2022-08-14 19:15:01	@ulm	it's still actively maintained though? at least I see some commits from this year
2022-08-14 19:15:03	+ionen	I've gotten one for nvidia-drivers before and it wasn't fun to try that thing, currently it ignores abi_x86_* USE entirely so any ebuild checking those is broken by default
2022-08-14 19:15:08	@sam_	anyway, I think it's a good idea, and the status quo leads to confusion from both developers and users (I've seen users add the multilib overlay thinking it was necessary). there is no "debate" over a solution for multilib anymore and we've standardised on the approach in the eclass.
2022-08-14 19:15:34	@sam_	the bugs reported tend to be lacking in detail, there's no much documentation for multilib-portage, and in reality, it's not supported
2022-08-14 19:15:37	@mgorny	i don't mind people working on their custom solutions but i really dislike the fact that they are deliberately causing confusion
2022-08-14 19:15:42	@gyakovlev	ulm: maintained or not, it has exactly 1 user.
2022-08-14 19:15:48	@mattst88	ulm: dunno, I think the point is really that even if it's getting commits, it's just by one person who has been doing it by himself for 10 years
2022-08-14 19:15:50	@gyakovlev	nobody is going to test or validate it
2022-08-14 19:16:00	@sam_	fwiw I actually tried it out a few months ago and I had to scavenge for distfiles as a bunch of the SRC_URIs in the overlay were gone
2022-08-14 19:16:06	@sam_	i really doubt anyone is using it apart from tommy
2022-08-14 19:16:12	+jsmolic	it seems to be a one-man project really, yes
2022-08-14 19:16:48	@sam_	does anyone have any concerns here?
2022-08-14 19:17:06	@gyakovlev	ok let's do itemized vote:
2022-08-14 19:17:06	@gyakovlev	1. Declare the current multilib solution (multilib-minimal.eclass,
2022-08-14 19:17:07	@gyakovlev	[${MULTILIB_USEDEP}] usedeps) the final _de facto_ and _de jure_
2022-08-14 19:17:07	@gyakovlev	approach Gentoo has chosen to take with respect to the multilib problem.
2022-08-14 19:17:14	@mattst88	(I'm happy to strip out #2 and let the portage project handle potentially removing the branch from portage.git)
2022-08-14 19:17:38	@gyakovlev	yeah ^ i thought the same.
2022-08-14 19:17:47	 *	ajak yes, though i think 1 probably naturally leads to 2
2022-08-14 19:18:04	@sam_	yeah, i don't really see the point in stripping it, 2 is just about making it explicit that it's okay to do so, but w/e
2022-08-14 19:18:30	@ulm	not sure if removing branches is good practice. retiring yes, but keep the history?
2022-08-14 19:18:43	@mattst88	yeah, true -- it's just asking for council's blessing. sam is right
2022-08-14 19:19:17	@gyakovlev	ok let's do the following vote
2022-08-14 19:19:17	@gyakovlev	Motion: Declare current multilib solution (multilib-minimal.eclass) final, maintainers are free to close  alternative implementation bugs as INVALID, WONTFIX etc.
2022-08-14 19:19:17	+jsmolic	I think point 2 seems okay, to get the approval, and Portage team can choose how to handle it in way they think is best
2022-08-14 19:19:28	 *	gyakovlev yes
2022-08-14 19:19:33	 *	mgorny yes
2022-08-14 19:19:40	@ajak	ulm: i think the issue is that it's really independent from portage (ie, never going to be merged) and as such doesn't belong in portage.git
2022-08-14 19:19:41	 *	ajak yes
2022-08-14 19:19:42	 *	ulm yes
2022-08-14 19:19:44	@mattst88	ulm: I think the real objective is to make it crystal clear that the multulib branch is not an official project, and removing it from the official portage.git sends that message
2022-08-14 19:19:53	 *	jsmolic yes
2022-08-14 19:19:53	 *	mattst88 yes
2022-08-14 19:20:08	@ajak	so, surely the parties that care about it can continue it elsewhere than portage.git
2022-08-14 19:20:20	@ulm	ajak: mattst88: ok, I hadn't looked at it from that perspective
2022-08-14 19:20:23	+jsmolic	yes, having the branch in portage.git might look confusing
2022-08-14 19:20:24	@ajak	there's just no need for it to be under the portage project's resources
2022-08-14 19:20:27	@gyakovlev	sam_ ? vote?
2022-08-14 19:20:30	 *	sam_ yes
2022-08-14 19:20:53	@gyakovlev	ok motion passes.
2022-08-14 19:20:53	@gyakovlev	we just ask portage team handle the branch handling
2022-08-14 19:21:25	@gyakovlev	moving on
2022-08-14 19:21:29	@gyakovlev	5. Approve draft of GLEP 78 (Sheng Yu, mgorny)
2022-08-14 19:21:36	@gyakovlev	it's the binpkg format glep
2022-08-14 19:21:51	@gyakovlev	https://gitweb.gentoo.org/data/glep.git/tree/glep-0078.rst
2022-08-14 19:22:14	@mgorny	Sheng Yu has been doing great work there, and i basically don't have anything to add
2022-08-14 19:22:21	@mgorny	he has figured out stuff that didn't even occur to me
2022-08-14 19:22:51	@sam_	portage-3.0.31+ implements this and we've had no real bugs either
2022-08-14 19:22:59	@mattst88	awesome, I'm really excited to see this
2022-08-14 19:23:00	@gyakovlev	Zac is aware of this too right?
2022-08-14 19:23:21	@sam_	https://github.com/gentoo/portage/blob/master/NEWS#L157
2022-08-14 19:23:24	+ionen	been using it for some time myself too, good stuff
2022-08-14 19:23:57	@sam_	gyakovlev: yeah, the PR was open for a very long time, and he'd commented on it quite a bit
2022-08-14 19:24:12	@sam_	but I've been handling recent releases as he's busy right now 
2022-08-14 19:24:28	@gyakovlev	ok let's vote I guess.
2022-08-14 19:24:28	@gyakovlev	motion: Approve draft of GLEP 78
2022-08-14 19:24:38	 *	mattst88 yes
2022-08-14 19:24:39	 *	ajak yes
2022-08-14 19:24:39	 *	sam_ yes
2022-08-14 19:24:40	 *	jsmolic yes
2022-08-14 19:24:42	 *	gyakovlev yes
2022-08-14 19:24:46	 *	mgorny yes
2022-08-14 19:24:50	 *	ulm yes
2022-08-14 19:25:04	@gyakovlev	passed with all y votes, thanks!
2022-08-14 19:25:40	@gyakovlev	next item is a bit poorly worded, but let's start a discussion and re-phrase if required
2022-08-14 19:25:41	@gyakovlev	6. Request a status update along with complete information about the
2022-08-14 19:25:41	@gyakovlev	current options from the Foundation regarding umbrella options.
2022-08-14 19:25:41	@gyakovlev	Make a decision on which of these options to follow. (mgorny) [6]
2022-08-14 19:26:01	@sam_	NeddySeagoon made a comment on the ML about this: https://archives.gentoo.org/gentoo-project/message/a6f135659f592c05b85e55eaac4d31d6
2022-08-14 19:26:08	@sam_	I don't think any of us were planning on an actual decision based on the options today though
2022-08-14 19:26:19	@sam_	it's more that we should make a decision based on the info when we get it
2022-08-14 19:26:22	@gyakovlev	yeah it was clear to me it's just an action starter, not finalizer
2022-08-14 19:26:26	 *	sam_ nods
2022-08-14 19:26:28	@ajak	yeah, just trying to see where the ball has rolled so far
2022-08-14 19:26:39	@mgorny	yes, it's just about asking foundation for the options officially
2022-08-14 19:27:15	@mattst88	I don't even know what happened with the foundation election
2022-08-14 19:27:25	@mattst88	i.e., who are the current trustees
2022-08-14 19:27:43	@ajak	current trustees appoint new ones at agm, i think?
2022-08-14 19:27:43	@sam_	very healthy situation for sure
2022-08-14 19:28:00	@sam_	suffice to say I'm very happy with us moving forward on requesting this info
2022-08-14 19:28:05	@mgorny	trustees stay the same until the AGM
2022-08-14 19:28:08	@mattst88	but yes, let's please get the info we want and try to put this thing to bed
2022-08-14 19:28:29	@ajak	according to neddy in -trustees, deadline for agm is 2022-09-23
2022-08-14 19:28:38	@gyakovlev	I'm stuggling to re-phrase it into actionable item. help?
2022-08-14 19:29:02	@sam_	change last sentence to "Once that information is received, council should make a..."
2022-08-14 19:29:28	@gyakovlev	let's just drop last part and make it an action item later?
2022-08-14 19:29:31	@sam_	sure
2022-08-14 19:29:34	@mattst88	"Council requests a status update from the Foundation regarding umbrella organizations."
2022-08-14 19:29:38	@sam_	even better :)
2022-08-14 19:30:41	@gyakovlev	so we are voting for us to ask? =)
2022-08-14 19:30:50	@mattst88	sure, let's just vote
2022-08-14 19:30:54	@gyakovlev	motion:  Council to  request a status update from the Foundation regarding umbrella organizations
2022-08-14 19:30:56	@mattst88	seems quickest
2022-08-14 19:31:01	 *	mattst88 yes
2022-08-14 19:31:02	 *	gyakovlev yes
2022-08-14 19:31:03	 *	jsmolic yes
2022-08-14 19:31:08	 *	ajak yes
2022-08-14 19:31:14	 *	mgorny yes
2022-08-14 19:31:30	 *	ulm yes
2022-08-14 19:31:40	 *	sam_ yes
2022-08-14 19:31:43	@mgorny	hmm, though perhaps we should make it clear that we're requesting complete details
2022-08-14 19:31:47	@sam_	i think they know
2022-08-14 19:31:51	@gyakovlev	passed.
2022-08-14 19:31:51	@sam_	if we don't get it, we can shout
2022-08-14 19:31:51	@gyakovlev	who's going to take the ball? =)
2022-08-14 19:31:52	@mgorny	not just something like "nothing new"
2022-08-14 19:32:11	@gyakovlev	passed with all y votes (for log)
2022-08-14 19:33:02	@mattst88	I've gotta run now (moving house, and the wife is waiting for my help to move furniture)
2022-08-14 19:33:06	@gyakovlev	I saw antarus's comments earlier, so believe foundation is aware indeed.
2022-08-14 19:33:06	@gyakovlev	but I guess we need papertrail email inquiry
2022-08-14 19:34:18	@gyakovlev	ok let's move to next item 
2022-08-14 19:34:18	@gyakovlev	bugs with council invovement
2022-08-14 19:34:23	@gyakovlev	!bug 835152
2022-08-14 19:34:24	willikins	gyakovlev: https://bugs.gentoo.org/835152 "Mirror pkgcore/* repos from github"; Gentoo Infrastructure, Git; CONF; sam:infra-bugs
2022-08-14 19:35:05	@sam_	arthurzam: what should we do there?
2022-08-14 19:35:08	@gyakovlev	sam_ arthurzam any news here?
2022-08-14 19:35:18	@gyakovlev	this is just mirror to infra right?
2022-08-14 19:35:20	@sam_	yeah
2022-08-14 19:35:24	+arthurzam	Done on gitlab.g.o
2022-08-14 19:35:31	@sam_	ok i think that's good enough for now
2022-08-14 19:36:14	@gyakovlev	ok thanks, progress happening, good enough
2022-08-14 19:36:16	+arthurzam	Maybe I will move it to gitweb from gitlab and then push to github & gitlab - didn't decide yet, but I think bug can be closed or removed from council?
2022-08-14 19:36:29	@gyakovlev	yeah I'll uncc council
2022-08-14 19:36:35	@gyakovlev	unless someone objects
2022-08-14 19:36:40	@gyakovlev	next bug:
2022-08-14 19:36:40	@gyakovlev	!bug 176186
2022-08-14 19:36:41	willikins	gyakovlev: https://bugs.gentoo.org/176186 "Gentoo projects file hosting"; Gentoo Infrastructure, Other; IN_P; dsd:infra-bugs
2022-08-14 19:36:43	@sam_	fine with me
2022-08-14 19:37:17	@sam_	we're waiting for infra on that one but it's such a big issue that i feel like we should stay on it
2022-08-14 19:37:24	@sam_	it's a long-standing complaint 
2022-08-14 19:37:35	@gyakovlev	I'm not logged into bugzilla on this machine and main machine is still down... will uncc later then.
2022-08-14 19:37:45	@sam_	robin is away moving at the moment so nothing has happened there
2022-08-14 19:38:01	@gyakovlev	ok let's keep monitoring.
2022-08-14 19:38:23	@gyakovlev	that's all for bugs
2022-08-14 19:38:32	@gyakovlev	__Open floor__
2022-08-14 19:38:53	@sam_	nothing from me
2022-08-14 19:39:16	@sam_	I want to pursue some eclassy analogue to the GLEP 83 stuff we approved earlier but I have nothing to show right now
2022-08-14 19:40:26	@gyakovlev	I guess nothing else will come up today. let's call it a day then.
2022-08-14 19:40:44	 *	gyakovlev bangs the gong
2022-08-14 19:40:45	@gyakovlev	meeting closed