10:09:12 <aday> #startmeeting Workstation WG (2020-02-18)
10:09:12 <zodbot> Meeting started Thu Feb 20 10:09:12 2020 UTC.
10:09:12 <zodbot> This meeting is logged and archived in a public location.
10:09:12 <zodbot> The chair is aday. Information about MeetBot at http://wiki.debian.org/MeetBot.
10:09:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
10:09:12 <zodbot> The meeting name has been set to 'workstation_wg_(2020-02-18)'
10:09:12 <aday> #meetingname workstation
10:09:12 <zodbot> The meeting name has been set to 'workstation'
10:09:12 <aday> #chair aday cmurf
10:09:12 <aday> #topic rollcall
10:09:13 <aday> #info present: otaylor, aday, cmurf, mcatanzaro, neal, tpopela, mclasen, jens, langdon, kalev (arrived late)
10:09:13 <zodbot> Current chairs: aday cmurf
10:09:14 <aday> #info regrets:
10:09:16 <aday> #info missing:
10:09:18 <aday> 
10:09:20 <aday> #topic approve minutes
10:09:22 <aday> #info approve meetbot 2020-02-12-17.07
10:09:24 <aday> #link https://meetbot.fedoraproject.org/teams/workstation/workstation.2020-02-12-17.07.log.html
10:09:26 <aday> #agreed Minutes approved.
10:09:28 <aday> #topic announcements
10:09:30 <aday> #info FESCo has approved the working group's updated governance document
10:09:32 <aday> #info The draft issue for the Fedora Council (for "ship fedora-workstation-repositories on install media") is available: https://pagure.io/fedora-workstation/issue/105#comment-626259
10:09:35 <aday> #topic Support for hibernation?
10:09:39 <aday> #info Background is https://pagure.io/fedora-workstation/issue/121
10:09:41 <aday> We go round the table:
10:09:43 <aday> - Allan: doesn't want us to enable a feature that doesn't get properly tested, but also doesn't think we should give up on a feature that prevents data loss - so maybe disable in the short term and come up with a long term solution.
10:09:47 <aday> - Jens: echos Allan - it would be nice if it worked, but we should disable it if it doesn't.
10:09:49 <aday> - Langdon: would like hibernation to work.
10:09:51 <aday> - Matthias: hibernation may or may not work, and we shouldn't make promises we can't keep.
10:09:53 <aday> - Michael: there are a lot of problems with hibernation - memory requirements, race conditions... it can't be done reliably, and if we expose it to users it should be reliable.
10:09:56 <aday> - Neal: uses hibernation personally, and would like it to be supported. Wants to know why we can't support it with a swap file. Hibernation generally works for him. But if it doesn't work, we should disable it, but we should have a plan for how to support it. Windows and Mac support hibernation, so we should too.
10:10:00 <aday> - Tomas: echos other statements. Hibernation has failed for him in the past, likely due to his memory being used for other things. If it doesn't work and is unreliable, is against it. Maybe there could be a way to enable it, and we can disable it by default.
10:10:04 <aday> Allan: are the problems just bugs or are they architectural?
10:10:06 <aday> Chris: one issue is incompatibility between UEFI secure boot and hibernation. This could imply that we need a dual strategy and focus on making hibernation work when secure boot is off.
10:10:11 <aday> Neal: or someone who works on secure boot needs to factor in hibernation.
10:10:13 <aday> Chris: hibernation is disabled because it's an attack vector.
10:10:15 <aday> Neal: secure boot is going to become mandatory in a few years.
10:10:17 <aday> Neal: Windows uses an encrypted swap file for hibernation.
10:10:19 <aday> Chris: do we know any upstream developers that we can talk to about this? Owen suggests Peter Jones. Question of time scales: how long are we prepared to have hibernation disabled or unavailable for?
10:10:22 <aday> Back to the round table...
10:10:24 <aday> - Owen: unless we improve the situation, we shouldn't actively break hibernation if someone wants to use it, but we should consider hibernation as not supported and disable it by default. We still don't have a good implementation of hybrid suspend, so it isn't something we can or should advertise as a feature. A long-term approach is to investigate whether we can emulate Windows and work with hardware vendors to support the same path.
10:10:29 <aday> Right now our power management efforts are probably better spent improving suspend power usage.
10:10:31 <aday> Chris: hybrid sleep - an image is written, then the system suspends (s3). Suspend to hibernate - the system suspends, then wakes periodically, and if it needs to, it writes out an image. Lennart apparently has some work to make suspend to hibernate work.
10:10:35 <aday> Chris: if we get rid of a swap partition in F33, we will break hibernate. Owen: someone can manually install with a swap partition if they want to have hibernate. This would be a sufficient level of support.
10:10:40 <aday> Neal: we should make it obvious and trivial to install with a swap partition, if we remove it and not having one disables hibernate.
10:10:43 <aday> Matthias: doesn't think we should make it too easy/obvious to opt into hibernation, if we know it isn't supported/might not work.
10:10:46 <aday> Neal: there are other arguments in favour of swap partitions versus swap files.
10:10:48 <aday> Langdon: agrees with Neal - we should allow hibernation somehow. Our users are generally technically sophisticated. It does work for some people.
10:10:51 <aday> Owen: we default to secure boot, which implies that we default to hibernation disabled.
10:10:53 <aday> Langdon: finds UEFI installs difficult (implication is that secure boot isn't the default in practice). For the most part, UEFI doesn't seem to figure.
10:10:56 <aday> Owen: you don't get firmware updating without UEFI - firmware updating is a feature we advertise. This isn't how to design an OS.
10:10:59 <aday> Langdon: hibernation is a really nice feature.
10:11:02 <aday> Owen: there are two questions about swap: 1. do we want to have a partition? 2. Does it have to be big enough for hibernate?
10:11:04 <aday> Allan: what do other distros do? We don't want to fall behind.
10:11:06 <aday> Neal: Ubuntu and Mageia have a patchset which makes S4 more reliable, and Ubuntu doesn't have the same UEFI requirements so that's not a factor there.
10:11:11 <aday> Neal: TuxOnIce patchset supports proper S4 suspend with encrypted swap: https://en.wikipedia.org/wiki/TuxOnIce
10:11:14 <aday> Allan: we should take this seriously if we want to be competitive.
10:11:16 <aday> [kalev joins]
10:11:18 <aday> Owen: any meaningful plan would involve figuring out how to properly support hibernation, including how to make it compatible with secure boot and how the effort would be resourced. If we can't come up with a credible plan for hibernation, we have to come up with an alternative approach to data loss. This could be at the app level.
10:11:22 <aday> Michael: what does "keeping hibernation" mean? Owen: it means including it in our planning - accommodating it in other technical decisions.
10:11:25 <aday> #action Chris will reach out to Peter Jones, Lennart Poettering (might be unavailable for a few weeks), Matthew Garrett, Hans. Tomas to help with this.
10:11:28 <aday> #topic Reconsider updates policy
10:11:30 <aday> #info Background is https://pagure.io/fedora-workstation/issue/107
10:11:35 <aday> Michael: the issue is that security updates are released daily. The current GNOME Software update logic is to install daily if they are security updates and weekly if they're not security updates. The end result is that we're bugging people to update every day.
10:11:36 <aday> Kalev: Bodhi used to have a mode where it would batch updates on a weekly basis, but maintainers used to circumvent it. Batching on the server side is better that client side - it can allow each batch to be tested before it is made available. Batching also reduces the test matrix.
10:11:42 <aday> Owen: the code to do batching was removed. Michael: it was discovered that the behaviour wasn't being effective. [Some discussion about why this was; something to do with the policy being flawed in some way.]
10:11:45 <aday> Kalev: to do server side batching, we'd need someone whose job it is to marshal the updates [General agreement that this won't happen.]
10:11:48 <aday> Owen: the batching needs to bet client-side because it is workstation-specific (other editions don't require it). Testing of server-side batches probably isn't acheivable outside of Silverblue. We should focus on what's achievable through GNOME Software and Fedora update metadata.
10:11:52 <aday> Tomas: the problem is getting packagers to set the metadata correctly.
10:11:54 <aday> Owen: if someone flags their update as critical, we can put up a confirmation dialog which explains the consequences - "by checking this box, you are forcing every workstation user to reboot in the next 24 hours".
10:11:57 <aday> Neal: we could verify that there is a corresponding security bug for the update (the security bugs have severity levels that are defined).
10:12:00 <aday> Langdon: is the real problem that people need to reboot to install updates? [Neal agrees.] Michael: doesn't think that offline updates is going to be a productive discussion.
10:12:03 <aday> Michael: We do get urgent non-security updates sometimes, so the useful distinction is urgent/non-urgent, not security/non-security.
10:12:06 <aday> Owen: however we define urgency, we should make it transparent to the packager what the consequences are.
10:12:11 <aday> Kalev: we should involve Matthew Miller in the discussion
10:12:13 <aday> #agreed The WG will return to this topic once the discussion has developed a bit more, and we have had opportunity to talk to Matthew Miller
10:12:16 <aday> #action Chris to invite Matthew Miller to join us
10:12:18 <aday> Owen: it's important to have a mechanism to get updates out quickly, but usually having fixes out in a week or two is enough, and training people to ignore updates is counter-productive and causes people not to update
10:12:21 <aday> #endmeeting