path: root/meeting-logs/20230611.txt

[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