12:26:14 <aday> #startmeeting Workstation WG (2020-01-21)
12:26:14 <zodbot> Meeting started Fri Jan 24 12:26:14 2020 UTC.
12:26:14 <zodbot> This meeting is logged and archived in a public location.
12:26:14 <zodbot> The chair is aday. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:26:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
12:26:14 <zodbot> The meeting name has been set to 'workstation_wg_(2020-01-21)'
12:26:14 <aday> #meetingname workstation
12:26:14 <aday> #chair cmurf aday
12:26:14 <aday> #topic rollcall
12:26:14 <aday> #info present: aday, cmurf, tpopela, hadess, petersen, mclasen, kalev, mcatanzaro, otaylor
12:26:14 <zodbot> The meeting name has been set to 'workstation'
12:26:14 <zodbot> Current chairs: aday cmurf
12:26:15 <aday> #info regrets: langdon
12:26:17 <aday> #info missing: neal
12:26:19 <aday> #topic Approve previous meeting minutes
12:26:23 <aday> #info https://meetbot.fedoraproject.org/fedora-meeting-2/2020-01-15/workstation.2020-01-15-10.49.html
12:26:26 <aday> #agreed Minutes approved!
12:26:28 <aday> Kalev: why are we approving minutes that have already been published? It's backwards - you can't undo the publication.
12:26:31 <aday> Chris: it's a convention.
12:26:33 <aday> Matthias thinks it's a waste of time.
12:26:35 <aday> Jens: it's a good idea to refer to last week's minutes.
12:26:37 <aday> #agreed In future we won't approve the minutes. Instead, Allan will wait 24 hours after each meeting before sending the minutes, to give time for corrections in the Etherpad.
12:26:40 <aday> #topic Announcements
12:26:42 <aday> #info Devconf is next week. Tomas and Jens might miss our meeting.
12:26:44 <aday> #topic Approve revised Workstation Working Group's Governance document
12:26:46 <aday> #info https://pagure.io/fedora-workstation/issue/110
12:26:48 <aday> #info Changes to the WG's governance need a majority vote of the WG, then to be sent to FESCo for acceptance.
12:26:53 <aday> Allan has posted a question about the phrasing of the draft document.
12:26:55 <aday> #agreed We will postpone this item until next week, to allow further revisions before we vote.
12:26:57 <aday> #topic Approve "Replace Rhythmbox with GNOME Music in default install"
12:26:59 <aday> #info: https://pagure.io/fedora-workstation/issue/33
12:27:01 <aday> There has been some recent discussion on the issue: a point from Allan requesting design goals/policy.
12:27:04 <aday> #action Kalev to provide a list of the current preinstalled apps.
12:27:06 <aday> Kalev: we should approve changes on a case by case basis.
12:27:08 <aday> Michael: the WG previously agreed to follow the defaults set by GNOME, but we can change that if we want. In GNOME the decisions are generally made by Michael, Allan and Javier Jardon. There are a couple of deviations: Music and Web. We don't have a policy for what gets preinstalled, though there has been some discussion recently about keeping the number of preinstalled apps minimal.
12:27:13 <aday> Allan: should we do a regular review of the preinstalled apps for each release, rather than making ad hoc decisions?
12:27:16 <aday> Kalev: we could do this as part of the test days, which the WG should participate in - potentially remove apps that have degraded in quality.
12:27:19 <aday> #agreed Pause this decision until more progress is made in the ticket.
12:27:23 <aday> #action Kalev to organise a test day in coordination with Fedora QA.
12:27:25 <aday> #topic Guest speaker, Bastien Nocera
12:27:27 <aday> #info Background can be found in https://pagure.io/fedora-workstation/issue/98, https://pagure.io/fedora-workstation/issue/119, https://pagure.io/fedora-workstation/issue/120
12:27:30 <aday> Bastien has been investigating solutions on different platforms, motivated to prevent crashes, stop app crashes from affecting the system.
12:27:33 <aday> Bastien talked about his experience and perspective working on low memory monitor:
12:27:35 <aday> - The simpliest solution is to prevent apps from using large amounts of memory.
12:27:37 <aday> - Bastien has implemented something which looks at how hard it is to allocate memory. When memory is under pressure, a signal is emitted which can be read by most parts of the system - this is the low memory monitor (LMM).
12:27:41 <aday> - LMM will hopefully be shipped by default in F32: it is required by xdg-desktop-portal, so should be automatically installed.
12:27:44 <aday> - This will hopefully generate interest in using the signal to reduce memory consumption, and will hopefully make people more aware of memory usage.
12:27:47 <aday> - Reasons against earlyoom: it requires workarounds or hacks to function properly (eg. EARLYOOM_ARGS, or the notification implementation). earlyoom hides the issues that exist, rather than solving them at their cause. For F32 we should advertise that low memory monitor is available, and work towards greater adoption. We should work to ensure that every component responds to the low memory signal (Bastien expects Fedora to do well at
12:27:54 <aday> this). Afterwards we will have a better view of the problem; maybe we will be able to have a more naive memory killer, like the kernel one or a more streamlined version earlyoom, without the hacks.
12:27:57 <aday> - The danger is that earlyoom becomes a black box - unclear how it functions internally. (And presumably hiding the issues that continue to exist.)
12:28:00 <aday> Owen: there two cases where you run out of memory: 1. many processes gradually, collectively using more memory. 2. a single or very small number of processes, soaking up all the memory themselves (classic example is a build process). Your approach is more for 1. Would it deal with 2? Bastien: it is possible to change the importance of particular processes. Bastien would expect measures to set processes so the oom killer knows how to
12:28:05 <aday> deal with them. These could be applied to daemons and build scripts.
12:28:07 <aday> Michael: that's not going to happen for all the build tools. Bastien: it's just a few values you can add on.
12:28:10 <aday> Michael: let's assume that no applications are using low memory monitor. Buggy applications. What happens then? Bastien: the kernel cannot know by itself what too much memory is. We are going to see more and more session services being aware of memory usage. We can't prevent apps from using massive amounts of memory; all we can do is help the oom killer know what to kill when memory is under pressure. LLM's README has links to systemd
12:28:15 <aday> configurations; Bastien can help to provide documentation on how to use these.
12:28:17 <aday> Owen: Bastien's argument is that rather than having the configuration in the oom killer, we should keep the configuration with the apps/processes and expose it to the kernel oom killer. But you still have to have the configuration somewhere: will the scores be set by individual developers? How will that work? Bastien: it's more about apps offering up processes to be killed first. We can also make the oom killer aware of system
12:28:24 <aday> components that shouldn't be killed. It's about using existing infra rather than a new one.
12:28:26 <aday> Michael: can see Bastien's approach coming together in the next year - maybe F33. Can we put memory limits on transient processes? Bastien: we can adjust the killer priority.
12:28:29 <aday> Michael: it's not going to make a big difference whether we fix this issue in F32 or F33. If it's a question of skipping the hack for F32, then he'd skip. It depends on how long the "real" solution might take.
12:28:32 <aday> Owen: earlyoom should set the bar for what we want from a solution. An alternative should work just as well as earlyoom.
12:28:35 <aday> Jens: would like to see testing in Rawhide of the LMM config that Bastien mentioned. Bastien: it would be good for a testday - should be working for Rawhide, but would not enable it by default now since the results can be "surprising".
12:28:39 <aday> Tomas: would you need to modify all the build tools to use the low memory monitor? Bastien: there are different ways we could do it - maybe running them from their own cgroups. If you are just running something from the terminal, there are probably a couple of scripts that could be used, but that wouldn't be clean.
12:28:43 <aday> #endmeeting