10:50:29 <aday> #startmeeting Workstation WG (2020-03-03)
10:50:29 <zodbot> Meeting started Tue Mar 10 10:50:29 2020 UTC.
10:50:29 <zodbot> This meeting is logged and archived in a public location.
10:50:29 <zodbot> The chair is aday. Information about MeetBot at http://wiki.debian.org/MeetBot.
10:50:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
10:50:29 <zodbot> The meeting name has been set to 'workstation_wg_(2020-03-03)'
10:50:29 <aday> #meetingname workstation
10:50:29 <zodbot> The meeting name has been set to 'workstation'
10:50:29 <aday> #chair aday cmurf
10:50:29 <zodbot> Current chairs: aday cmurf
10:50:29 <aday> #topic Rollcall
10:50:29 <aday> #info present: cmurf, aday, neal, jens, kalev, otaylor, tomas, mcatanzaro, benzea, feborges, langdon
10:50:31 <aday> #info regrets: mclasen
10:50:33 <aday> #info missing:
10:50:37 <aday> 
10:50:39 <aday> #topic Approve minutes from 25 Feb
10:50:41 <aday> #info Approve meetbot 2020-02-26-15.23
10:50:43 <aday> #link https://meetbot.fedoraproject.org/fedora-meeting-2/2020-02-26/workstation.2020-02-26-15.23.html
10:50:46 <aday> #topic Enable swap on ZRAM by default
10:50:48 <aday> #info Issue is https://pagure.io/fedora-workstation/issue/127 , we discussed this last week
10:50:50 <aday> #action Chris will organise a test day and coordinate with Michael
10:50:52 <aday> #info The test day will be early in the F33 cycle (by the end of April 2020)
10:50:54 <aday> #topic Anaconda creates too much swap space
10:50:56 <aday> #info Issue is https://pagure.io/fedora-workstation/issue/120
10:50:58 <aday> #info Proposal 1: the edition will have a small swap partition, capped at ~4GiB (the final number can be refined as we go forward), created at install time.
10:51:01 <aday> #info Proposal 2:  the edition will not have a swap partition created at install time.
10:51:03 <aday> Concern raised in the ticket about proposal 1 by Bastien: 4GB is a dangerous amount of swap for a machine with the same amout of RAM. Chris: we can maybe modify the proposal to address this: use 4GB as a maximum and cap it at 2GB.
10:51:09 <aday> Tomas: Bastien's view is that we should drop the partition completely.
10:51:11 <aday> Jens: it's unclear what the swap size would be in proposal 1. What's the difference between maximum and cap?
10:51:14 <aday> Tomas: a smaller swap will imply no hibernation by default.
10:51:16 <aday> Owen: a small memory system will still need a swap partition. The two proposals don't quite reflect the range of scenarios that are available. Proposal 1 is one option here, but there are other options. What are the pros and cons for common scenarios, like a large RAM 16 GB system?
10:51:20 <aday> Chris: there's an advantage to having a small amount of swap even when there's a large amount of physical memory. Without swap, eviction of anon pages isn't possible so when under memory pressure the kernel resorts to reclaim, so you still get IO thrashing, and it can be worse than evicting seldom used anonymous pages. [For more info see this article:https://chrisdown.name/2018/01/02/in-defence-of-swap.html .] Windows and Mac create
10:51:25 <aday> swap dynamically, but on Linux we have to pick a fixed amount.
10:51:27 <aday> Michael: why not swap on zram? Is proposal 1 the fallback if proposal 2 and zram doesn't work out? Chris: we want a small swap partition no matter what. Proposal 2 could happen on top of proposal 1.
10:51:30 <aday> Owen: how does zram interact with a small amount of disk swap? Does it do something reasonable, or is it the worst of both worlds? Chris: the kernel supports up to 32 swap devices. zram would get a higher priority so would be used before the disk-based one.
10:51:34 <aday> Chris: the two proposals are an attempt to take individual steps rather than having a holistic design. What's coming next is zram and zswap testing. Swap on zram is basically done.
10:51:39 <aday> Michael: we want proposal 1 or proposal 2, so we could make the decision to go ahead with one or the other.
10:51:42 <aday> Owen: an alternative proposal:  the working group does not believe that Anaconda should allocate a swap partiiton big enough to hibernate to. (The details of the replacement will be determined later.)
10:51:45 <aday> Kalev: +1
10:51:47 <aday> Michael: +1
10:51:49 <aday> Neal: isn't the proposal that we're going to have a tiny swap partition or none at all, with the option of having an on-demand swap file at a later date if it becomes available? Chris: yes.
10:51:52 <aday> Allan: this sounds consistent with the direction of travel we want. We just need a disk partitioning proposal for F33.
10:51:55 <aday> #agreed The WG will make a decision on this in the F33 cycle, once there's a more concrete proposal for disk partitioning, and once we have feedback from zram testing.
10:51:58 <aday> #topic Status updates
10:52:00 <aday> #info Poor support for multiple VPNs - https://pagure.io/fedora-workstation/issue/123
10:52:02 <aday> #info Michael just hasn't gone to this yet.
10:52:04 <aday> #info Guidelines for preinstalled and non-removable apps - https://pagure.io/fedora-workstation/issue/125
10:52:09 <aday> #info Allan will get something to the group in the next 1 or 2 weeks
10:52:11 <aday> #topic GNOME packages are in bad shape in Bugzilla
10:52:13 <aday> #info Issue is https://pagure.io/fedora-workstation/issue/131
10:52:15 <aday> Michael's intro:
10:52:17 <aday> Right now we're ignoring most of the bugs that come in
10:52:19 <aday> Wants to move the issues upstream by using a script to automatically close the bugs. Excluding anything that's needed for QA, blockers, downstream bugs, security issues: this would need to work off keywords, whiteboards. It would just be for whitelisted GNOME packages.
10:52:23 <aday> It will be much easier to deal with the issue reports upstream.
10:52:25 <aday> Neal: doesn't hate the idea. His experience of doing a similar strategy is that it just moved the unloved bugs elsewhere. From the upstream perspective the issue reports look low quality because there's no reporter CC'd.
10:52:29 <aday> Neal: another issue is that the issues don't get QA'd or included in release management. Compromise proposal: file the issue in both places, then link them.
10:52:32 <aday> Michael's main concern is the number of open bugs so being able to close them upstream would be fine.
10:52:37 <aday> Owen: a lot of the bugs that get filed are RFEs or duplicates. For Fedora we just need the bug reports that are needed for Fedora processes.
10:52:40 <aday> Allan: have we spoken to any upstream maintainers about the proposal? Michael: if any upstream maintainers want to opt out they'll be able to - it will be a whitelist.
10:52:43 <aday> Tomas: let's identify the top five components with the most issues and talk to their maintainers, and focus on those.
10:52:46 <aday> Owen: is this more important for modules with many reports or few reports? What sort of packages are you thinking about? Michael: both.
10:52:49 <aday> Tomas: what would happen if other distros did the same? Michael: this would only work for Fedora because the release cycle is closely aligned with upstream. Tomas: even so, there are non-Fedora people upstream who could resent the move.
10:52:53 <aday> Michael: this would work for distros that are close to the GNOME release schedule - Arch, tumbleweed.
10:52:56 <aday> Allan: cites the example of Ubuntu's community drive to push their issues upstream. Neal: this was possible because Launchpad has the ability to link to upstream issues.
10:52:59 <aday> Michael: would like to address the issue of having lots of ignored issues in Fedora's Bugzilla. Hopes we can agree that there needs to be a solution.
10:53:02 <aday> Owen: we can agree that there's a problem, and we need to try to solve it. Isn't sure we have a good idea how to do that at the moment.
10:53:07 <aday> Allan: agrees. Would like to see examples of what other projects have done. Maybe there are smaller steps we could take that would mitigate the issue rather than entirely eliminate it. Would like to see a case study or a pilot.
10:53:11 <aday> #action Michael will followup on the ticket and hopefully come back with more evidence for the group
10:53:14 <aday> #endmeeting