desktop March 2020

desktop@lists.fedoraproject.org

23 participants
25 discussions

24 Mar, MEETING AGENDA
by Chris Murphy 20 Mar '20

20 Mar '20

Workstation Working Group Meeting Date and Time: 2020-03-24 9:30 am ET 13:30 UTC Location: https://bluejeans.com/395383051/ https://www.bluejeans.com/numbers = Followups = #107 Reconsider updates policy - Needs assignment = Status Reports = #38 Propose cross-repo recommends dependency from totem to OpenH264 https://teams.fedoraproject.org/project/workstation-wg-1/task/38 = Topics = #82 encryption of user data (excludes system) https://pagure.io/fedora-workstation/issue/82 #136 encryption of system data (excludes user) https://pagure.io/fedora-workstation/issue/136 Review Taiga Kanban https://teams.fedoraproject.org/project/workstation-wg-1/kanban -- Chris Murphy

1 0

F32 Beta: Cursor hot point mis-positioned under Wayland
by Milan Crha 19 Mar '20

19 Mar '20

Hi, I'm not sure where this should be filled, thus starting here. I just installed Fedora-Workstation-Live-x86_64-32_Beta-1.2.iso and booted to the Wayland session and I noticed that selecting text in the gnome-terminal is weird. I opened the terminal and ran `ls -C1` and tried to select some text there and it seems the cursor's hot point (or how it is called) is the left-top corner, while the 'I' cursor uses to have it in its center (both horizontally and vertically). It doesn't do that under X11. An unrelated thing, which might be probably fixed in the final release: The first `dnf update` greeted me with this: Fedora 32 openh264 (From Cisco) - x86_64 86 B/s | 543 B 00:06 Fedora 32 openh264 (From Cisco) - x86_64 1.6 MB/s | 1.6 kB 00:00 Importing GPG key 0x12C944D0: Userid : "Fedora (32) <fedora-32-primary(a)fedoraproject.org>" Fingerprint: 97A1 AE57 C3A2 372C CA3A 4ABA 6C13 026D 12C9 44D0 From : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-32-x86_64 Is this ok [y/N]: That's something I would not expect in this stage. Bye, Milan

4 12

Emerging editions, Fedora 32 Beta, and bureaucracy
by Adam Williamson 17 Mar '20

17 Mar '20

