summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--meeting-logs/20220814.txt228
-rw-r--r--meeting-logs/20220814.txt.asc7
2 files changed, 235 insertions, 0 deletions
diff --git a/meeting-logs/20220814.txt b/meeting-logs/20220814.txt
new file mode 100644
index 0000000..5303ad3
--- /dev/null
+++ b/meeting-logs/20220814.txt
@@ -0,0 +1,228 @@
+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
diff --git a/meeting-logs/20220814.txt.asc b/meeting-logs/20220814.txt.asc
new file mode 100644
index 0000000..3f31a75
--- /dev/null
+++ b/meeting-logs/20220814.txt.asc
@@ -0,0 +1,7 @@
+-----BEGIN PGP SIGNATURE-----
+
+iHUEABYKAB0WIQQyG9yfCrmO0LPSdG2gXq2+aa/JtQUCYxeKpgAKCRCgXq2+aa/J
+tUbYAP41mstrfF2jlaYsvlAw0Np8sfC7zOXEKBDhdraeb/I3OgD/Q2YGqkwsetaC
+YP1TsZk9CyKILQJPqPgECAP9veDUNQI=
+=buLt
+-----END PGP SIGNATURE-----