test May 2023

test@lists.fedoraproject.org

12 participants
19 discussions

reversible dual-boot test station
by Chris Murphy 22 Feb '24

22 Feb '24

Hi, I mentioned this in a QA meeting, and have given it enough testing that I think it's broadly usable. If desired it can be copied out of my user account and put up somewhere where QA folks will see it and can modify it as issues or improvements are discovered. What is it? The idea is to produce a system that can confidently be used for baremetal testing, without risking the primary operating system. While VM's are a great way to test, it's also a really idealized environment that tends to not expose an assortment of bugs that affect particular hardware. But then quite a lot of folks reasonably don't want to upgrade their daily use hardware early on, because they don't want to always have to debug things, or have to figure out how to undo the upgrade if it really goes badly. Therefore, I present a dual-boot setup offering: * no re-partitioning; * no installation step, instead system upgrade is used; * reversibility, or undoability, i.e. with just a few steps you can delete the "test OS". https://fedoraproject.org/wiki/User:Chrismurphy/Draft/dualboot_teststation -- Chris Murphy

2 5

Re: Thoughts welcome: interface between automated test gating and the "critical path"
by Adam Williamson 16 Aug '23

16 Aug '23

On Fri, 2022-09-02 at 08:37 +0000, Zbigniew Jędrzejewski-Szmek wrote: > > > > Now, because I glued openQA to the critpath because it was handy, there > > are two sets of consequences to a package being in critical path: > > > > 1. Tighter Bodhi requirements > > 2. openQA tests are run, and results gate the update (except Rawhide) > > > > So, one of the implicit questions here is, is it OK to keep twinning > > these two sets of consequences, or should we split them up? Splitting > > them up kinda implies answer 2) from my original mail: "Keep the > > current "critical path" concept but define a broader group > > of "gated packages" somewhere". Because we would then need some new > > concept that isn't "critical path". As I said, that's more *work* - > > it'd require us to write new code in several places[0]. Even if we > > decide it'd be nice to do this, is it nice *enough* to be worth doing > > that work? > > I'd still vote for keeping a single critpath list and using it as > "the list of packages that require extra care and testing". > > As you describe, the original meaning of critpath has shifted, but > it's because the way we do updates and QA has also shifted. Doing > gating tests for a package seems much more useful than just keeping > it longer in 'updates-testing' in hope that somebody discovers an > important regresion in the second week. Well, there's a caveat there - openQA doesn't test everything. On the whole we cover quite a lot with the set of tests that gets run on updates, but there's certainly lots of potential for there to be important bugs it misses, that a human tester might catch. So I think there is still a case for the higher karma requirements too. > > So yeah, I don't think it makes sense to do the extra work to split > the concepts. Also because we have way too many concepts and processes > in Fedora already. On the whole, though, I agree with you. I just don't trust my own opinion because it's obviously biased by what's convenient for me. :D > > If we don't think it's worth doing that work, then we're kinda stuck > > with openQA glomming onto the critpath definition to decide which > > updates to test and gate, because I don't have any other current viable > > choices for that, really. And we'd have to figure out a critpath > > definition that's as viable as possible for both purposes. > > > > > > BTW, one other thought I've had in relation to all this is that we > > could enhance the current critpath definition somewhat. Right now, it's > > built out of package groups in comps which are kinda topic-separated: > > there's a critpath-kde, a critpath-gnome, a critpath-server, and so on. > > But the generated critical path package list is a monolith: it doesn't > > distinguish between a package that's on the GNOME critpath and a > > package that's on the KDE critpath, you just get a big list of all > > critpath packages. It might be nice if we actually did distinguish > > between those - the critpath definition could keep track of which > > critpath topic(s) a package is included in, and Bodhi could display > > that information in the web UI and provide it via the API. That way > > manual testers could get a bit more info on why a package is critpath > > and what areas to test, and openQA could potentially target its test > > runs to conserve resources a bit, though this might require a bit more > > coding work on the gating stuff now I think about it. > > That sounds useful. We only need a volunteer to figure out the details > and do the work ;) I actually did a huge rewrite of the thing that generates the critpath data this week, and it probably wouldn't be tooooo much work, honestly. The most annoying bit would be the Bodhi frontend stuff, but that's because I'm bad at frontend dev in general. :P But yeah, this is definitely off in sky-castle land. I'll add it to my ever-growing list of sky-castle projects to do when I get a couple of years of spare time... -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