So, today is the Fedora 32 Beta release date. If you examine the release announcement: https://fedoramagazine.org/announcing-the-release-of-fedora-32-beta/ and the current state of the download site: https://getfedora.org/ there are three fairly significant things entirely missing. Those three things are the things that getfedora.org calls our 'Emerging Fedora Editions' - the things that are allegedly the 'future of Fedora': IoT, CoreOS and Silverblue. This is approximately how I currently understand things regarding those editions: 1) Silverblue - this is kind of the simplest. Silverblue is built as part of the regular Fedora composes. Silverblue image builds failed in the actual Beta compose, which was unfortunate but not release-blocking as SB is not yet tagged release-blocking, so the Beta we signed off has no SB images. At the go/no-go and readiness meetings, IIRC, we agreed a rough plan that we would nominate images from a nightly compose built after the packages in Beta had been pushed stable to release alongside the Beta. https://kojipkgs.fedoraproject.org/compose/branched/Fedora-32-20200314.n.0/… should work fine for that purpose, but it seems not everything necessary to actually get that plan implemented has happened, at least not yet - I see no mention of this in the release announcement or on getfedora.org . 2) IoT - as I've been trying to annoy people about for a few weeks now, IoT is not built as part of our main 'Fedora' composes: https://pagure.io/fedora-iot/issue/24 this is a significant difference from just about everything else in Fedora. We have several of these kinda 'variant' composes, but the others are only used to do nightly builds of specific images for stable releases *after* the release happens. For Rawhide and Branched releases, those images are built in the main 'Fedora' compose. IoT is the first and only thing (aside from CoreOS...which we'll get to in a minute) which is being built outside of the 'Fedora' compose for Branched and Rawhide. This means we don't have IoT images in the Beta compose or indeed in any of the main Fedora 32 Branched composes and it falls effectively entirely outside the existing processes for testing and releasing stuff. That wouldn't be a problem if IoT were some unimportant thing we didn't care about, but that doesn't seem to be the case. It also wouldn't be a problem if this had all been figured out ahead of time and a plan had been put in place for how exactly we were going to validate and ship IoT releases, but that doesn't seem to have been the case either. I keep filing tickets and bugging people and there have been some back channel discussions and things, and a few of us as individuals are making up a validation process as we go along as best as we can, but there doesn't seem to be anything on paper aside from https://docs.fedoraproject.org/en-US/iot/edition-promotion/ , which doesn't really address QA and release process stuff much and seems to be rather old. As far as F32 Beta goes, again we roughly decided at Go/No-Go and readiness to identify a specific compose that 'matched' Beta and ship the bits from that - https://kojipkgs.fedoraproject.org/compose/iot/Fedora-IoT-32-20200314.0/com… would seem to fit the bill, and pwhalen has done validation testing on it at https://fedoraproject.org/wiki/User:Pwhalen/QA/IoT/Fedora-IoT-32-20200314.0 , but again this plan doesn't seem to have got as far as getfedora.org or the Beta release announcement. 3) CoreOS - CoreOS is just a *whole* other thing. It is not built like the rest of Fedora at all. It's not built as Pungi composes, whatever compose process it does have doesn't run alongside our other compose processes or output to the same locations, it's like a whole other product. It also doesn't seem to be terribly well documented (I can't find any detail on the wiki, docs sites, or any of the git repos I happen to know of) or even introspectable - for instance, ISO locations look like https://builds.coreos.fedoraproject.org/prod/streams/stable/builds/31.20200… , but if you try and browse around that tree by visiting URLs like https://builds.coreos.fedoraproject.org/prod/streams/ , you just get 'Access Denied'. So if the process appears to have broken down and some poor monkey like me is left trying to help people figure out where they can get a 'Fedora CoreOS 32' image to try - it isn't very easy. Right now I simply have no clue if there is something you could reasonably call 'Fedora CoreOS 32 Beta' or a decent analogue of it. So, in practical terms for Fedora 32 Beta: it would be good if we could complete the plan of identifying SB and IoT nightly images to place alongside the Beta release, and update getfedora.org (and maybe the Beta release announcement) to refer to these. For CoreOS, it would be good if we could...I don't know...do something? To call something 'Fedora CoreOS 32 Beta' and let people install it? Or at least explicitly say that there isn't one for $REASONS? In wider terms: I've been bugging specific people/teams about this in less public channels for a while now, but mattdm said I can be more annoying about it, so now I'm gonna bug people about it in these more public channels! For our so-called Emerging Editions (especially IoT and CoreOS, Silverblue pretty much gets a pass here) - the 'future of Fedora' - we need better process than this. We need more bureaucracy than this! I know bureaucracy isn't exciting and there are always 'real' problems to fix instead. I know our existing compose/test/release process is old-fashioned and unwieldy and monolithic and takes forever. But it has the advantage that it is a complete, end-to-end, more-or-less-fully- documented process that all the teams involved understand. The developers of the existing Editions (and other spins/labs), releng, QA, websites and communications folks all understand the existing sausage factory and all the bits are joined up well enough that when we push the big red button, everything works. The bits get built, the release validation process kicks in, the bits get tested. The Beta release announcement talks about Workstation and Server and the spins and labs. getfedora.org provides download links for them. I totally get that the existing process can be constricting and it's reasonable to want to do things a little differently (IoT) or a lot differently (CoreOS). But if we're gonna do that *and make these things important parts of Fedora and not just sandbox projects*, then we need to start working on making the new way of doing things as well-oiled and integrated with other teams as the old way of doing things. The new processes doen't just have to work for the team that are making the things, they have to work for other teams all the way down the line so that this kind of situation doesn't happen; there needs to be clarity on how we are actually going to build and validate and ship and announce these things. It doesn't have to work the same way we've been doing it the last few years at all. We can experiment with different schedules for different editions, we can experiment with different release approaches that make sense for different products, we can do all kinds of stuff. But in order to do it properly, we need better process. Some specific ideas: FESCo and/or the Council should be taking a stronger lead here. I'd view the Fedora.next process as a good model for this. In Fedora.next there was a really strong model set up for how we were going to create these 'Editions': every Edition had to have a PRD and a tech spec, every edition had to be built and tested and shipped together in the same release process, we had to have release criteria and validation testing for every edition, and all the editions had to be presented together with good strong unified branding on download pages and so on. The whole process of bootstrapping the editions was extensively tracked with issues and meetings and regular status updates and all of that kind of stuff. FESCo kept strong lines of communication between the teams working on the editions and teams like releng and QA and websites and docs so that everyone understood what was happening and what the schedules were and what needed to be done by when. This is what I feel like we're missing with these 'emerging Editions'. I like that as a catch-all for these three things that are obviously important to Fedora's future, but right now all it seems to be is a phrase on the download page. There doesn't seem to be a process for how an 'emerging Edition' becomes a fully-fledged Fedora edition and takes its place alongside (or replaces one of) our existing ones. I can't, for instance, find a FESCo or Council ticket somewhere for 'Fedora IoT becoming an official Edition' where the concrete things necessary to make that actually happen are defined and tracked. No-one has really come to a QA meeting and said "hey, so we have this idea to make IoT and CoreOS fully-fledged, release-blocking Fedora editions in future, how do you think that would look from a QA perspective? What needs to happen? Want to come to a FESCo meeting and talk about it?" and then followed up on it, IIRC. All of that happened for the initial Fedora.next process. I've had various conversations like that informally with individual people, but there is no paper trail, little of it seems to be written down anywhere, and it seems to be very easy for different people to have different understandings of what's going on and what the current status of things is and what the future expectations are. I just went through the last two months of meeting logs for FESCo - https://meetbot-raw.fedoraproject.org/teams/fesco/ - and the Council - https://meetbot-raw.fedoraproject.org/teams/council/ - and unless I'm missing something, the string 'coreos' doesn't appear one time and the string 'iot' appears only in the word "Patriots" in a discussion of the NFL playoffs. This doesn't seem like how things ought to be. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

