summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMichał Górny <mgorny@gentoo.org>2023-06-12 11:39:00 +0200
committerMichał Górny <mgorny@gentoo.org>2023-06-12 11:39:00 +0200
commitb5228dbf90795a4688ee0c992a121bb21a759919 (patch)
tree496d23af8f8d2f1a42fd41b501ce787851db0e1d
parentadd summary for 20230409 meeting (diff)
downloadcouncil-b5228dbf90795a4688ee0c992a121bb21a759919.tar.gz
council-b5228dbf90795a4688ee0c992a121bb21a759919.tar.bz2
council-b5228dbf90795a4688ee0c992a121bb21a759919.zip
Add 20230514 and 20230611 logs
Signed-off-by: Michał Górny <mgorny@gentoo.org>
-rw-r--r--meeting-logs/20230514.txt97
-rw-r--r--meeting-logs/20230514.txt.asc11
-rw-r--r--meeting-logs/20230611.txt135
-rw-r--r--meeting-logs/20230611.txt.asc11
4 files changed, 254 insertions, 0 deletions
diff --git a/meeting-logs/20230514.txt b/meeting-logs/20230514.txt
new file mode 100644
index 0000000..78c6261
--- /dev/null
+++ b/meeting-logs/20230514.txt
@@ -0,0 +1,97 @@
+[21:00:30] <@mgorny> DING DING DING!
+[21:00:32] <@mgorny> !proj council
+[21:00:34] <willikins> (council@gentoo.org) ajak, dilfridge, gyakovlev, mattst88, mgorny, sam, ulm
+[21:00:46] <@sam_> feels rough to be the only person without their dev name as a nick..
+[21:00:49] <@mgorny> it's time for our 237th meeting (according to /topic, didn't verify)
+[21:01:10] <@mgorny> agenda: https://marc.info/?l=gentoo-project&m=168403323301173&w=2
+[21:01:16] <@mgorny> 1. Roll call
+[21:01:18] -*- ajak here
+[21:01:20] -*- arthurzam here (as proxy for mattst88)
+[21:01:23] -*- mgorny here
+[21:01:25] -*- gyakovlev here
+[21:01:26] -*- ulm here
+[21:01:39] -*- dilfridge here
+[21:01:41] -*- sam_ here
+[21:01:48] <@mgorny> thanks
+[21:01:59] <@mgorny> 2. Mark GLEP 78 as final [1,2]
+[21:02:05] <@mgorny> [2] https://gitweb.gentoo.org/data/glep.git/log/?h=glep78
+[21:02:05] <@mgorny> [3] https://marc.info/?l=gentoo-project&m=168396622312449&w=2
+[21:02:30] <@mgorny> long story short, we have the spec implemented thanks to Sheng Yu
+[21:02:40] <@ajak> mispaste i think
+[21:02:54] <@mgorny> oops
+[21:03:06] <@mgorny> [1] https://bugs.gentoo.org/672672
+[21:03:06] <@mgorny> [2] https://gitweb.gentoo.org/data/glep.git/log/?h=glep78
+[21:03:07] <@mgorny> these two
+[21:03:32] <@mgorny> does anyone have any questions?
+[21:05:21] <@mgorny> ok, i guess not
+[21:05:34] <@mgorny> motion: Mark GLEP 78 as final
+[21:05:38] -*- ajak yes
+[21:05:41] -*- sam_ yes
+[21:05:43] -*- mgorny yes
+[21:05:43] -*- arthurzam yes
+[21:05:47] -*- ulm yes
+[21:05:49] -*- dilfridge yes
+[21:06:38] -*- gyakovlev yes
+[21:06:48] <@mgorny> thansk, passed unanimously
+[21:06:59] <@mgorny> 3. Undeprecated EGO_SUM [3,4]
+[21:07:03] <@mgorny> [3] https://marc.info/?l=gentoo-project&m=168396622312449&w=2
+[21:07:03] <@mgorny> [4] https://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg97310.html
+[21:07:32] <@sam_> I still don't feel it's appropriate for us to even be discussing this
+[21:07:41] <@sam_> there's no consensus and various concerns have not been addressed on the ML
+[21:07:47] -*- ajak nods
+[21:08:15] <+arthurzam> mattst88 have said the same
+[21:08:35] <@ulm> I'd also say it's not ready for a vote
+[21:08:58] <@gyakovlev> well, there has been lengthy discussion.
+[21:08:58] <@gyakovlev> I'm in favor of returning it, but with some limits set for per-manifest or per package directory or both.
+[21:08:58] <@gyakovlev> I even suggested specific numbers before, need to find them.
+[21:08:58] <@gyakovlev> but yeah it needs to be presented as actionable item.
+[21:09:09] <@ajak> by discussing it we'll be giving justification to the idea that anybody can bring up anything and have the council discuss it, great way to waste time by bureaucracy
+[21:09:57] <+arthurzam> I also want to note that various people have given quite good "middle" ground in multiple places (IRC, ML), but I'm not sure where have it been stuck?
+[21:10:03] <@sam_> right
+[21:10:05] <@mgorny> well, i think at least some of us have made good points on the ml and they haven't been addressed in any way
+[21:10:24] <@sam_> ulm probably put it best
+[21:10:26] <@sam_> and gyakovlev
+[21:10:31] <@sam_> it's not actionable as-is/not ready as a proposal
+[21:10:38] <@ajak> yes, let's move to kick it back to MLs?
+[21:10:44] <@sam_> that doesn't mean the topic isn't worth talking about in the dev community, but it needs to be kicked back i agree
+[21:11:09] <+arthurzam> I also want to note that I think the thing should be split into multiple parts, for example split ::gentoo from overlays and such...
+[21:11:09] <+arthurzam> Not one huge "action"
+[21:11:21] <+soap> (it doesnt apply to overlays anyways)
+[21:11:40] <@mgorny> also the maintainer should really take part in this
+[21:11:52] <@sam_> it doesn't appear flow is here right now either
+[21:11:55] <@sam_> mgorny: ok if we dismiss and move on?
+[21:11:59] <@gyakovlev> yeah per repo qa settings is a thing. ok enough discussion =) it has to be finalized on ML
+[21:12:06] <@mgorny> i don't think it's a good idea for Council to arbitrarily override how eclasses work without having anyone to maintain the resulting eclass
+[21:12:30] <@mgorny> ok then, back to the ml
+[21:12:32] <@mgorny> 4. Open bugs with Council participation [5]
+[21:13:00] <@mgorny> https://bugs.gentoo.org/520156
+[21:13:06] <@mgorny> Bug 520156 - Give the council authority to change GLEP 39 like any other GLEP
+[21:13:07] <willikins> mgorny: https://bugs.gentoo.org/520156 "Give the council authority to change GLEP 39 like any other GLEP"; Gentoo Council, unspecified; CONF; wking:council
+[21:13:21] <@ulm> this should be closed
+[21:13:30] <@mgorny> close WONTFIX per comment?
+[21:13:35] <@ajak> yes
+[21:13:38] <@ulm> I wanted to have it in the meeting log
+[21:13:57] <@mgorny> now you do ;-)
+[21:14:22] <@ulm> closed
+[21:14:24] <@mgorny> Bug 672672 - GLEP 78: Gentoo binpkg container format
+[21:14:25] <willikins> https://bugs.gentoo.org/672672 "GLEP 78: Gentoo binpkg container format"; Documentation, New GLEP submissions; IN_P; mgorny:glep
+[21:14:31] <@mgorny> we've just discussed this one
+[21:14:48] <@mgorny> ulm: will you push the GLEP update and close the bug afterwards?
+[21:14:54] <@ulm> just pushed it
+[21:15:03] <@ulm> refresh the bug :)
+[21:15:10] <@mgorny> Bug 883715 - (new) Developers who wish to stay anonymous
+[21:15:10] <willikins> mgorny: https://bugs.gentoo.org/883715 "(new) Developers who wish to stay anonymous"; Gentoo Council, unspecified; CONF; juippis:council
+[21:15:39] <@sam_> i don't know if i love this but i don't have a solid logical argument against it, in theory this is a recruitment policy thing, not a GLEP copyright policy thing in isolation
+[21:15:48] <@sam_> unfortunately the recruiters lead is AWOL and due to be retired soon enough
+[21:16:17] <@ajak> yeah, not sure what we'd do here
+[21:16:19] <@sam_> I don't think it's really for us yet, recruiters should get in order first
+[21:16:38] <@sam_> (with discussion on the ML, as well, given this affects everybody)
+[21:17:09] <@mgorny> does anyone want to write a comment to the bug or should i?
+[21:17:18] <@sam_> would you mind?
+[21:17:28] <@mgorny> i'll do it after closing the meeting
+[21:17:38] <@mgorny> 5. Open floor time
+[21:20:04] <@mgorny> anyone?
+[21:23:06] <+arthurzam> seems like no?
+[21:23:20] -*- ajak looks both ways
+[21:23:42] <@mgorny> ok, meeting adjourned!
+[21:23:45] <@mgorny> thanks, everyone
diff --git a/meeting-logs/20230514.txt.asc b/meeting-logs/20230514.txt.asc
new file mode 100644
index 0000000..56e2df5
--- /dev/null
+++ b/meeting-logs/20230514.txt.asc
@@ -0,0 +1,11 @@
+-----BEGIN PGP SIGNATURE-----
+
+iQFGBAABCAAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmSG5voSHG1nb3JueUBn
+ZW50b28ub3JnAAoJEGOa2uIyniQOPCsH/2eBNalvSeYetuSj1F3Ssh4CVA/ySlpX
+bNOxpGeu/+xOXzVDBc6XjhBV27stnNYfKLEgn8Yd3UlWLpjxSSoErKZwhlntXHgN
+m/TLME3dYVU5CYk64tlgCRLYsiZxNpJCH+UddygpiUV6LYlU1QVsffi7hYxZZ06t
+peYxpOnrgVUIAi8dt+FO9UO2G7HHlM2l/7l9bTD59gFF+PVlrqP+x78s0mi//LKx
+ES7T0uFvy9/6wfUoz7Yzn75rSQCsz+9xGTIYBX0A2QnT/WCeWmK16Vx/X2/vGbnM
+h03gKvz8CQq8Hh0ADxAqicozqnMuSlFSSFqdLDlvES0PfhnhM936oqQ=
+=nLt/
+-----END PGP SIGNATURE-----
diff --git a/meeting-logs/20230611.txt b/meeting-logs/20230611.txt
new file mode 100644
index 0000000..2190457
--- /dev/null
+++ b/meeting-logs/20230611.txt
@@ -0,0 +1,135 @@
+[21:02:15] <@mgorny> !proj council
+[21:02:16] <willikins> (council@gentoo.org) ajak, dilfridge, gyakovlev, mattst88, mgorny, sam, ulm
+[21:02:28] <@mattst88> o/
+[21:02:38] <@dilfridge|mobile> allo
+[21:02:49] <@mgorny> lemme just find the agenda link
+[21:02:53] -*- mgorny mumbles about archives.g.o
+[21:03:19] <@ulm> roll call, bugs, open floor
+[21:03:25] <@sam_> https://marc.info/?l=gentoo-project&m=168650241618329&w=2
+[21:03:34] <@mgorny> thanks
+[21:03:42] <@mgorny> i just wanted to have a link in the log ;-)
+[21:03:48] <@mgorny> 1. Roll call
+[21:03:50] -*- mgorny is here
+[21:03:52] -*- ajak here
+[21:03:52] -*- sam_ here
+[21:03:53] -*- mattst88 here
+[21:03:55] -*- ulm here
+[21:03:59] -*- dilfridge|mobile here
+[21:04:12] <@mattst88> gyakovlev is likely not here
+[21:04:34] <@mgorny> yeah, i don't think i've seen him around today
+[21:07:08] <@mgorny> ok, let's move on
+[21:07:12] <@mgorny> 2. Open bugs
+[21:07:26] <@mgorny> bug 883715
+[21:07:27] <willikins> mgorny: https://bugs.gentoo.org/883715 "(new) Developers who wish to stay anonymous"; Gentoo Council, unspecified; CONF; juippis:recruiters
+[21:07:41] <@mgorny> we reassigned it to Recruiters last
+[21:07:43] <@sam_> don't think I agree with the conclusion there
+[21:08:00] <@sam_> if it was worth asking trustees+council about it, as we said (+ you said in the comment), it's worth discussing on -project
+[21:08:10] <@sam_> us simply having no decision in a *meeting* doesn't mean it's not worth discussing
+[21:08:14] <@sam_> (at large)
+[21:08:21] <@sam_> so recruiters should really bring it up on -project
+[21:08:29] <@ulm> sorry, what was the conclusion there?
+[21:08:36] <@ajak> the last comment?
+[21:08:39] <@sam_> i'm referring to juippis' conclusion, sorry, yes
+[21:08:40] <@sam_> not ours
+[21:08:50] <@ulm> ajak: yes, what does it say?
+[21:09:03] <@sam_> "If trustees / council has no comments to the issues raised in #c0, then recruiters can continue as normal. In other words, no change needed for recruitment process."
+[21:09:11] <@ulm> yes, I can read :)
+[21:09:16] <@sam_> you asked what it said..
+[21:09:19] -*- ajak scratches head
+[21:09:20] <@ulm> but what does "normal" mean?
+[21:09:41] <@sam_> i think you could've just asked that if you wanted to know that, but it's also not something any of us know the answer to (we're not recruiters)
+[21:10:22] <@sam_> but my point was I disagree with the premise of the response there - council isn't special here, and it should be brought up and discussed with the developer community at large
+[21:11:58] <@mgorny> sam_: perhaps ask for clarification on the bug
+[21:12:05] -*- ulm just did
+[21:12:14] <@sam_> i felt your comment was clear enough, but i will do
+[21:12:27] <@mgorny> should we move on?
+[21:12:53] <@ulm> +1
+[21:12:55] <@sam_> i think so, i've commented as to my concern & ulm has as well
+[21:13:06] <@mgorny> ok
+[21:13:07] <@mgorny> 3. Open floor
+[21:13:16] <+arthurzam> I have https://wiki.gentoo.org/wiki/Project:Council#Arch-status_Reviews
+[21:13:24] <+arthurzam> (June meeting)
+[21:13:36] -*- mgorny gives the floor to arthurzam
+[21:14:14] <+arthurzam> So we are doing active work on destabalising a lot of packages that we thing are less important on 32 bit arches, for example sci-*/*
+[21:14:32] <@mattst88> ++
+[21:14:49] <+arthurzam> I don't think we want full x86 -> ~x86 (yet), but we want to decrease the total amount of packages
+[21:15:02] <+arthurzam> 32 bit is just too limiting and giving too much noise at this point
+[21:15:34] <@sam_> yeah, the general principle for me at least is that while i'm happy to look at bugs affecting real people, there's a lot of stuff which gained x86 for no reason and we end up wasting time on those
+[21:15:44] <@sam_> really need developers to stop adding it by default too
+[21:15:53] <@mattst88> sounds great to me
+[21:16:30] <+arthurzam> I don't think I have something more "action itemy" for Council, but we are cleaning up a lot for now
+[21:16:32] <@mgorny> honestly, i have mixed feelings about this
+[21:16:40] <@mgorny> i normally do not add ~x86 by default these days
+[21:16:50] <@mgorny> but this generally means i end up having to rekeyword stuff ~x86 ;-)
+[21:16:55] <@mgorny> (you know, python)
+[21:17:04] -*- ulm still does when the package is allarches
+[21:17:18] <@ulm> (add ~x86, that is
+[21:17:20] <@ulm> )
+[21:17:34] <@ajak> i think this is fine and not opposed to the idea of removing x86 where it matters less, lik ein sci
+[21:17:37] <+arthurzam> mgorny: you can continue with that, we don't last-rite x86 (yet)
+[21:17:41] <+ionen> adding by "default" still means needing to test it at least in a x86 chroot though, rekeyword requests do that for you fwiw
+[21:17:48] <@ajak> yes
+[21:18:16] <+arthurzam> mgorny: just try to consider (if time permits of course), maybe the rev-dep tree is small enough to just drop x86 there
+[21:18:19] <@ajak> i have seen at least one security bug blocked forever because of an x86 problem, until i dekeyworded it
+[21:18:23] <+ionen> have little doubt it got added a lot without any testing
+[21:18:27] <@ajak> (also was a sci package, iirc)
+[21:19:08] <+arthurzam> My main request for all devs, if you see a blocked bug because of 32 bit arches, and the rev-dep tree isn't too big, contact us so we all consider together the destable idea
+[21:19:43] <@ajak> i'm happy with this
+[21:19:55] <@ulm> does anyone run real x86 these days? or even a 32 bit kernel on amd64?
+[21:20:04] <@ulm> or is it just 32 bit userland?
+[21:20:13] <+ionen> I do have a vm with a 32bit kernel but that's about it
+[21:20:15] <+arthurzam> I know infra uses
+[21:20:22] <+ionen> heh :)
+[21:20:24] <@sam_> there's people who run it on older hw, although some (not all) of them have 64-bit capable CPUs
+[21:21:04] <+floppym> I saw a youtube video of someone installing Gentoo on a 486 around a year ago.
+[21:21:25] <@sam_> ultimately x86 isn't going to go away, it's just going to become more like ppc is
+[21:22:05] <+arthurzam> Yes, you get potential stable x86, with various packages from ~x86
+[21:23:20] <@sam_> all done?
+[21:23:34] <@mgorny> anything else for the open floor?
+[21:23:36] <+arthurzam> Me, yes, sorry for taking long
+[21:23:43] <+NeddySeagoon> Election timeline
+[21:23:47] <@sam_> you did nothing wrong, just wondering if there's anything more for us to discuss
+[21:24:03] <+NeddySeagoon> Election timeline ?
+[21:24:13] <@sam_> i'm fine with what you'd suggested earlier
+[21:24:16] <@sam_> restate it for the log purposes?
+[21:24:20] <+NeddySeagoon> OK
+[21:25:03] <+NeddySeagoon> nominations next weekend for two week, have a day or so off then voting a day or so later. Both for two weeks
+[21:25:12] <+NeddySeagoon> Results 16-Jul-23
+[21:25:46] <@ulm> hm, next meeting still by the old council then? would be on 2023-07-09
+[21:26:01] <@ajak> it would be, but our term expires with this meeting, right?
+[21:26:15] <+NeddySeagoon> ulm: It would be after the resuts are out
+[21:26:27] <@ulm> term expires when the new council constitutes itself, I think?
+[21:26:34] <@mgorny> NeddySeagoon: any reason not to start nominations tomorrow?
+[21:26:35] <@ulm> but maybe unwise to have such a meeting
+[21:26:53] <@ajak> right
+[21:27:08] <@ajak> i don't see why the new council's first meeting can't be the following sunday after results or so
+[21:27:21] <+NeddySeagoon> mgorny: We always have a period on notic but it need not be most of a week
+[21:27:23] <@ulm> that would be 2023-07-30
+[21:27:53] <@ajak> sure? it's still a july meeting, though a bit later than usual
+[21:28:04] <+NeddySeagoon> 23-JUl ?
+[21:28:17] <@ajak> yeah that sounds more right
+[21:28:29] <@ulm> or 23rd, yes
+[21:28:34] <@mgorny> well, the proposed dates wfm
+[21:28:45] <+NeddySeagoon> Results 16-Jul ... Meeting folloming Sunday
+[21:29:12] <@ajak> is this something worth properly voting on given it's a bit weird
+[21:29:34] <+NeddySeagoon> ulm: You have one of those calendars with 23 and 30 Jul in the same square :)
+[21:29:54] <@ulm> NeddySeagoon: something like that. I got confused there :)
+[21:30:14] <@ulm> ajak: the date of the meeting? I think we should leave it for the new council to decide
+[21:30:20] <+NeddySeagoon> ajak: Its caused by the election.
+[21:30:54] <@ajak> i know that
+[21:31:08] <@sam_> can discuss on ML if we're not sure of what to do here
+[21:31:12] <@ajak> yes that too
+[21:31:25] <@sam_> i think i'd find it easier to digest in an email format because lots of dates being thrown around
+[21:31:50] <+NeddySeagoon> sam_: I'll get the annouce out tonight
+[21:31:59] <@sam_> thank you!
+[21:32:16] <@ajak> yeah thank you for being on top of it
+[21:32:34] <+NeddySeagoon> I've not got anything else.
+[21:32:49] <@ulm> so we're sort of organised :p
+[21:32:59] <+NeddySeagoon> heh
+[21:33:08] <@ulm> NeddySeagoon: thanks for doing the work
+[21:34:43] <@mgorny> anything else for the open floor?
+[21:34:47] <@sam_> (yes, thank you)
+[21:36:40] <@mgorny> i guess not
+[21:36:43] <@mgorny> thanks, everyone!
+[21:36:46] <@ulm> mgorny: thank you for chairing
+[21:36:47] -*- mgorny bangs the gavel
diff --git a/meeting-logs/20230611.txt.asc b/meeting-logs/20230611.txt.asc
new file mode 100644
index 0000000..7bdea0f
--- /dev/null
+++ b/meeting-logs/20230611.txt.asc
@@ -0,0 +1,11 @@
+-----BEGIN PGP SIGNATURE-----
+
+iQFGBAABCAAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmSG5v8SHG1nb3JueUBn
+ZW50b28ub3JnAAoJEGOa2uIyniQOUt4H/39se0qCQsrfhdF/T/yQaTF4PUsq7gM5
+QC6p46Hv4617nss7eFBTBZK7j2kFGnTcKpA+qkLgNVbVZAcY7oPm9xQTdx2Qd5ke
+8zKQfep1Hxst1wqoZvTU0mAtUxh+u/xLnbP3zw9EOp3XsbDCIe9/6RU+IgGfIAtk
+TVxLd7Q3xYNXrxYN7RC6Xerd7OsIS0gFqzhjE6Cam8fIW2zmXmO95GYZZRLTfNUX
+u1AvfcEea+7LkpsxpqpMrxURkAyYC9oM910Lox5ZeC83vDVMdUr2hIeUjhS6pClP
+bdhpoXdqvAzJMOfqR9qf+baiWnAabkC0lcEXjqS+mq9UfztGWH+Mg40=
+=wKIU
+-----END PGP SIGNATURE-----