3 4

new criterion proposal: toolbox functionality
by Sumantro Mukherjee 26 Jun '23

26 Jun '23

Related to a recently proposed blocker [0], I propose a new release criterion which would cover that case. There is a push from the Dekstop team to have toolbox as a default app in the installer iso as well. Here it is: ~~~~~~~~~~~~ Toolbox aka Toolbx should be usable. Toolbox should be able to list, create and provide the desired containerized environment to the user without root privileges. Toolbox images should be generally functional. Footnote - "What does this cover?": Toolbox's general functionality as covered by this test cases https://fedoraproject.org/wiki/QA:Testcase_toolbox ~~~~~~~~~~~~~ I think this criterion could target F39 Beta Release Criteria or Basic Release Criteria [2]. Please tell me your thoughts, thanks! [0] https://bugzilla.redhat.com/show_bug.cgi?id=2183038 [1] https://fedoraproject.org/wiki/Basic_Release_Criteria -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED

6 25

Plan / proposal: enable openQA update testing and potentially gating on Rawhide updates
by Adam Williamson 09 Jun '23

09 Jun '23

Hi folks! We've had openQA testing of updates for stable and branched releases, and gating based on those tests, enabled for a while now. I believe this is going quite well, and I think we addressed the issues reported when we first enabled gating - Bodhi's gating status updates work more smoothly now, and openQA respects Bodhi's "re-run tests" button so failed tests can be re-triggered. A few weeks ago, I enabled testing of Rawhide updates in the openQA lab/stg instance. This was to see how smoothly the tests run, how often we run into unexpected failures or problems, and whether the hardware resources we have are sufficient for the extra load. So far this has been going more smoothly than I anticipated, if anything. The workers seem to keep up with the test load, even though one out of three worker systems for the stg instance is currently out of commission (we're using it to investigate a bug). We do get occasional failures which seem to be related to Rawhide kernel slowness (e.g. operations timing out that usually don't otherwise time out), but on the whole, the level of false failures is (I would say) acceptably low, enough that my current regime of checking the test results daily and restarting failed ones that don't seem to indicate a real bug should be sufficient. So, I'd like to propose that we enable Rawhide update testing on the production openQA instance also. This would cause results to appear on the Automated Tests tab in Bodhi, but they would be only informational (and unless the update was gated by a CI test, or somehow otherwise configured not to be pushed automatically, updates would continue to be pushed 'stable' almost immediately on creation, regardless of the openQA results). More significantly, I'd also propose that we turn on gating on openQA results for Rawhide updates. This would mean Rawhide updates would be held from going 'stable' (and included in the next compose) until the gating openQA tests had run and passed. We may want to do this a bit after turning on the tests; perhaps Fedora 37 branch point would be a natural time to do it. Currently this would usually mean a wait from update submission to 'stable push' (which really means that the build goes into the buildroot, and will go into the next Rawhide compose when it happens) of somewhere between 45 minutes and a couple of hours. It would also mean that if Rawhide updates for inter-dependent packages are not correctly grouped, the dependent update(s) will fail testing and be gated until the update they depend on has passed testing and been pushed. The tests for the dependent update(s) would then need to be re- run, either by someone hitting the button in Bodhi or an openQA admin noticing and restarting them, before the dependent update(s) could be pushed. In the worst case, if updated packages A and B both need the other to work correctly but the updates are submitted separately, both updates may fail tests and be blocked. This could only be resolved by waiving the failures, or replacing the separate updates with an update containing both packages. All of those considerations are already true for stable and branched releases, but people are probably more used to grouping updates for stable and branched than doing it for Rawhide, and the typical flow of going from a build to an update provides more opportunity to create grouped updates for branched/stable. For Rawhide the easiest way to do it if you need to do it is to do the builds in a side tag and use Bodhi's ability to create updates from a side tag. As with branched/stable, only critical path updates would have the tests run and be gated on the results. Non-critpath updates would be unaffected. (There's a small allowlist of non-critpath packages for which the tests are also run, but they are not currently gated on the results). I think doing this could really help us keep Rawhide solid and avoid introducing major compose-breaking bugs, at minimal cost. But it's a significant change and I wanted to see what folks think. In particular, if you find the existing gating of updates for stable/branched releases to cause problems in any way, I'd love to hear about it. Thanks folks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

