desktop February 2020

desktop@lists.fedoraproject.org

12 participants
20 discussions

Revamping the Release Readiness meeting
by Ben Cotton 05 Mar '20

05 Mar '20

(Posting to many mailing lists for visibility. I apologize if you see this more times than you'd like.) You may have already seen my Community Blog post[1] about changing the Release Readiness meeting process. The meeting has questionable value in the current state, so I want to make it more useful. We'll do this by having teams self-report readiness issues on a dedicated wiki page[2] beginning now. This gives the community time to chip in and help with areas that need help without waiting until days before the release. I invite teams to identify a representative to keep the wiki page up to date. Update it as your status changes and I'll post help requests in my weekly CommBlog posts[3] and the FPgM office hours[4] IRC meeting. The Release Readiness meeting will be shortened to one hour and will review open concerns instead of polling for teams that may or may not be there. We will use the logistics mailing list[5] to discuss issues and make announcements, so I encourage representatives to join this list. [1] https://communityblog.fedoraproject.org/fedora-program-update-2020-08/ [2] https://fedoraproject.org/wiki/Release_Readiness [3] https://communityblog.fedoraproject.org/category/program-management/ [4] https://apps.fedoraproject.org/calendar/council/#m9570 -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

1 1

3 Mar, MEETING AGENDA
by Chris Murphy 28 Feb '20

28 Feb '20

9:30 am ET 14:30 UTC Location: https://bluejeans.com/395383051/ https://www.bluejeans.com/numbers Follow-ups: #127 enable swap-on-ZRAM by default - Confirm assignments https://pagure.io/fedora-workstation/issue/127 --- #120 Anaconda creates way too much swap space - Proposals Drop the creation of swap partition for Fedora Workstation 33. Drop the creation of swap partition for Fedora Workstation 33, contingent on one of the swap-on-ZRAM implementations being production ready replacements. https://pagure.io/fedora-workstation/issue/120#comment-629480 --- #121 Support for hibernation? - Close for now, but keep an eye on future developments https://pagure.io/fedora-workstation/issue/121 --- Status Reports: #123 Poor support for multiple VPNs (should we enable systemd-resolved?) https://pagure.io/fedora-workstation/issue/123 #125 Guidelines for preinstalled and non-removable apps https://pagure.io/fedora-workstation/issue/125 Discussion Topics: #131 Red Hat Bugzilla: GNOME packages are in bad shape https://pagure.io/fedora-workstation/issue/131 -- Chris Murphy

1 0

Workstation WG minutes, 25 Feb
by Allan Day 26 Feb '20

26 Feb '20

The Fedora Workstation Working Group had a meeting this week, on 25 February 2020. See meetbot for the summary or full minutes: https://meetbot.fedoraproject.org/fedora-meeting-2/2020-02-26/workstation.2… Thanks, Allan

2 1

[Fedocal] Reminder meeting : Workstation WG
by catanzaro＠fedoraproject.org 24 Feb '20

24 Feb '20

Dear all, You are kindly invited to the meeting: Workstation WG on 2020-02-25 from 09:30:00 to 10:30:00 US/Eastern At https://bluejeans.com/395383051/ The meeting will be about: Regular meeting for the Workstation Working Group Current Topics: https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting Etherpad: https://etherpad.gnome.org/p/fedora-workstation-wg More information available at: https://fedoraproject.org/wiki/Workstation Source: https://apps.fedoraproject.org/calendar/meeting/9652/

1 0

Re: URGENT: users prompted to upgrade to F32
by Kevin Fenzi 22 Feb '20

22 Feb '20

On Tue, Feb 18, 2020 at 09:33:42PM -0700, Ken Dreyer wrote: > On Mon, Feb 17, 2020 at 10:52 AM Adam Williamson > <adamwill(a)fedoraproject.org> wrote: > > > Since this is an API endpoint of a real system which needs to be > > updated correctly when the release events actually happen, it should > > have the benefits pkgdb used to be (the information should be reliable > > and timely) > > Do we have stats on how many hits per second that current endpoint receives? It looks like it gets less than 100k/day. So, one or less per second. > > It would be a bummer to inadvertently bring down Bodhi because of this feature. Agreed. We should definitely make sure if we switch to this it can handle the load, but it doesn't seem like it will be much of a problem. > > What do you think about having Bodhi write out a flat file to disk or > something for Apache to serve in a similar way, so it doesn't have to > go through mod_wsgi or touch the database for that URL? We could, but I don't think it gets enough traffic to warrent that... Something to discuss with the Bodhi development team. kevin

2 1

25 Feb, MEETING AGENDA
by Chris Murphy 21 Feb '20

21 Feb '20

9:30 am ET 14:30 UTC Location: https://bluejeans.com/395383051/ https://www.bluejeans.com/numbers Announcements: * Outstanding F32 in-progress tasks * Bi-monthly progress updates to help focus on clearing the in-progress queue (or as needed) --- #129 Remove LibreOffice Draw from default install. No objections in ticket, so removal can proceed. https://pagure.io/fedora-workstation/issue/129 --- #107 Reconsider updates policy. We'll punt this until Matthew Miller can show up. https://pagure.io/fedora-workstation/issue/107 --- #121 Support for hibernation? Discuss what's new since last week's #action item. Proposal for F33: "drop swap partition, enable swap-on-ZRAM" This covers: #127 enable swap-on-ZRAM by default #121 Support for hibernation? #120 Anaconda creates way too much swap space Idea is to summarize all three, and thereby make the case in favor of the proposal. If there's consensus to agree, clearing these off the board it makes it easier to revisit #54, #82, #101. If there isn't consensus yet, then we need to better understand the source of hesitation, and ask how to mitigate concerns. -- Chris Murphy

1 0

Re: proposal: Default application functionality criterion reduction
by Adam Williamson 21 Feb '20

21 Feb '20

On Fri, 2020-02-21 at 07:25 -0800, Troy Dawson wrote: > As for those extra applications that you are debating about: > > I figure the word processor (libre-office) would have already been > > checked when you check the Workstation desktop, so I don't feel it has > > to be checked again. It is possible for us to hit desktop-specific issues in applications, it's happened before. So we'd probably still want to do that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

1 0

proposal: Default application functionality criterion reduction
by Kamil Paral 21 Feb '20

21 Feb '20

Yesterday I sent out a QA-related proposal that directly affects the release criteria for KDE x86_64 and Workstation x86_64 and (probably) aarch64 images. The proposal is attached below and also available in the test list (including some follow-ups which are recommended to read): https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/… Can you please review that proposal and post your thoughts, if you have any? (Responding to test list is preferred, so that we can discuss it in a single place, but responding here is fine as well). Thank you. ---------- Forwarded message --------- From: Kamil Paral <kparal(a)redhat.com> Date: Mon, Feb 17, 2020 at 3:20 PM Subject: proposal: Default application functionality criterion reduction To: test <test(a)lists.fedoraproject.org> This proposal intends to reduce the scope of the “*Default application functionality*” release criterion [0]: All applications that can be launched using the standard graphical > mechanism of a release-blocking desktop after a default installation of > that desktop must start successfully and withstand a basic functionality > test. > *= Background =* The area which QA is responsible for has been growing and growing in recent years. We used to have just a single Fedora release with two blocking desktops (GNOME and KDE). Then Editions got introduced and we started testing Workstation, Server, Cloud and the KDE Spin. Additional architectures were introduced (fortunately i386 got obsolete) and we started testing and blocking on specific images on armhfp and aarch64. Currently there are 13 release blocking deliverables mentioned on the ReleaseBlocking page [1]. That list is not complete, though. Fedora CoreOS became an official edition lately, and even though its release cycle is not tied to traditional Fedora release cycle (and that’s why it’s not mentioned on that wiki page), as an official edition QA should care about it as well. It is the same story with Fedora IoT, another recent release-blocking addition [2]. Desktop testing is one of the most time-consuming jobs with the most frequent bug occurrence. Right now, we’re supposed to be fully testing and blocking on GNOME, KDE and XFCE (although XFCE might get dropped in favor or aarch64 Workstation [3]). We cannot test all of this and honestly claim that we verified basic functionality of all the included apps on all these desktops. I believe we need to adjust the criterion and align it closer with reality. In my eyes, it’s better to have a narrower scope and perform it well than having a large scope and perform it poorly. *= Proposal =* Change the criterion to something along these lines: All applications that can be launched using the standard graphical > mechanism after a default installation of Fedora Workstation on x86_64 > architecture must start successfully and withstand a basic functionality > test. > > For other release-blocking desktops (on any architecture), the > requirements only apply to the following types of applications: > > * web browser (e.g. firefox) [4] > > * file browser (e.g. nautilus) > > * package manager (e.g. gnome-software) > > * image viewer (e.g. eog) > > * document viewer (e.g. evince) > > * text editor (e.g. gedit) > > * archive manager (e.g. file-roller) > > * terminal emulator (e.g. gnome-terminal) [4] > > * problem reporter (e.g. abrt) > > If there are multiple applications of the same type (e.g. several web > browsers), only one of them needs to satisfy the requirements. > As you can see, the original criterion was kept for Fedora’s flagship desktop edition, the one that is most prominent on https://getfedora.org and probably the one that most newcomers download. We would still verify everything on Fedora Workstation on x86_64. But any other desktop (including Workstation on aarch64) would get just reduced criteria, because we simply can’t ensure the same quality bar for the smaller desktop editions/spins. There are some high-profile types of applications that I considered including in the list above, but didn’t in the end: * word editor (e.g. libreoffice-writer) * spreadsheet editor (e.g. libreoffice-calc) * video player (e.g. totem) * help viewer (e.g. yelp) I’d like to hear your thoughts on whether they should be included or not. Of course from an end-user point of view, it would be beneficial. But the question is whether we as QA can promise their testing. And also whether we want to block the release e.g. if Gnumeric is broken on armhfp XFCE or if totem doesn’t work on aarch64. Yes, it’s unpleasant, but people using alternative desktops and architectures are usually far from beginners. It’s usually not difficult to install a different application. Also note that the apps included in x86_64 Workstation will be thoroughly tested so they should be very likely to work well even on other architectures (minus some arch-specific issues). I’d like to target Fedora 32 with this proposal, which means we should decide on this proposal fast. (I wanted to propose it much sooner, but I was waiting on clarifications about new release-blocking images and also on some fesco tickets [3], some of which is still not clarified; so I’m sorry about a late proposal). Please comment, thanks. [0] https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria#Default_app… [1] https://fedoraproject.org/wiki/Releases/32/ReleaseBlocking [2] https://pagure.io/fedora-iot/issue/23 [3] https://pagure.io/fesco/issue/2339 [4] These two are required to work even in Basic release criteria [5], but I decided to include them anyway to avoid confusion (“why is the web browser missing?”), and to make it clear that they need to satisfy the basic functionality (whereas for Basic release criteria just the barebone functionality might be deemed enough) [5] https://fedoraproject.org/wiki/Basic_Release_Criteria#Required_applications

1 1

Support for hibernation 2/2: questions
by Chris Murphy 21 Feb '20

21 Feb '20

Continued from the 'background and summary' email: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.o… Adding Hans and Matthew and Lennart to cc. Questions I have are: - WG is considering dropping creation of swap partitions by default, in favor of swap-on-ZRAM. Any concerns? (We do know it's not possible to use a ZRAM device for hibernation, but the kernel will look to another swap device for contiguous free space to write out a hibernation image.) - What's the status of s2idle in the kernel? - What sort of work is needed outside the kernel to properly support s2idle, or is this predominantly kernel work? Microsoft documents on Modern Standby suggest minimal application effort. [1] - Prospect of kernel support to separate swap and hibernation partitions (and/or swap files)? Or systemd method of creating then activating swapfiles on demand? - Prospect of hibernation supported with UEFI Secure Boot? - Is hibernation a better fallback than poweroff, given the significant reliability differential? Why? Poweroff is universal, hibernation isn't. What's the argument that a non-universally available fallback is better than the universal fallback? - What are the implications of hibernation if Fedora will move to measured boot? (I'm not sure how mainstream that function is expected to be, or it's use case specific opt-in.) - There's some anecdotal evidence users are disabling UEFI Secure Boot, possibly quite a lot [2]. Does there need to be an effort at making the signing of user built kernel and module easier? Can it be made easier? I don't know custom or out of tree modules is a significant motive for disabling SB, vs other explanations. - A systemd TODO makes me wonder: Does anyone have (corroborating) data on the reliability of firmware or battery reporting, when the system, and thus the battery, are under significant load? [3] I've discussed with a reliable source that on 2+ year old hardware, the vast majority of batteries are effectively broken and aren't likely to report anything reliably if they are under significant load, in particular waking from S3. By anything, I mean, time remaining, power remaining, and current power consumption rate. Would s2idle instead of S3 would make this more reliable? - It doesn't sound like S1 is really used at all, even though kernel docs say it's supported as shallow/standby. (?) Is it more or less reliable than S3? - I'm inclined to think we should mimic what hardware vendors, Microsoft, Apple, and Google (with Chromebooks and Android) have been doing for a while: faster boots, and S0 low power idle - and skip the things making devs and users crazy. But I invite a persuasive contrary argument. - Any other questions? [1] https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences… [2] https://twitter.com/hughsient/status/1225826488903249920 [3] see line "beef up hibernation" https://github.com/systemd/systemd/blob/master/TODO -- Chris Murphy

5 22

Workstation WG minutes, 18 Feb
by Allan Day 20 Feb '20

20 Feb '20

The Fedora Workstation Working Group had a meeting this week, on 18 February 2020. See meetbot for the summary or full minutes: https://meetbot.fedoraproject.org/fedora-meeting-2/2020-02-20/workstation.2… Thanks, Allan

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop February 2020