[21:02:15] <@mgorny> !proj council [21:02:16] (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] 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