3 4

introduction
by fedtest＠post.carik.tech 02 Jun '23

02 Jun '23

hello all, I'm very glad to apply to volunteer at the Fedora Test Team. I first installed Red Hat in 1998 and have been an exclusive Linux user ever since, now my everyday linux distros are both fedora and arch (I like having options) but predominantly fedora. it's well past time I contributed something back to the project other than ad-hoc testing such as 6.3.1 recently I am retired 20 years, live in Ireland and have time to spare I'm known as ffyon or grumpy or both FAS - grumpyffyon irc.libera.chat - ffyon | grumpyffyon email - fedtest at post.carik.tech cheers

2 1

DNF5 is in f38 updates-testing ?????
by Ian Laurie 31 May '23

31 May '23

I was under the impression DNF5 was being held of until F39? https://bodhi.fedoraproject.org/updates/FEDORA-2023-b3c645d401 -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney

3 2

Rawhide ~ only partial swap to DNF5?
by Ian Laurie 30 May '23

30 May '23

I usually run DNF via an automation script of mine, and I noticed it complained there was no /etc/dnf/dnf.conf file available (my script checks it and warns if there are active excludes in it). My dnf.conf had become dnf.conf.rpmnew which is why my automation script complained. However /usr/bin/dnf was still pointing at dnf-3, not dnf5. So it disabled my config for dnf-3 but didn't migrate me over all the way to dnf5? Should I manually point the dnf link to dnf5? As a separate issue, I do have an active exclude (coreutils, pending a revert of a recent change that introduced an undesirable feature). Where does one put the "exclude=coreutils" in a dnf5 world? Note right now I don't have a functioning /etc/dnf/dnf.conf file (it got renamed to dot rpmnew) Ian -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney

2 2

2023-05-29 - Fedora QA Meeting - Minutes
by Adam Williamson 29 May '23

29 May '23

================================== #fedora-meeting: Fedora QA meeting ================================== Meeting started by adamw at 15:04:54 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2023-05-29/fedora-qa.2023-… . Meeting summary --------------- * Roll Call (adamw, 15:05:05) * Do we need a meeting? (adamw, 15:15:26) * I don't have anything very important (adamw, 15:15:35) * dnf5 is currently replacing dnf in Rawhide, expect some turbulence, and please test and report any issues you come across (adamw, 15:15:50) * prod wiki will be down for upgrade on wednesday afternoon (NA time) (adamw, 15:19:37) Meeting ended at 15:28:45 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * adamw (21) * zodbot (8) * geraldosimiao (5) * lruzicka (4) * nirik (2) * kparal (1) Generated by `MeetBot`_ 0.4 .. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

1 0

2023-05-29 @ 15:00 UTC - Fedora QA Meeting
by Adam Williamson 28 May '23

28 May '23

# Fedora Quality Assurance Meeting # Date: 2023-05-29 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.libera.chat Greetings testers! It's meeting time again! If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 39 status 3. Test Day / community event status 4. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

1 0

Does kernel-6.3.x bring IBT protection to Fedora?
by Ian Laurie 20 May '23

20 May '23