2 1

Missing LibreOffice Draw menu icon
by Lukas Ruzicka 17 Mar '20

17 Mar '20

Hello, today, I was going through the Workstation menu (20200316.n.0) and I realized, that there is no icon for LibreOffice Draw. Is it a purpose or is it a bug? Thanks for clarifying. -- Lukáš Růžička FEDORA QE, RHCE Red Hat <https://www.redhat.com> Purkyňova 115 612 45 Brno - Královo Pole lruzicka(a)redhat.com TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>

4 6

Workstation WG minutes, 10 March
by Allan Day 17 Mar '20

17 Mar '20

The summary and minutes of last week's Fedora Workstation Working Group meeting can be found here: https://meetbot.fedoraproject.org/teams/workstation/workstation.2020-03-12-… Thanks, Allan

1 0

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

16 Mar '20

Dear all, You are kindly invited to the meeting: Workstation WG on 2020-03-17 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

17 Mar, MEETING AGENDA
by Chris Murphy 15 Mar '20

15 Mar '20

Workstation Working Group Meeting Date and Time: 2020-03-17 9:30 am ET 13:30 UTC Location: https://bluejeans.com/395383051/ https://www.bluejeans.com/numbers = Agenda = 1. Approve minutes 2. Announcements 3. Topic: #107 Reconsider updates policy: Matthew Miller joining 4. Topic: #138 automatically adding new packages when upgrading 5. Status update: #71 Should we include thermald by default? https://pagure.io/fedora-workstation/issues?status=Open&tags=meeting&close_… -- Chris Murphy

1 0

Re: proposal: Default application functionality criterion reduction
by Kamil Paral 12 Mar '20

12 Mar '20

On Mon, Feb 17, 2020 at 3:20 PM Kamil Paral <kparal(a)redhat.com> wrote: > 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 > > > I haven't received much feedback on this proposal. On test list and kde list, there was a short follow-up regarding the list of release-blocking applications. On kde list, Kevin disagreed because it lowers the guaranteed quality bar for KDE, but he didn't continue discussing it with me. I haven't received any alternative proposals either. On desktop list, there was silence, but Chris Murphy gave me a thumbs up on IRC. I'll give it a few more days, and unless somebody yells hard (and ideally also provides some constructive ways how to optimize desktop testing, because we need to cut it down /somehow/), I'll put the change into effect. I'll also probably move the help viewer into the list of release-blocking applications, based on the discussion I saw. Thanks, Kamil Fedora QA

4 6

10 Mar, MEETING AGENDA
by Chris Murphy 10 Mar '20

10 Mar '20

9:30 am ET 14:30 UTC Location: https://bluejeans.com/395383051/ https://www.bluejeans.com/numbers Status reports: #119 enabling earlyoom by default https://pagure.io/fedora-workstation/issue/119#comment-631241 #84 Automatically install the OpenH264 codecs https://pagure.io/fedora-workstation/issue/84 https://pagure.io/releng/issue/9246 - Changes merged. Needs testing. #71 Should we include thermald by default? https://pagure.io/fedora-workstation/issue/71 Topics: #107 Reconsider updates policy https://pagure.io/fedora-workstation/issue/107 - Review the issue, and prepare for 17 Mar meeting with Matthew Miller --- Various installation related issues: https://pagure.io/fedora-workstation/issues?status=Open&tags=installation&c… - Prioritize the issues, form a delegation to meet with Anaconda. --- -- Chris Murphy

1 1

Workstation WG minutes, 3 March
by Allan Day 10 Mar '20

10 Mar '20

The summary and minutes of last week's Fedora Workstation Working Group meeting can be found here: https://meetbot.fedoraproject.org/fedora-meeting-2/2020-03-10/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 March 2020