F32 Beta: Cursor hot point mis-positioned under Wayland
by Milan Crha
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 years, 1 month
Emerging editions, Fedora 32 Beta, and bureaucracy
by Adam Williamson
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....
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/c...
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.202...
, 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
4 years, 1 month
Missing LibreOffice Draw menu icon
by Lukas Ruzicka
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 years, 1 month
Re: proposal: Default application functionality criterion reduction
by Kamil Paral
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_a...
>
> [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 years, 1 month
