diff options
author | Andreas K. Hüttel <dilfridge@gentoo.org> | 2021-05-28 20:01:41 +0200 |
---|---|---|
committer | Andreas K. Hüttel <dilfridge@gentoo.org> | 2021-05-28 20:01:41 +0200 |
commit | 91df96729fb8ab289bd93d426797bafb11c2e3ed (patch) | |
tree | c57eaaa92c0f23b1566d97acca85266b8f271df1 | |
parent | Add summary of the emergency meeting (diff) | |
download | council-91df96729fb8ab289bd93d426797bafb11c2e3ed.tar.gz council-91df96729fb8ab289bd93d426797bafb11c2e3ed.tar.bz2 council-91df96729fb8ab289bd93d426797bafb11c2e3ed.zip |
Add 2020/11 logs
Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org>
-rw-r--r-- | meeting-logs/20201108.txt | 246 | ||||
-rw-r--r-- | meeting-logs/20201108.txt.asc | 19 |
2 files changed, 265 insertions, 0 deletions
diff --git a/meeting-logs/20201108.txt b/meeting-logs/20201108.txt new file mode 100644 index 0000000..030ad70 --- /dev/null +++ b/meeting-logs/20201108.txt @@ -0,0 +1,246 @@ +8/Nov/2020 + +[20:00:38] <gyakovlev> !proj council +[20:00:39] <willikins> (council@gentoo.org) dilfridge, gyakovlev, mattst88, slyfox, ulm, whissi, williamh +[20:00:43] <slyfox> \o/ +[20:01:05] <gyakovlev> let's start the meeting. +[20:01:05] <gyakovlev> today's agenda: https://archives.gentoo.org/gentoo-project/message/8a574038e9dc22d7f15b687ffab0abc6 +[20:01:10] <gyakovlev> 1. Roll call +[20:01:15] -*- gyakovlev here +[20:01:18] -*- slyfox here +[20:01:19] -*- ulm here +[20:01:20] -*- dilfridge here +[20:01:21] -*- Whissi here +[20:01:21] -*- WilliamH here +[20:01:22] -*- mattst88 here +[20:01:58] <gyakovlev> good, everyone is here. moving to 2. +[20:02:47] <gyakovlev> in agenda there are links [1][2] and [3] contain all the proposed features, do we want to vote each separately? +[20:03:20] <ulm> [1] contains all features +[20:03:26] <mattst88> Quick question: this just approving EAPI=8 features, but not necessarily locking us into these being the /only/ EAPI=8 features, right? +[20:03:26] <slyfox> i personally don't mind all-or-nothing vote +[20:03:33] <mattst88> IOW: we can approve more changes later? +[20:03:36] <ulm> and traditionally the council has voted separately +[20:04:10] <dilfridge> traditionally it has, yes... before we discuss this for long let's just start with it +[20:04:17] <WilliamH> I don't mind all or nothing either. +[20:04:25] <ulm> mattst88: that's pretty much intended as the complete list +[20:05:16] <mattst88> I'm happy with all of the proposed changes, FWIW +[20:05:18] <dilfridge> works for me too +[20:05:19] <Whissi> For my understanding, is this the final list? Is it still possible that we are going to remove/add stuff to EAPI 8? +[20:05:51] <gyakovlev> ok, vote item: 1) EAPI8 tentative features, all or nothing. +[20:05:51] <gyakovlev> features listed here https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_8_tentative_features +[20:05:51] <gyakovlev> please vote yes if agree with all, if someone votes no we'll move to itemized voting. +[20:05:52] <ulm> Whissi: everything is possible +[20:06:02] -*- slyfox yes +[20:06:03] -*- dilfridge yes +[20:06:04] <ulm> but there's not plan from the PMS team to extend the list +[20:06:09] -*- gyakovlev yes +[20:06:29] -*- mattst88 yes +[20:06:59] -*- WilliamH yes +[20:07:07] -*- Whissi yes +[20:07:09] -*- ulm yes +[20:07:12] <slyfox> \o/ +[20:07:20] <dilfridge> verrry nice +[20:07:21] <ulm> excellent, thank you :) +[20:07:39] <gyakovlev> ok all proposed eapi8 features passed with all yes vote. moving on. +[20:07:46] <gyakovlev> *tentative +[20:08:26] <gyakovlev> moving to 2) Open bugs with council participation +[20:08:28] <gyakovlev> https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&email2=council%40gentoo.org&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype2=substring&list_id=4950950&query_format=advanced +[20:08:55] <gyakovlev> https://bugs.gentoo.org/751010 Missing log summaries. +[20:09:05] <dilfridge> I know I know... +[20:09:10] <dilfridge> soon +[20:09:21] <gyakovlev> speaking for myself I finally recovered the machine, will upload old log with todays one soon. +[20:10:02] <gyakovlev> https://bugs.gentoo.org/688876 Comrel webpage does not document expectations of privacy +[20:10:15] <gyakovlev> I see the ping but no answer. +[20:10:30] <slyfox> I can ping again :) +[20:10:39] <gyakovlev> I'll take that one, don't worry. +[20:10:43] <slyfox> Thank you! +[20:11:02] <gyakovlev> bug #729062 +[20:11:03] <willikins> gyakovlev: https://bugs.gentoo.org/729062 "Services and Software which is critical for Gentoo should be developed/run in the Gentoo namespace"; Gentoo Council, unspecified; IN_P; jstein:council +[20:11:25] <WilliamH> Nothing else has really been said about that... +[20:11:28] <Whissi> I missed both items... for some reason I thought we meet next week and just realized yesterday :/ +[20:11:59] <gyakovlev> ok that's one on Whissi in that case. Please follow up once you can. +[20:12:42] <gyakovlev> as for bug #736760 +[20:12:43] <willikins> gyakovlev: https://bugs.gentoo.org/736760 "Application to Software Freedom Conservancy"; Gentoo Foundation, Proposals; CONF; mgorny:trustees +[20:13:27] <WilliamH> I think SFC isn't interested in taking us on? +[20:13:27] <gyakovlev> I know there has been no new developments and we are waiting for some answers/clarifications. +[20:13:31] <slyfox> cloucil@ there is as an FYI, right? +[20:13:47] <gyakovlev> yeah there's no actionable items, just status update. +[20:13:51] <slyfox> *nod* +[20:14:39] <gyakovlev> and the last one is inderect bug #574752 +[20:14:40] <willikins> gyakovlev: https://bugs.gentoo.org/574752 "Rename portage-YYYYMMDD.tar* snapshots with gentoo-YYYYMMDD.tar*"; Gentoo Infrastructure, Other; IN_P; mgorny:infra-bugs +[20:14:46] <Whissi> That's my second item, I have something prepared for zac to review but not yet posted :/ +[20:14:49] <gyakovlev> I finally see some activity there. +[20:16:10] <gyakovlev> ok at least something happening after month of radio silence. This concludes item 3. of today's agenda. +[20:16:19] <gyakovlev> 4. Open floor +[20:16:52] <gyakovlev> any1? +[20:17:03] -*- mattst88 has nothing +[20:17:09] -*- WilliamH has nothing +[20:17:18] <slyfox> ${crickets} +[20:17:52] <gyakovlev> ok let's just wait 3 minutes till :20 +[20:17:58] <Whissi> This feels like my daily meetings... +[20:17:59] -*- Whissi has nothing +[20:18:01] <slyfox> SGTM +[20:18:55] <FreedomBear> Way to go all. +[20:18:56] <mattst88> epsilonKNOT asks about the display-manager init renaming +[20:19:07] <dilfridge> after this week, a no-news slow week is just great +[20:19:16] <mattst88> it feels like we're in a bit of a deadlock +[20:19:29] <mattst88> renaming seems fine to me, FWIW, since we're already going to have a news item +[20:19:30] <dilfridge> is that really necessary? we should just keep it as xdm +[20:19:39] *** Modus #gentoo-council +v epsilonKNOT by mattst88 +[20:19:48] <slyfox> what is a tl'dr? +[20:19:56] <dilfridge> too long didnt read +[20:20:07] <epsilonKNOT> xdm is both an actual display-manager and also a init script +[20:20:20] <epsilonKNOT> the init script name is a misnomer as it start any display-manager +[20:20:23] <gyakovlev> slyfox: moving /etc/init.d/xdm out of xorg specific package. +[20:20:31] <dilfridge> yes but for ages the xdm script has been used to start any display manager +[20:20:35] <gyakovlev> to gui-libs/diplay-manager-init +[20:20:37] <WilliamH> epsilonKNOT: That makes sense to me. +[20:20:39] <slyfox> aha +[20:20:43] <mattst88> the thread on gentoo-dev is '[gentoo-dev] [REVIEW] News Item - 2020-10-17-display-manager-init +[20:20:56] <epsilonKNOT> ty mattst88 :) +[20:21:05] <dilfridge> moving it out makes sense, not so sure about the renaming :D +[20:21:10] <WilliamH> dilfridge: fix the misnomer by renaming. +[20:21:25] <slyfox> https://archives.gentoo.org/gentoo-dev/message/524ad4d76379a4f70555bf51aa1edbe4 +[20:21:27] <ulm> that rename is pointless and I am strongly opposed +[20:21:45] <ulm> and it's longer to type :) +[20:21:59] <dilfridge> well, the impact is rather limited, and how often do you have to type it? +[20:22:12] <mattst88> yeah, that's argument is a complete waste of time +[20:22:20] <WilliamH> mattst88++ +[20:22:26] <ulm> the problem is the impact on users because it will require manual intervention +[20:22:30] <gyakovlev> epsilonKNOT: have you seen my proposal on smooth migration path? not sure if it made it to mailing list. +[20:22:39] <gyakovlev> I had some mail troubles +[20:22:52] <WilliamH> ulm: that's what news items are for, they tell users what they need to do, they do it once, then they are done. +[20:23:02] <epsilonKNOT> i saw that you mentioned to *try* and get a smooth path, i am not sure if there was any concrete solution +[20:24:00] <mattst88> ulm: we'll already have a news item, and I think we determined that we can just fix it up automatically in pkg_postinst(), didn't we? +[20:24:00] <ulm> yeah, but there's no point to the renaming, in the first place +[20:24:00] <ulm> it's just unnecessary bikeshedding +[20:24:00] <WilliamH> ulm: I disagree. +[20:24:00] <gyakovlev> epsilonKNOT: I provided one, I'll try to re-send. +[20:24:00] <ulm> wihtout an underlying technical reason +[20:24:00] <ulm> and it will put burden on users +[20:24:00] <gyakovlev> it will solve manual steps completely. +[20:24:00] <epsilonKNOT> gyakovlev: thanks :O +[20:24:00] <WilliamH> ulm: the reason is that the xdm init script can start things other than xdm. +[20:24:02] <ulm> gyakovlev: which aren't needed without the renaming +[20:24:09] <ulm> WilliamH: so what? +[20:24:11] <mattst88> the point in renaming is that it removes the ambiguity +[20:24:27] <WilliamH> mattst88++ +[20:24:27] <ulm> the display-manager script would also start things named differently +[20:24:59] <epsilonKNOT> thats a bit of a red herring, its starting a display-manager +[20:25:08] <slyfox> '/etc/init.d/xdm' is also a gentoo-specific script, right? +[20:25:08] <ulm> mattst88: what ambiguity, there's only one init script named xdm +[20:25:14] <mattst88> slyfox: yes +[20:25:27] <mattst88> ulm: with x11-apps/xdm +[20:25:47] <mattst88> xdm (the script) can start x11-apps/xdm, gnome-base/gdm, or ..., et al +[20:25:47] <slyfox> *nod*, i don't mind a rename (but i also don't use it) +[20:25:49] <ulm> that's a package +[20:26:04] <mattst88> ulm: of course it's a package? +[20:26:20] -*- sam_ scratches head +[20:26:23] <ulm> where's the ambiguity? +[20:26:31] <ulm> different name space +[20:26:37] <mattst88> the confusion is that there's a script, 'xdm' installed to /etc/init.d that (1) isn't from x11-apps/xdm and (2) can start things other than x11-apps/xdm +[20:26:46] <ulm> so what? +[20:26:55] <sam_> All this is about is making 'xdm' (the script which starts up a DM) not necessarily mean xdm the WM, and also emphasise it's not necessarily even X. +[20:27:02] <gyakovlev> ulm: it's been a source of confusion for many years for many new users. +[20:27:20] <gyakovlev> because everyone else has per-dm initscripts +[20:27:21] <mattst88> ulm: maybe just take our words for it that it's been confusing for a lot of people? +[20:27:21] <dilfridge> yeah not everyone remembers that xdm even exists +[20:27:29] <sam_> having two things called xdm when you might even be using wayland is kind of weird. +[20:27:30] <epsilonKNOT> as sam has said, the scripts don't have anything to do with xxorg-server either +[20:27:36] <sam_> I didn't know xdm even existed when I first used 'xdm' +[20:27:58] <dilfridge> can the xdm init script start cde? +[20:28:05] <slyfox> so unambiguous which is which :) +[20:28:16] <sam_> hehe +[20:28:30] <gyakovlev> dilfridge: I authoritatively answer yes as cde maintainer +[20:28:34] <dilfridge> ++ +[20:29:03] <mattst88> should I just put this on the council agenda for next month, or can we attempt a vote to unblock this? +[20:29:11] <dilfridge> let's just vote +[20:29:16] <slyfox> ultimately i'd say it's up to /etc/init.d/xdm maintainer to decide how it should be handled. +[20:29:29] <epsilonKNOT> slyfox: there is none (if you don't count x project) +[20:29:34] <dilfridge> !proj x11 +[20:29:34] <willikins> dilfridge: (x11@gentoo.org) chithanh, leio, mattst88, remi, sarnex, slashbeast +[20:29:44] <dilfridge> mattst88: you decide :P +[20:29:48] <mattst88> lol +[20:29:51] <WilliamH> slyfox++ +[20:30:03] <WilliamH> I was about to ask why that is coming to the council to begin with. +[20:30:14] <gyakovlev> so yeah please stop this bikeshed and do the right thing. there are solutions to work around this. +[20:30:29] <gyakovlev> for smooth migration for unsuspecting users. +[20:30:50] <WilliamH> I'm not sure it needs to be a council issue at all. +[20:30:50] <dilfridge> no need for a fundamental discussion about constitutional amendments +[20:30:52] <mattst88> WilliamH: right, only because of the strength of the disagreement did I think I should ask council +[20:31:10] <WilliamH> How many people disagreed mattst88 ? +[20:31:22] -*- slyfox does not +[20:31:30] -*- dilfridge doesnt mind that much +[20:31:37] <ulm> if this was a new introduction of the init script, I'd agree that xdm wasn't the best name +[20:31:38] <epsilonKNOT> there were atleast 3 people with dissatisfaction in the mailing list thread +[20:31:40] <ulm> but we're talking about migration path here +[20:31:43] <dilfridge> my main point is it shoudl be a smooth upgrade path +[20:32:00] <epsilonKNOT> it can be done by adding to pkg_postinst +[20:32:00] <dilfridge> if zyou can provide that everything is good +[20:32:02] <mattst88> WilliamH: ulm (strongly), juippis (mildly? thought the rename is useless). I think ulm is the only strongly-disagree that I know of +[20:32:05] <gyakovlev> I personally HATE gui-libs category, it just does not sound right. but ok for rename itself. +[20:32:36] <slyfox> i think package moves are easier to move +[20:32:39] <WilliamH> If we are talking about migration path ulm, imo if there is a migration path that means the rename can go ahead. +[20:32:59] <WilliamH> Even with manual intervention by users as long as there is a newsitem. +[20:33:10] <epsilonKNOT> manual intervention is going to be required in any case +[20:33:24] <WilliamH> epsilonKNOT: ok, in that case, there isn't a blocker. +[20:33:29] <ulm> and that's a killer argument against renaming IMHO +[20:33:50] <WilliamH> ulm: did you look at what epsilonKNOT said? there is going to be manual intervention regardless. +[20:33:55] <epsilonKNOT> display-manager-init has no reverse dependencies, none of gdm/sddm/lightdm *need* xdm script to be present +[20:34:05] <epsilonKNOT> they can all be started from command line +[20:34:21] <epsilonKNOT> so if you want a display-manager-init script, you have to add it manually +[20:34:30] <mattst88> in other words: users will be asked to emerge gui-libs/display-manager-init +[20:34:40] <mattst88> so they can easily rc-update add ... too +[20:35:33] <dilfridge> ok, on the upside we're not talking about the ssh or net.eth0 init script here +[20:35:54] <mattst88> right +[20:35:57] <dilfridge> so if this breaks people should be able to fix it rather quickly +[20:36:02] <dilfridge> still it's kinda ugly +[20:36:28] <ulm> mattst88: can't you make it a (use conditional) dependency of xorg-server +[20:36:30] <ulm> ? +[20:36:36] <WilliamH> dilfridge: manual intervention is a fact of life. +[20:36:46] <epsilonKNOT> ulm: its a optional runtime dependency, i think thats not allowed +[20:36:55] <WilliamH> epsilonKNOT++ +[20:37:21] <mattst88> ulm: we could -- it'd be distateful, but we could. but I assume we'll still have people with wayland-only systems that would need to install it explicitly +[20:37:21] <ulm> there are exceptions to that rule for a transition path +[20:37:29] <gyakovlev> epsilonKNOT: it's allowed under special circumstances with appropriate approval. +[20:37:30] <dilfridge> WilliamH: yes, I still remember when my server didnt boot... since no keyboard was connected, dmcrypt timed out, mount failed, and then the network didnt start +[20:38:15] <WilliamH> gyakovlev: I haven't heard that. if it is I am going to apply for it for logrotate w/ openrc. :-) +[20:38:41] <gyakovlev> WilliamH: you have to have a good enough reason ofc. talk to qa. +[20:38:58] <dilfridge> let's just say, a good reason should be there +[20:38:58] <mattst88> ulm: are you against any sort of manual intervention? I'm struggling to understand what you find so awful about the rename +[20:39:11] <WilliamH> mattst88++ +[20:39:29] <epsilonKNOT> if we go for keeping it as optional runtime, then we can do a pkg_postinst to check if it enabled and then swap out xdm to display-manager. this would count as an automated path +[20:39:51] <ulm> mattst88: the rename would add an additional step to any manual intervention, right? +[20:39:55] <gyakovlev> epsilonKNOT: poor soul, your got yourself into that opinion war trying to do a good thing. +[20:40:05] <sam_> Fair play, she's gone right in the deep end. :) +[20:40:15] <mattst88> ulm: yes, it would require the user to run rc-update +[20:40:25] <sam_> at the end of the day, this is righting a long-standing wrong +[20:40:37] <WilliamH> rc-update add display-manager <runlevel> <-- done +[20:40:49] <ulm> *shrug* I believe I've voiced my opinion +[20:40:52] <ulm> loudly :) +[20:41:14] <WilliamH> ulm: your opinion seems to be that you are against manual intervention, which is unrealistic. +[20:41:16] <dilfridge> so what happens to the people who administer 100++ desktops? +[20:41:26] <epsilonKNOT> indeed, having disagreements is not bad per se :) +[20:41:37] <Soap__> dilfridge: ansible? +[20:41:39] -*- Soap__ ducks +[20:41:40] <mattst88> dilfridge: presumably they have systems for managing 100+ desktops, like ansible, salt, puppet, etc? +[20:41:45] <dilfridge> otoh, yes, ansible or rex or ... +[20:42:06] <Soap__> that said, a university of gentoo desktops, I'm not convinced thats a thing +[20:42:12] <dilfridge> sorry just channeling patrick :D +[20:42:24] <Soap__> 100++ servers maybe +[20:42:28] <mattst88> okay, I guess we're done here +[20:42:39] <slyfox> *nod* +[20:42:52] <epsilonKNOT> thanks you :) +[20:43:00] <WilliamH> Yeah I would guess servers aren't going to have a display manager. +[20:43:08] <dilfridge> I suppose this manual intervention is much smaller than typical portage upgrade fiddling. +[20:43:36] <epsilonKNOT> for sure, removing cycles with use flags is more work :) +[20:44:29] <gyakovlev> ok, seems there are no more open floor items. +[20:44:36] <gyakovlev> let's call it a day +[20:44:38] <dilfridge> thanks everyone +[20:44:41] -*- dilfridge sneaks off +[20:44:43] <WilliamH> We can argue about things like that all day, but really shouldn't we let the maintainers handle it? +[20:44:43] <epsilonKNOT> thanks again :) +[20:44:46] -*- gyakovlev bangs the gong, meeting closed. +[20:44:47] <WilliamH> Thanks all. :-) +[20:44:58] <Whissi> \o/ +[20:45:00] <slyfox> thanks all! diff --git a/meeting-logs/20201108.txt.asc b/meeting-logs/20201108.txt.asc new file mode 100644 index 0000000..7bcaf19 --- /dev/null +++ b/meeting-logs/20201108.txt.asc @@ -0,0 +1,19 @@ +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v2 + +iQKTBAABCgB9FiEE6W4INB9YeKX6Qpi1TEn3nlTQogYFAmCxL+hfFIAAAAAALgAo +aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEU5 +NkUwODM0MUY1ODc4QTVGQTQyOThCNTRDNDlGNzlFNTREMEEyMDYACgkQTEn3nlTQ +ogYAyBAAvKerAFLjf2qYh5Gxl8dL+dUsnM52GMrpWeH26F9k0KYAZyNEt7vMfrN+ +rbGiHdB8xyYAOrcCci/aXzNK668t2pT7YFua1nRAyyd0fUoVchGUq2ZkegWLTsIo +BuZWQ9NlFgrtExF0y4MnbUGe3fGBHlJAXNbiphNDptVA6hBJ1UQlrI2suvHhuvSl +UVeIcK9E7v15C8p+SSJGvL8Ew816f8nvDfgk8/5YBIPj2F0AeGHInrrqAbMMCZY/ +4GHv0I683ITRuiMsLuTNDsOi2Ey4xCdDL3xRgEWw4KmZOt8QKAtSQsvvLqh560Bv +ZYFnfFTMkWW0mQIq2vPUWhE0NJFq37GFiGw1MpLCUGShbxgWtAs7n8oZEn1Ap16b +Lua6hTs4wt5tBWElBjroXxOAnfyHw6oQWGeKtmX1/6sOvZcSG/g1ZkCoKRAEQ7dI +b/2pYJch+waJ2jMExGI911zuwMgoZ3e1sb9nKrcmlVblR/ZXP7Y5e8j5qJe3DAM3 +JFWwVXTEZ9MQcP2FwZ6PoriXKc+r6vzEwohbPYoHbodR3nZpyinWCA32DkyzRcy5 +wIe6Y9ch6Rg9M20314Z/gCN8d3nUfxwOFI2SfnIC+46NIGcf84O+2TV+TTj4uqTE +BKMdJUwq1h6mRabk2B8oXND4/q47vCin++07F1uB4u/P9bsEpIs= +=L/Jo +-----END PGP SIGNATURE----- |