Related discussion on mailing list: How good is the real quality and reliability of our deliverables?
Summary of discussion so far:
Many of us check / try out betas and RC's according to their respective relevance. So we don't completely "fly blind" or rely exclusively on automated testing (to my relief). For me, it's virtualization, PostgreSQL, Web service; for Stephen it may be Cockpit, Active Directory. I suppose everybody has some areas specifically interested in. Can we gather our special interests and systematize it a little and make sure that key areas are not just automatically tested?
Additionally, we should have a look on our technical specifications and our release criteria (Stephen Gallagher proposed that some times ago) and check automatic testing is OK and where manual testing makes sense, along with a general revisit as Stephen proposed.
Regarding ARM SBC's, several of us have some experiences with it and own one or the other device. I suggest we gather our knowledge and create a set of reference devices that we know basically work with Server (i.e. installable, bootable, network connection, storage, text terminal / keyboard). IoT provides such a list (in a very short form, a bit more detailed information would be desirable).
There seems to be agreement that manual testing is useful / necessary for specific more complex issues, possibly specific for individual changes in a release. Examples would be the change to systemd-resolved or the modularization of libvirt, which led to 'surprises'. We should plan as a routine, around the time the first beta is completed, to go through the list of release changes and check for potential issues and manual testing requirement (and determine who does what).
For some topics worthwhile discussing, see mail from Stephen (Monday, April 19, 2021)
Issue tagged with: pending activity
Some changes that might be worth taking a closer look at (full ChangeSet):
There is a bug opened to add some helpful packages to the distribution media (e.g. dnf-utils, tuned, zsh someting like those).
https://bugzilla.redhat.com/show_bug.cgi?id=2054625
I would propose to postpone this bug to F37 and not to make a substantial change to the DVD composition that late in the release circle (after branching from rawhide), given all the issues we had with the max size of the images.
Metadata Update from @pboy: - Issue tagged with: meeting
Issue tagged with: in progress
Server WG is tracking for the upcoming F36 beta phase:
(1) Ansible 5 (by jwhimpel) - fits everything for our Ansible Prove of Concept project
(2) Cockpit Filesharing (by jwhimpel, cooltshirtguy, xtify21) - new, does it work as expected
(3) DNS Over TLS - possible conflicts with existing configurations
(4) FreeIPA - one of our 2 hard release criteria and specifically features app - does it work as expected
(5) java17-openjdk as system JDK - given that FreeIPA etc is based on JDK - various issues as discussed on mailing list
(6) No ifcfg by default only if it survives beta, otherwise deferred to F37, see FESCo 2022-03.01 - potential conflicts with existing configurations - transition guide
(7) PostgreSQL 14 (by pboy, n.n.) - possible conflicts with existing configurations - does our installation guide fit
(8) openldap upgrade (by eseyman) - no conflict with existing configurations
(9) QEMU/KVM/Libvirt (by pboy, n.n.) - does our Installation doc still fit (including network conf. see no 5) - Compatibility with various VMs - working split DNS name resolution
(10) systemd-resolved - file /etc/resolv.conf a link to ../run/systemd/resolve/stub-resolv.conf - split DNS working with libvirt virtual network (default, virbr0) - split DNS working with NetworkManager virtual bridge over physical interface
(11) Users are administrators by default in Install GUI (by pboy, n.n.) - does it work as expected - no side effects - does out install guide still fit
Issue status updated to: Closed (was: Open)
Metadata Update from @pboy: - Issue untagged with: in progress, meeting, pending activity
Login to comment on this ticket.