path: root/meeting-logs/20211114.txt

[20:05:51] <dilfridge> meeting starts
[20:05:56] <dilfridge> !proj council
[20:05:57] <willikins> (council@gentoo.org) dilfridge, gyakovlev, marecki, mattst88, mgorny, sam, ulm
[20:06:01] <dilfridge> roll call
[20:06:03] -*- gyakovlev here
[20:06:04] -*- ulm here
[20:06:05] -*- sam_ here
[20:06:06] -*- dilfridge here
[20:06:09] -*- mgorny here
[20:06:10] -*- Marecki still here
[20:06:29] -*- mattst88 here
[20:06:34] <dilfridge> excellent 
[20:06:36] <dilfridge> all here
[20:06:48] <dilfridge> https://archives.gentoo.org/gentoo-project/message/4102bb0a1037dea0c07f30bfc3116a3f
[20:06:50] <dilfridge> ^ agenda link
[20:07:03] <dilfridge> 2. Dropping hppa, ppc, sparc and x86 to ~arch-only status
[20:07:12] <dilfridge> https://archives.gentoo.org/gentoo-project/message/253dc6b0b980133305f8661d4093f664
[20:07:14] <dilfridge> ok
[20:07:27] <dilfridge> first, let's talk about this a bit
[20:07:36] <dilfridge> there have been a load of discussions in the meantime 
[20:07:38] <dilfridge> opinions?
[20:07:59] <mattst88> let's start with getting the rationale. what are we trying to accomplish?
[20:08:20] <dilfridge> I guess that part is clear, better response time overall and less load to developers
[20:08:41] <gyakovlev> well I can say for the record that situation improved  lately (2 week timeframe) a LOT for sparc and x86 at least
[20:08:55] <mgorny> i think the key point is that arch teams should be able to decide whether they want stable keywords for their arch or not
[20:09:01] <Marecki> Still not great for ppc and hppa, though.
[20:09:10] <mgorny> but at the same time they should be reasonably responsive and helpful
[20:09:13] <dilfridge> https://www.akhuettel.de/gentoo-bugs/arches.php
[20:09:19] <sam_> I was just getting the link :)
[20:09:27] <dilfridge> if I look at the bug number graphs, all arches are OK at the moment imho
[20:10:07] <dilfridge> someone even took mercy on ia64
[20:10:17] <sam_> does sometimes feel like we're a bit spoiled nowadays; things are in general much quicker overall. If a bug was filed 3 days ago and e.g. ppc is the only one left, that doesn't mean ppc is slow.
[20:10:42] <sam_> this is the sort of thing that, combined with mgorny's point, should be handled on a per-arch basis
[20:10:48] <mgorny> to put it the other way, i think we don't need to make a decision until we reach the point that developers are so frustrated they want to dekeyword stuff but they can't because of deep depgraphs
[20:10:51] <gyakovlev> yeah I've been thinking on ppc(32) and even considered it like a year ago.
[20:10:51] <gyakovlev> what baffles me about dropping it to ~ only are 2 things:
[20:10:51] <gyakovlev> 1) gentoo is one of really few distros still supporting it ( there's less than 5 overall probably with decent support)
[20:10:51] <gyakovlev> 2) moving it to ~ is a death sentence
[20:11:45] <mattst88> I've actually found dropping alpha to ~alpha to have not caused many problems. I was somewhat surprised
[20:12:26] <dilfridge> building stages for riscv (and alpha) is going relatively smooth... needs a bit more interventions than stable arches but not much
[20:12:44] <mgorny> tbh, the most frustrating arch team i've worked so far was x86
[20:12:51] <mgorny> but with jsmolic joining, i see light
[20:12:51] <mattst88> I think there are a *lot* of ppc keyworded packages that we can drop without anyone ever noticing -- ppc had a huge number of keywords dating from 2003~2006
[20:12:57] <sam_> the problem is with alpha I genuinely don't know of (m)any users, whereas there are ppc/x86 (and even kind of hppa) users out there
[20:13:02] <dilfridge> but on the whole that's probably more a plus for our general quality these days
[20:13:05] <sam_> not that I want alpha to go away, I just mean that I suspect the practical impact to people was low
[20:13:11] <Marecki> mattst88 dilfridge: That has been my impression too
[20:13:12] <mattst88> right
[20:13:20] <sam_> yeah, I agree on that wrt ppc
[20:13:23] <gyakovlev> mattst88: I think dropping some to ~ppc will help indeed
[20:13:25] <sam_> i think the workload for ppc is artifically high
[20:13:27] <gyakovlev> not all
[20:13:33] <mattst88> gyakovlev: I agree
[20:13:46] <mgorny> but that's not something that the Council needs to decide about, right?
[20:14:03] <sam_> i think it's ok for us to discuss general issues affecting gentoo and actually good, but that doesn't mean we have to actually make a decision
[20:14:10] <gyakovlev> mgorny: yeah we have powerpc team lead in progress
[20:14:19] <gyakovlev> as soon as lead is appointed we can handle it
[20:14:26] <mattst88> mgorny: I think Council only needs to step in here when there's a disagreement between two parties that cannot find an agreement
[20:14:31] <gyakovlev> team lead election/nomination I mean
[20:14:32] <mgorny> i'd say let's defer to next month, possible let people try dropping some packages to ~arch
[20:14:45] <sam_> fwiw, on x86, I suspect we could do a bit better here if we encouraged devs to NOT stable on x86 by default too
[20:14:47] <mgorny> and revisit if people still feel that we need to drop stable keywords entirely then
[20:14:57] <sam_> i.e. stop doing "amd64 and x86"
[20:15:00] <sam_> for new pkgs, etc
[20:15:12] <mgorny> fyi, i've removed the implicit ~x86 keyword on amd64 from gentoo-syntax
[20:15:16] <mgorny> but didn't make a release yet
[20:15:19] <ulm> sam_: from a multilib standpoint it makes sense for many packages
[20:15:38] <dilfridge> additional item, it's good if we have arch *teams*, i.e. more than one person taking care of stuff
[20:15:42] <sam_> ulm: oh because it is already tested you mean?
[20:15:44] <mgorny> ulm: for multilib packages, sure
[20:15:53] <mgorny> ulm: for non-multilib, they never got tested on x86
[20:15:55] <sam_> that said, multilib doesn't really make up the bulk of this
[20:15:57] <sam_> dilfridge: yes
[20:15:59] <ulm> sam_: if the 32bit variant is stable on amd64 then it can be stable on x86 too
[20:16:00] <mgorny> and even damn pure python packages fail on x86 sometimes
[20:16:05] <mattst88> FWIW: for hppa I'm working on having a system shipped from a former developer to OSUOSL that is probably 8x faster than what we've been using
[20:16:08] <sam_> dilfridge: so, let me ramble for a brief moment here
[20:16:44] <sam_> over the last 2-3 weeks, I've been helping jsmolic primarily to get up and running using my tooling
[20:16:57] <sam_> (he's also been helping with amd64 + x86, but that's orthogonal to my point for a moment)
[20:17:08] <sam_> as a result I've started documenting things to help others get started: https://wiki.gentoo.org/wiki/User:Sam/Arch_testing
[20:17:14] <dilfridge> very nice
[20:17:20] <sam_> I was also able to make a fair amount of improvements to my scripts: github.com/thesamesam/archtools
[20:17:33] <sam_> I hope to document more about known troublesome packages too
[20:17:41] <dilfridge> great
[20:17:58] <sam_> but yeah, I think it helps if people know they can actually: 1. get started (and how); 2. ... any dev can access to our devboxes
[20:18:01] <mattst88> thank you for doing that. that's great to see
[20:18:12] <dilfridge> I should also probably say, it would *also* be great if ago finally publishes his scripts, so we can review and maybe even contribute.
[20:18:33] <dilfridge> Not a mystery closed-source solution.
[20:18:36] <sam_> aye
[20:18:37] <Marecki> That's all well but I am a bit concerned that as soon as the "OMG they're trying to kill these arches must work MOAR" excitement has worn off stabilisation on the exotic arches will begin to lag again
[20:18:53] <dilfridge> well, we have a council meeting each month too
[20:19:06] <Marecki> Automation would indeed help
[20:19:17] <dilfridge> ok before we come to a vote, let's briefly review developer hardware for the mentioned arches
[20:19:29] <dilfridge> hppa, ppc, sparc and x86
[20:19:36] <sam_> back to wha mattst88 said re hppa. we recently got access to a much faster box for hppa from gmsoft and we're getting shipped another one. this is a lot better than the previous situation and it's now fast enough that I should be able to actually run my scripts on it at least.
[20:19:43] <dilfridge> hppa - mattst88 already mentioned he new box
[20:19:45] <gyakovlev> Marecki: yeah, discussion took place, people stepped up. so that's part of the whole dilemma.
[20:19:56] <sam_> os keep in mind that there's _two_ new HPPA boxes involved here, not just 1.
[20:19:56] <Marecki> dilfridge: True but I really don't think it's the Council's job to hold the sword of Damocles over the arch teams
[20:20:02] <gyakovlev> means people care
[20:20:06] <dilfridge> ppc ?
[20:20:25] <gyakovlev> we agreed to solve it in arch team, we have good box
[20:20:29] <dilfridge> pl
[20:20:30] <dilfridge> ok
[20:20:32] <sam_> ppc we have timberdoodle (a ppc64be host) which is pretty fast enough. bit busy nowadays but we could probably get more hardware if we needed it.
[20:20:32] <Marecki> Question: have we got ANY actual hppa users?
[20:20:38] <dilfridge> sparc ?
[20:20:40] <mattst88> timberdoodle is a power9 VM that we use for ppc/ppc64. it's fast.
[20:20:50] <mattst88> sparc has catbus, a 256-thread very fast system
[20:20:51] <mgorny> mattst88: i think Dakon mentioned he runs something in production
[20:20:52] <sam_> sparc we're well and good on, we have catbus which is ridiculously good frankly in terms of its speed
[20:21:04] <mattst88> mgorny: that's true
[20:21:10] <gyakovlev> sam_: btw we resources space for separate box I think
[20:21:11] <dilfridge> x86 ... well. fast machines are actually amd64.
[20:21:23] <sam_> i've had a few developers not realise that they can have access to e.g. catbus to test packages on sparc when a bug is reported
[20:21:34] <gyakovlev> I can make ppc32-only box to unload timberdoodle
[20:21:43] <sam_> gyakovlev: i think we might want to do that actually
[20:21:43] <mattst88> dilfridge: well, there's some disagreement (from Whissi) about that, but it's impossible to get Whissi communicate, so...
[20:21:59] <mgorny> in general, I've found Dakon to be willing and helpful regarding hppa/sparc
[20:22:00] <dilfridge> I know.
[20:22:07] <sam_> fwiw jsmolic has decided (after I explained the situation) to use a full x86 VM 
[20:22:21] <sam_> and he already found some time_t bugs ;)
[20:22:23] <dilfridge> which means you're testing the hypervisor :D
[20:22:26] <gyakovlev> sam_: it may be not as fat as timberdoodle, but I can cut a bit from bogsucker too, it's kinda idle-ish.
[20:22:38] <mgorny> sam_: so it requires a 32-bit kernel after all?
[20:22:55] <dilfridge> anyway
[20:23:09] <sam_> mgorny: i need to verify if i could hit the same bugs or if it was just chance, but possibly? it doesn't sound right to me either
[20:23:15] <dilfridge> so now I suggest we vote on Marecki's proposal per-arch.  or do we need further discussion?
[20:23:18] <sam_> maybe he's just doing more work and noticed problems which i didn't even get to
[20:24:10] <gyakovlev> I think we can monitor/postpone. do we need a vote? seems most arches have a solution or improvement planned or in progress
[20:24:19] <mattst88> I'm not in favor of forcing arches to drop keywords, at least at this point
[20:24:33] <dilfridge> well, voting no means not doing any action, so it's resolved fastest by voting
[20:24:37] <sam_> if it would make folks happier, we can revisit hppa in a few months after the kit is setup, but I genuinely don't think the situation is bad atm
[20:24:55] <mgorny> as i've said, i didn't really have any problems, except for x86
[20:24:57] <sam_> but I will poke at seeing if we can e.g. stable-mask problematic bits maybe a bit more aggressively on arches to limit the depgraph
[20:25:06] <mgorny> and python does stablereqs a lot
[20:25:08] <dilfridge> Motion: Dropping hppa, ppc, sparc and x86 to ~arch-only status. Vote per arch:
[20:25:11] <dilfridge> A) hppa
[20:25:16] -*- dilfridge no hppa
[20:25:21] -*- mattst88 no hppa
[20:25:24] -*- gyakovlev no hppa
[20:25:26] -*- mgorny no hppa
[20:25:33] -*- sam_ no hppa
[20:25:34] -*- ulm no hppa
[20:25:49] -*- Marecki yes hppa
[20:25:58] <dilfridge> that's 1 yes, 6 no, 0 abstentions
[20:26:01] <dilfridge> B) ppc
[20:26:04] -*- dilfridge no ppc
[20:26:05] -*- ulm no ppc
[20:26:07] -*- mattst88 no ppc
[20:26:08] -*- sam_ no ppc
[20:26:09] -*- mgorny no ppc
[20:26:09] -*- Marecki abstain
[20:26:18] -*- gyakovlev no ppc (will take action in arch team)
[20:26:21] <sam_> ^
[20:26:26] -*- ulm no sparc
[20:26:40] <dilfridge> that's 0 yes, 6 no, 1 abstention
[20:26:43] <dilfridge> c) sparc
[20:26:48] -*- dilfridge no sparc
[20:26:48] -*- mattst88 no sparc
[20:26:49] -*- gyakovlev no sparc
[20:26:50] -*- mgorny no sparc
[20:26:54] <Marecki> BTW. I think we need a motion on the Council having acknowledged both the problem and responses from respective arch teams, will monitor the situation and revisit the matter
[20:26:59] -*- sam_ no sparc
[20:27:00] -*- Marecki no sparc
[20:27:09] <gyakovlev> Marecki: agreed on that
[20:27:14] <sam_> yes
[20:27:15] <dilfridge> that's 0 yes, 7 no, 0 abstention
[20:27:19] <dilfridge> D) x86
[20:27:21] -*- ulm no x86
[20:27:23] -*- dilfridge x86 yes
[20:27:31] <Marecki> Someone needs to formulate it better though, my mind is a hash after 10 hours of driving today
[20:27:33] -*- mattst88 no x86
[20:27:34] -*- Marecki yes x86
[20:27:45] -*- sam_ no x86 but would like to revisit the situation if it remains problematic (ditto hppa)
[20:27:59] -*- gyakovlev no x86 (just because of multilib, but look at dropping some like ppc)
[20:28:05] -*- mgorny no x86
[20:28:15] <mattst88> sam_: I agree with that sentiment
[20:28:17] <dilfridge> that's 2 yes, 5 no, 0 abstentions
[20:28:21] <dilfridge> all motions not carried
[20:28:43] <mgorny> i think x86 should be put in the group of 'all 32-bit arches' if we ever decide on that
[20:28:45] <gyakovlev> let's do a monitor/re-assesment motion? or simply a bug will do
[20:28:52] <dilfridge> bug is fine, you file it :)
[20:28:56] <sam_> I don't mind having a bug to make sure this is on our agenda still
[20:28:58] <gyakovlev> k
[20:28:59] <sam_> I think we need to keep an eye on this
[20:29:00] <mgorny> much relevant if we finally get 64-bit time_t on 32-bit arches
[20:29:05] <sam_> mgorny: glibc-2.34 unlocks this
[20:29:11] <dilfridge> indeed
[20:29:16] <sam_> which is VERY important
[20:29:18] <ulm> go to x32 :)
[20:29:20] <dilfridge> (it's rekeyworded since last night)
[20:29:21] -*- ulm hides
[20:29:24] -*- sam_ hits ulm 
[20:29:31] <antarus> we have 2 x86 machines left; but we should migrate them
[20:29:41] <dilfridge> and with this we come to
[20:29:46] <antarus> one is a VM and one is probably older than some developers ;)
[20:29:49] <dilfridge> 3. Opening the range 60001..60999 (with possible later extension to higher IDs) for allocation of additional UIDs and GIDs [2]
[20:30:05] <ulm> well, 60000+ won't fly for now I think
[20:30:09] <dilfridge> I havent followed the full discussion there.
[20:30:12] <gyakovlev> seems there's has been a systemd problem
[20:30:16] <ulm> bug 823732, systemd issues
[20:30:17] <willikins> https://bugs.gentoo.org/823732 "sys-apps/systemd: UIDs and GID above 60000 are not usable for system accounts"; Gentoo Linux, Current packages; CONF; ulm:systemd
[20:30:22] <dilfridge> I guess the problem is that systemd defines a range as system accounts
[20:30:30] <mgorny> these issues don't seem a showstopper to me
[20:30:31] <-- jstein (~jstein@gentoo/developer/jstein) hat das Netzwerk verlassen (Ping timeout: 245 seconds)
[20:30:41] <mgorny> Debian uses 60000+ and doesn't even patch systemd
[20:30:53] <ulm> so the proposal is to open some IDs in the low range, like 500..749 with extension to 60000+ later
[20:31:00] <gyakovlev> maybe let's open up a ~100 in reserved range to unblock packages?
[20:31:06] <gyakovlev> ^ yeah
[20:31:09] <ulm> to give systemd folks some time to sort things out
[20:31:10] <mgorny> and a quick patch is literally a two line modification that we can carry for quite some time if necessary
[20:31:21] <dilfridge> what do we have, what do we need, where can we free ups space?
[20:31:35] <dilfridge> ulm: maybe explain please
[20:31:52] <ulm> we use 101..499 right now for static ids
[20:32:00] <ulm> and 500..999 for dynamic
[20:32:17] <dilfridge> "dynamic system accounts"?
[20:32:22] <ulm> so the proposal is to repurpose some part of the dynamic range
[20:32:35] <gyakovlev> how many user.eclass consumers are left there anyway?
[20:32:42] <ulm> ids allocated dynamically by user.eclass
[20:32:55] <ulm> and for use by system administrators
[20:33:09] <dilfridge> user.eclass is on the way out
[20:33:11] <ulm> so I'd leave at least 200 there
[20:33:28] <dilfridge> ok imho opening 500-749 makes sense then
[20:33:41] <ulm> and 749 instead of 799 so we get an early warning and still have 50 more
[20:34:05] <mattst88> gyakovlev: 456 according to
[20:34:06] <mgorny> the dynamic range is small already, i'm against taking up more of it because of temporary issues
[20:34:06] <mattst88> git grep -l 'inherit.*user' | cut -d / -f1-2 | sort -u | wc -l
[20:34:38] <mattst88> oh, but that's BS. sorry, sec.
[20:34:59] <dilfridge> https://qa-reports.gentoo.org/output/eapi-per-eclass/user.eclass/
[20:35:06] <mattst88> 45 according to
[20:35:07] <mattst88> git grep -l 'inherit.*user' | cut -d / -f1-2 | sort -u | grep -v acct- | grep -v eclass | wc -l
[20:35:07] <sam_> that's misleading (I just checked) becasue it counts acct-*
[20:35:27] <ulm> mgorny: my /etc/group is between 70 and 80 lines on my systems here
[20:35:40] <ulm> so I dare say 200 dynamic is enough
[20:36:15] <dilfridge> do we need to vote on this?
[20:36:21] <mgorny> if we open up 250 ids in the low range, we're going to revisit the same problem 250 ids from now
[20:36:43] <ulm> yes, but hopefully the systemd issue will be sorted out by then
[20:36:51] <dilfridge> mgorny: yes but until then we can discuss with systemd upstream about a second interval
[20:37:25] <ulm> I also want to contact debian, they're using 60000+ as well for packages
[20:37:45] <dilfridge> question, uid only or uid and gid?
[20:37:50] <dilfridge> both I guess
[20:37:53] <mgorny> both
[20:37:58] <dilfridge> ok
[20:37:58] <ulm> both of course
[20:38:32] <mgorny> just note that gid 60000+ range is one shorter than uid range because of nogroup
[20:38:43] <dilfridge> motion: uid and gid 500-749 are made available for allocation via acct-* as system accounts
[20:39:02] -*- ulm yes
[20:39:06] -*- mgorny no
[20:39:18] -*- Marecki seconds the motion
[20:39:28] <dilfridge> is that a yes?
[20:39:36] -*- Marecki yes
[20:39:41] -*- dilfridge yes
[20:39:46] -*- mattst88 yes
[20:40:20] <sam_> frankly I'm not sure and I think I'd prefer a smaller range for now while we speak to Debian and systemd
[20:40:38] <ulm> we'll start filling it from 500 upwards
[20:41:30] <sam_> i suppose that's okay then
[20:41:32] <dilfridge> I dont expect sudden huge demand
[20:41:38] <sam_> yeah, we've done the bulk of the migration
[20:41:46] -*- sam_ yes, although wants to keep an eye on the allocation as we go
[20:42:04] <dilfridge> gyakovlev: ?
[20:42:04] -*- gyakovlev abstain
[20:42:17] <dilfridge> ok that's 5 yes, 1 no, 1 abstain
[20:42:20] <dilfridge> motion carried
[20:42:30] <dilfridge> next: open bugs with council participation
[20:42:45] <dilfridge> bug 821553
[20:42:46] <willikins> dilfridge: https://bugs.gentoo.org/821553 "Document upgrade path policy"; Documentation, Devmanual; CONF; sam:devmanual
[20:42:49] <ulm> dilfridge: should we vote on further extension to 60001..60999?
[20:42:59] <ulm> or postpone that decision?
[20:43:14] <dilfridge> ulm: let's postpone that and wait what the powers-that-be say :P
[20:43:19] <ulm> k
[20:43:23] <sam_> agreed yeah
[20:43:32] <dilfridge> :P:
[20:43:49] <dilfridge> I dont really see anything actionable for us in that bug
[20:44:10] <dilfridge> mostly it's work documenting 
[20:44:20] <dilfridge> so, next
[20:44:21] <sam_> we probably want to talk about a formal policy on it
[20:44:23] <sam_> but that's better for a glep
[20:44:39] <dilfridge> I think the policy already exists from previous council decision
[20:45:16] <dilfridge> bug 786105
[20:45:17] <willikins> dilfridge: https://bugs.gentoo.org/786105 "access to manage projects on GH"; Gentoo Infrastructure, GitHub; CONF; vapier:github
[20:45:23] <sam_> so
[20:45:29] <sam_> a discussion on that was never opened on the ML
[20:45:36] <sam_> (after our last decision)
[20:45:43] <Marecki> Discussion hasn't happened, seems that even vapier is no longer interested.
[20:45:52] -*- dilfridge is all in favour of telling vapier to forget it 
[20:45:58] <mgorny> i suppose we should close i
[20:46:00] <mgorny> it*
[20:46:08] <dilfridge> anyone opposed?
[20:46:42] <sam_> i'd suggest we post on the bug a request from council for it to be discussed on the ML first
[20:46:48] <sam_> then if nothing happens by next meeting we close
[20:46:52] <mattst88> ++
[20:46:59] <dilfridge> that happened last month
[20:47:12] <Marecki> We did that last month. Enough is enough.
[20:47:12] <sam_> oh, I'm sorry, I'd missed we actually opsted on the bug
[20:47:16] <dilfridge>  Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2021-10-10 22:45:52 CEST
[20:47:16] <dilfridge> The Council has reached no conclusion during today's meeting and decided that the discussion needs to happen on mailing list first.
[20:47:19] <sam_> yes, yes
[20:47:30] <sam_> I'd missed mgorny had actually commented on it
[20:47:34] <sam_> yes, close it with NEEDINFO or something
[20:47:49] <dilfridge> done
[20:48:05] <dilfridge> 4) OPEN FLOOR
[20:49:24] <mgorny> i was wondering if we should split supported arches into more official tiers
[20:49:32] <mgorny> to make it clear to users what to expect
[20:49:59] <mgorny> right now https://www.gentoo.org/downloads/ only puts amd64 and arm64 out
[20:50:06] <mgorny> and everything except for 'experimental' looks equal
[20:50:50] <Marecki> mgorny: IIRC your response to a related question a few months ago we sort of already have the tiers, don't we? So it might be the matter of making them formal?
[20:50:56] <Marecki> (or at least more visible)
[20:51:05] <gyakovlev> well ppc64 is in very good shape (download section) and has probably most stages and installers for everything.
[20:51:21] <dilfridge> and experimental only includes s390
[20:51:22] <sam_> we should possibly split ppc into ppc and ppc64 on that page
[20:51:48] <mgorny> gyakovlev: do you consider ppc64 and ppc64le support equal?
[20:52:00] <dilfridge> mgorny: how about you try to write up some simple table of expectations for tiers? we can then discuss it on the list
[20:52:21] <gyakovlev> mgorny: on releng basis - yes.
[20:52:21] <gyakovlev> on usability level - no, be has some desktop issues.
[20:52:40] <gyakovlev> but is perfectly fine in serverland
[20:52:44] <mgorny> if i had a good idea how to do it, you'd be voting a glep already ;-P
[20:53:00] <dilfridge> well make a first draft and circulate it :P
[20:53:07] <sam_> i think let's discuss on ML first
[20:53:10] <sam_> (even if it's not with a glep draft)
[20:53:16] <dilfridge> nobody expects the sp^H^H^H^H^Ha final product
[20:53:17] <sam_> need more time to structure thoughts on tiers i think
[20:53:47] <mgorny> i'd like to hear sam_'s thoughts first
[20:53:58] -*- Marecki is looking for the aforementioned comment from a few months ago, gimme a sec...
[20:54:58] <Marecki> Ah, no - that was only "arch vs ~arch-only vs exp", and we need something more fine-grained
[20:55:07] <Marecki> Still, it might be a good place to start!
[20:55:12] <gyakovlev> sam_: we currently share an ppc32/ppc64 installer, it's one livecd. so I'd say separate installer is a pre-requisite for splitting
[20:55:22] <dilfridge> ok anything else?
[20:55:24] <gyakovlev> which depends on separate ppc vm =)
[20:55:25] <mgorny> the key point is that i don't want to say "this arch is tier 3, so we have to remove stable keywords"
[20:55:36] <mgorny> rather "this arch doesn't have stable keywords, so it can't be tier 1"
[20:55:55] -*- sam_ nods
[20:56:02] <Marecki> Makes sense
[20:56:06] <sam_> but let's discuss off-meeting
[20:56:27] <dilfridge> ok if there are no other topic
[20:56:28] <dilfridge> s
[20:56:33] -*- dilfridge bangs the gavel
[20:56:37] <dilfridge> meeting closed
[20:56:38] <mattst88> thanks for chairing!
[20:56:39] <Marecki> WAIT
[20:56:40] <gyakovlev> thanks for chairing
[20:56:43] <gyakovlev> oh
[20:56:44] <Marecki> I've got one
[20:56:51] <dilfridge> ok
[20:56:55] -*- dilfridge unbangs 
[20:57:02] <dilfridge> Marecki: talk to us
[20:57:17] <Marecki> Finishing on the last point, I guess we'd need something like "to be consider tier X, arch must support: (...)". And now the new one:
[20:57:43] <Marecki> Do we need some sort of a policy on the merging of PRs that does not undo keywording?
[20:58:08] <gyakovlev> we have one already (kinda)
[20:58:09] <sam_> i'm not sure if i follow yet
[20:58:21] <mgorny> Marecki: plz rephrase
[20:58:34] <Marecki> It has already happened to me several times that a PR got merged which introduced a new revision or version/ebuild of a package which has recently had the ~riscv keyword added, without including that keyword.
[20:59:01] <mgorny> Marecki: probably old PRs?
[20:59:03] <sam_> ah
[20:59:07] <gyakovlev> well tooling tells you that keywords has been dropped
[20:59:09] <sam_> yeah, that'd be old un-rebased PRs
[20:59:09] <Marecki> Now which one was the latest case.... Gimme a sec.
[20:59:20] <dilfridge> ask the submitter, and if it was accidental, just adjust it and re-add the keyword
[20:59:27] <sam_> that's what i've been doing
[20:59:29] <gyakovlev> yeah ^
[20:59:39] <mgorny> doesn't repoman report it as well?
[20:59:44] <gyakovlev> or just manually restore keyword after merging
[20:59:49] <gyakovlev> repoman used to
[20:59:57] <gyakovlev> but I haven't used it for a while
[21:00:06] <gyakovlev> so yeah tooling warns about it
[21:00:08] <Marecki> mgorny: Not really old. arturzam's commit introducing a new revision was dated 6th of September, the keyword was added on the 9th of September
[21:00:23] <mgorny> well, older than your commit
[21:00:30] <Marecki> gyakovlev: pkgcheck complains about this too
[21:00:32] <sam_> that's the only thing which matters
[21:00:37] <sam_> "was it before the keyword was added"
[21:00:38] <mgorny> just ping whoever merged it to read pkgcheck/repoman output
[21:00:42] <sam_> yes
[21:00:47] <Marecki> Which is why it looks like we might need a policy so that whoever merges the PRs actually bothers to check.
[21:01:04] <mgorny> well, "whoever merges" is already expected to verify the commits
[21:01:09] <mgorny> so i don't think we need a new policy
[21:01:15] <mattst88> people generally speaking need to run pkgcheck more...
[21:01:17] <Marecki> Fair enough.
[21:01:18] <dilfridge> should already be covered under "ommon sense"
[21:01:28] <sam_> Marecki: but agreed we should poke about this on maybe the ML and ping proxy-maint about it
[21:01:33] <sam_> "watch out for this common issue"
[21:01:42] <mattst88> a surprising number of developers are still learning it exists
[21:01:42] <Marecki> sam_: Good idea.
[21:02:18] <dilfridge> k
[21:02:18] <Marecki> mattst88: If there are developers with commit access who know neither pkgcheck nor repoman... Scary.
[21:02:37] <Marecki> One sec, let me quote the last occurrence of this problem for reference.
[21:02:44] <mattst88> Marecki: they know repoman, but repoman is very much inferior these days
[21:02:54] <gyakovlev> Marecki: welcome to the world of elder gentoo, where rules don't apply and sense makes no sense.
[21:03:18] <Marecki> mattst88: I know - but it DOES catch DroppedKeywords
[21:03:28] <mattst88> that's a fair point
[21:03:51] <Marecki> Got it, look at commit history of dev-python/mkdocs-redirects
[21:04:01] <Marecki> Okay, that's it from me on the subject
[21:04:14] <sam_> Can I be really annoying super quick on a somewhat related topic?
[21:04:19] <dilfridge> go on
[21:04:35] <sam_> We've had a few complaints about people "wrongly" keywording by not updating 9999 ebuilds from Whissi and Polynomial-C complained about it in the past
[21:04:42] <sam_> At one point, Whissi went as far as doing a "Fixes:" commit
[21:04:48] <Marecki> Even more annoying than usual? ;-) JK, go ahead
[21:04:49] <sam_> I really don't think this is something we can enforce but I think we should talk about it
[21:05:02] <sam_> In general, I don't think there's a simple way to "always make sure you keyword 9999 too"
[21:05:07] <sam_> Because not everybody uses templates
[21:05:10] <mgorny> we should talk why 9999 ebuilds have keywords?
[21:05:11] <dilfridge> exactly
[21:05:19] <sam_> So, I'd like to know, do we all expect arch teams to check every single time?
[21:05:24] <sam_> Or is it the responsibility of the maintainer?
[21:05:26] <sam_> (This is my opinion)
[21:05:26] <dilfridge> no this is maintainer thing
[21:05:41] <dilfridge> because arch teams automate, and this can't be easily automated
[21:05:47] <mgorny> it's like people complaining we don't update their fancy overlays
[21:05:55] <dilfridge> but maintainer knows his fancy ebuild
[21:05:56] <mgorny> if you do custom workflow, you're responsible for it
[21:06:07] <sam_> Marecki: hehe
[21:06:29] <gyakovlev> idk I always sync keywords to live (to the section behind if [[ ${PV}
[21:06:31] <dilfridge> workflow of bumping from 9999 to version is rather common by now, but even then 9999 can look very different
[21:06:36] <Marecki> Having run into this before as both package maintainer and arch tester, I REALLY do not want to be told to update "if not live" KEYWORDS in live ebuilds
[21:06:39] <sam_> the problem is nattka/ekeyword can't easily do this
[21:06:50] <gyakovlev> sam_: ekeyword actually works
[21:06:58] <gyakovlev> use it all the time
[21:06:59] <sam_> gyakovlev: nono
[21:07:00] <Marecki> (while keywording actual revisions)
[21:07:02] <sam_> what i'm saying is
[21:07:14] <sam_> i can't ALWAYS do ekeyword ppc foo-1.ebuild ekeyword-9999.ebuild
[21:07:21] <sam_> because if there's no template, it'll *actually* keyword 9999
[21:07:30] <gyakovlev> yeah
[21:07:48] <gyakovlev> it's manual, so I keep attention
[21:07:50] <sam_> Marecki: Yeah, I really feel this is for package maintainers.. you should diff anyway just to check on bumps
[21:08:04] <gyakovlev> and again
[21:08:06] <sam_> It's not for arch testers at all, but I wanted to see if maybe I had the wrong interpretation of this
[21:08:07] <gyakovlev> tooling will warn
[21:08:12] <sam_> yes :)
[21:08:27] * ulm has changed topic for #gentoo-council to: "220th meeting: 2021-12-12 19:00 UTC | https://www.timeanddate.com/worldclock/fixedtime.html?iso=20211212T19 | https://wiki.gentoo.org/wiki/Project:Council | https://dev.gentoo.org/~dilfridge/decisions.html"
[21:08:29] <Marecki> Not to mention that by my experience, not a few such "universal" live ebuilds end out of sync with latest releases in _way_ more ways than just keywords
[21:08:32] <gyakovlev> so it's just asking maintainers/comitters to pay more attention
[21:08:35] <dilfridge> ok but i think with that we really come to the end...
[21:08:41] <dilfridge> any more topics?
[21:08:43] -*- sam_ nods
[21:08:47] <sam_> no more from me
[21:08:55] <Marecki> Or to put it more bluntly, if you maintain a live ebuild then ~$%%~!@!$% look after it
[21:09:00] <sam_> Marecki: absolutely
[21:09:41] <dilfridge> no more topics
[21:09:44] <gyakovlev> well I still update live ebuilds for others, that not only helps them , but me too, so I  don't have to keyword it again
[21:09:54] <gyakovlev> no more topics from me
[21:09:56] -*- dilfridge re-bangs the gavel
[21:10:01] <dilfridge> meeting finished