I cannot load any VirtualBox VM on my i7 hardware running any 6.3.x kernel, and sometimes trying to do it locks up the system requiring the power to be pulled (that's an issue in itself). However I am able to run VMs wirh kernel 6.3.x on some different hardware at work that uses old Xeon E5-2603 v2 CPUs. I found this bug entry talking about IBT protection: https://www.virtualbox.org/ticket/21435 Adding "ibt=off" to the kernel line when booting seems to have fixed it. Did Fedora turn on IBT checking with 6.3.2/6.3.3 ? RPM Fusion VB bug: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6688 Has 6.3.x destroyed VirtualBox for anyone else? Ian -- Ian Laurie FAS: nixuser | IRC: nixuser TZ: Australia/Sydney

1 0

2023-05-15 - Fedora QA Meeting - Minutes
by Adam Williamson 15 May '23

15 May '23

================================== #fedora-meeting: Fedora QA meeting ================================== Meeting started by adamw at 15:05:55 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2023-05-15/fedora-qa.2023-… . Meeting summary --------------- * Roll Call (adamw, 15:06:14) * Previous meeting follow-up (adamw, 15:09:25) * "adamw to migrate release criteria from the wiki to docs.fp.o" - this one was mostly a joke that wound up in the minutes. i didn't do it yet. :D (adamw, 15:09:54) * Toolbox criteria proposal (adamw, 15:11:43) * Fedora 39 status (adamw, 15:25:14) * fedora 39 is fairly stable atm, tests are passing. F39 changes are starting to build up at https://fedoraproject.org/wiki/Releases/39/ChangeSet , we should do a review soon (adamw, 15:29:39) * Test Day / community event status (adamw, 15:35:32) * kernel 6.3 test week recently concluded: https://fedoraproject.org/wiki/Test_Day:2023-05-07_Kernel_6.3_Test_Week , https://testdays.fedoraproject.org/events/157 (adamw, 15:36:33) * we're still working on the Fedora 39 Test Day slate, stay tuned! (adamw, 15:38:10) * Open floor (adamw, 15:38:15) Meeting ended at 15:44:01 UTC. Action Items ------------ Action Items, by person ----------------------- * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * adamw (36) * zodbot (9) * lruzicka (8) * kparal (7) * tflink[m] (2) * coremodule (1) Generated by `MeetBot`_ 0.4 .. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

1 0

2023-05-15 @ 15:00 UTC - Fedora QA Meeting
by Adam Williamson 14 May '23

14 May '23

# Fedora Quality Assurance Meeting # Date: 2023-05-15 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.libera.chat Greetings testers! It's meeting time again! If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Toolbox criteria proposal 3. Fedora 39 status 4. Test Day / community event status 5. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

1 0

In fedora 38, after installed libpqxx from postgresql.org, cannot install vtk-devel
by wang_chen 10 May '23

10 May '23

# dnf install vtk-devel Last metadata expiration check: 0:05:17 ago on Thu May 11 05:59:18 2023. Error: Problem: package vtk-devel-9.2.5-2.fc38.i686 requires libpq-devel(x86-32), but none of the providers can be installed - conflicting requests - libpq-devel-15.0-3.fc38.i686 has inferior architecture - package vtk-devel-9.2.5-2.fc38.x86_64 requires libpq-devel(x86-64), but none of the providers can be installed - package libpq-devel-15.0-3.fc38.x86_64 requires libpq(x86-64) = 15.0-3.fc38, but none of the providers can be installed - problem with installed package libpq5-15.2-42.1PGDG.f38.x86_64 - installed package libpq5-15.2-42.1PGDG.f38.x86_64 obsoletes libpq provided by libpq-15.0-3.fc38.x86_64 - package libpq5-15.2-42.1PGDG.f38.x86_64 obsoletes libpq provided by libpq-15.0-3.fc38.x86_64 (try to add '--skip-broken' to skip uninstallable packages) [root@robot pgsql]# dnf list libpq* --installed Installed Packages libpq5.x86_64 15.2-42.1PGDG.f38 @pgdg-common libpq5-devel.x86_64 15.2-42.1PGDG.f38 @pgdg-common libpqxx.x86_64 1:7.7.5-10.f38 @pgdg-common libpqxx-devel.x86_64 1:7.7.5-10.f38 @pgdg-common

2 1

Full system freeze when testing 6.3.1 with amd_pstate=active
by Christopher Klooz 08 May '23

08 May '23

I started to run 6.3.1. on my system* today with amd_pstate=active (...hoping it solves some issues I have on my hardware, see the bug ticket below). The issue of today with 6.3.1.: it worked properly most of the day, but when the system was not used several minutes, it completely froze with Firefox and some other applications open (CTRL+ALT+F* did not respond as well). I attached the "journalctl -r --boot=-1" after I force-rebooted. However, I cannot exclude that it is related to an open ticket (this "symptom" is not new with 6.3.1 on my hardware), but *the logs of this time with 6.3.1 with amd_pstate=active (see attachment) differ* to the logs of the earlier issues: see https://bugzilla.redhat.com/show_bug.cgi?id=2193110 (I don't think at this time that this is caused by firefox, but firefox may has some unintended behavior that triggers the issues). I now switched to amd_pstate=passive but remain with 6.3.1 to see how it develops. My "feeling" of the day is that 6.3.1 is still more stable than 6.2. Maybe the logs are indicative for you. Concerning the SELinux denials (to which I see no relation in this issue): the user account is a SELinux confined user sysadm_u. * Lenovo Thinkpad T16 AMD, AMD Ryzen 7 PRO 6850U, Fedora KDE spin, tainted=0, only default repos/software. Regards, Chris (py0xc3)

1 1

Kernel 6.3 Test Week 2023-05-07
by Sumantro Mukherjee 05 May '23

05 May '23

Hey All, I would like to invite all of you to participate in the Kernel 6.3 Test week is happening from 2023-05-07 to 2023-05-14. It's fairly simple, head over to the wiki [0] and read in detail about the test week and simply run the test case mentioned in[1] and enter your results. As usual, the Fedora QA team will hangout at #fedora-test-day(a)libera.chat for question and discussion. [0] http://fedoraproject.org/wiki/Test_Day:2023-05-07_Kernel_6.3_Test_Week [1] https://testdays.fedoraproject.org/events/157 -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED

2 1

F39 Rawhide: GNOME on XORG: Legacy applications have Windows title bar different than Native Gnome Applications
by Dario Lesca 04 May '23

04 May '23

Start with last rawhide iso: (Fedora-Workstation-Live-x86_64-Rawhide-20230503.n.0.iso) set password to user liveuser an logout. Login with liveuser and select "GNOME on Xorgs", open libreoffice or firefox and nautilus or gnome-termonal. The title of firefox is different than Nautilus. Also the Middle-Click mouse button, set to "lower" via gnome-tweaks, if pressed on title bar DO NOT WORK on legacy windows. I have fill this bug: https://bugzilla.redhat.com/show_bug.cgi?id=2192180 See also: "In GNOME 44, window top bar doesn't work properly under Xorg" https://www.reddit.com/r/gnome/comments/12ubuya/in_gnome_44_window_top_bar_… -- Dario Lesca (Inviato dal mio Linux Fedora 38 Workstation)

1 0

[Testdays] Call for Fedora Linux 39 testing events
by Sumantro Mukherjee 02 May '23

02 May '23

Hi Fedora users, developers, and friends! It's time to start thinking about Test Days for Fedora 39. For anyone who isn't aware, a Test Day is an event usually focused around IRC for interaction and a Wiki page for instructions and results, with the aim being to get a bunch of interested users and developers together to test a specific feature or area of the distribution. You can run a Test Day on just about anything for which it would be useful to do some fairly focused testing in 'real time' with a group of testers; it doesn't have to be code, for instance, we often run Test Days for l10n/i18n topics. For more information on Test Days, see https://fedoraproject.org/wiki/QA/Test_Days . Anyone who wants to can host their own Test Day, or you can request that the QA group helps you out with organization or any combination of the two. To propose a Test Day, just file a ticket in fedora-qa pagure - here's an example https://pagure.io/fedora-qa/issue/624 . For instructions on hosting a Test Day, see https://fedoraproject.org/wiki/QA/SOP_Test_Day_management . You can see the schedule at https://pagure.io/fedora-qa/issues?tags=test+days . There are many slots open right now. Consider the development schedule, though, in deciding when you want to run your Test Day - for some topics you may want to avoid the time before the Beta release or the time after the feature freeze or the Final Freeze. We normally aim to schedule Test Days on Thursdays; however, if you want to run a series of related Test Days, it's often a good idea to do something like Tuesday / Wednesday / Thursday of the same week (this is how we usually run the X Test Week, for instance). If all the Thursday slots fill up but more people want to run Test Days, we will open up Tuesday slots as overflows. And finally, if you really want to run a Test Day in a specific time frame due to the development schedule, but the Thursday slot for that week is full, we can add a slot on another day. We're flexible! Just put in your ticket the date or time frame you'd like, and we'll figure it out from there. If you don't want to run your own Test Day, but you are willing to help with another, feel free to join one or more of already accepted Test Days: GNOME Test Day* i18n Test Day* Kernel Test Week(s)* Upgrade Test Day* IoT Test Week* Cloud Test Day* Fedora CoreOS Test Week* And don't be afraid, there are a lot of more slots available for your own Test Day! [*] These are the test days we run generally to make sure everything is working fine, the dates get announced as we move into the release cycle. If you have any questions about the Test Day process, please don't hesitate to contact me or any member of the Fedora QA team on test at lists.fedoraproject.org or in #fedora-qa on IRC. Thanks! -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED

3 2

2023-05-01 - Fedora QA Meeting - Minutes
by Adam Williamson 01 May '23

01 May '23

================================== #fedora-meeting: Fedora QA meeting ================================== Meeting started by adamw at 15:00:37 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting/2023-05-01/fedora-qa.2023-… . Meeting summary --------------- * Roll Call (adamw, 15:00:47) * Previous meeting follow-up (adamw, 15:06:05) * no action items at last meeting (adamw, 15:06:51) * ACTION: adamw to migrate release criteria from the wiki to docs.fp.o (bcotton, 15:11:23) * Fedora 38 and 39 check-in (adamw, 15:18:13) * Fedora 38 seems to be going over generally well, there's a potential issue with upgrades crashing, see https://bugzilla.redhat.com/show_bug.cgi?id=2187837 and preserve all logs if you encounter this (adamw, 15:35:03) * Fedora 39 (Rawhide) is fairly stable at present (adamw, 15:35:14) * Test Day / community event status (adamw, 15:35:28) * the call for Test Days has gone out, please go ahead and file a ticket if you'd like to propose a Test Day for Fedora 39 cycle: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.o… (adamw, 15:36:16) * Open floor (adamw, 15:41:59) Meeting ended at 15:47:27 UTC. Action Items ------------ * adamw to migrate release criteria from the wiki to docs.fp.o Action Items, by person ----------------------- * adamw * adamw to migrate release criteria from the wiki to docs.fp.o * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * adamw (55) * bcotton (15) * zodbot (9) * tflink[m] (6) * coremodule_ (3) * nirik (1) Generated by `MeetBot`_ 0.4 .. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

1 0

2023-05-01 @ 15:00 UTC - Fedora QA Meeting
by Adam Williamson 01 May '23

01 May '23

# Fedora Quality Assurance Meeting # Date: 2023-05-01 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.libera.chat Greetings testers! It's meeting time again! Sorry for the late notice on this; I was away for the weekend without any device that's set up to send Fedora emails... If anyone has any other items for the agenda, please reply to this email and suggest them! Thanks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 38 and 39 check-in 3. Test Day / community event status 4. Open floor -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org https://www.happyassassin.net

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test May 2023