Fedora test days are events where anyone can help make sure changes in Fedora Linux work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed to Fedora Linux before, this is a perfect way to get started.
There are three upcoming test events in the coming weeks.
- Thursdy, October 07 , is to test Upgrade.
- Friday, October 08 , is test Virtualization.
- Monday,October 11 and Tuesday October 12 is to test Cloud
- Monday, October 11 through October 15 is to test Fedora IoT
- Monday, October 11 through October 15 is to test Fedora CoreOS
Come and test with us to make Fedora Linux 35 even better. Read more below on how to do it.
Upgrade test day
As we come closer to Fedora Linux 35 release dates, it’s time to test upgrades. This release has a lot of changes and it becomes essential that we test the graphical upgrade methods as well as the command line. As a part of this test day, we will test upgrading from a full updated, F33 and F34 to F35 for all architectures (x86_64, ARM, aarch64) and variants (WS, cloud, server, silverblue,kinoite, IoT).
This test day will happen on Thursday, October 07
Virtulization test day
We are going to test all forms of virtualization possible in Fedora. The test day will focus on testing Fedora or your favorite distro inside a bare metal implementation of Fedora running Boxes, KVM, VirtualBox and whatever you have. The general features of installing the OS and working with it are outlined in the test cases which you will find on the results page.
This will be happening on Friday, October 08.
Cloud test day
Now that the Fedora Beta is officially released, the Fedora Cloud SIG would like to get the community together this week to find and squash some bugs. We are organizing a test day for Monday, October 5th.For this event we’ll test Fedora Cloud Base content. See the Wiki Page for links to the Beta Cloud Base Images. We have qcow, AMI, and ISO images ready for testing.
This will be happening on Monday, October 11, and October 12.
IoT test Week
For this test week, the focus is all-around; test all the bits that come in a Fedora IoT release as well as validate different hardware. This includes:
- Basic installation to different media
- Installing in a VM
- rpm-ostree upgrades, layering, rebasing
- Basic container manipulation with Podman.
We welcome all different types of hardware, but have a specific list of target hardware for convenience.
This will be happening the week of Monday, October 11 to Friday, October 15.
Fedora CoreOS test week
The Fedora CoreOS team released the first Fedora CoreOS next stream based on Fedora 35. They expect to promote this to the testing stream in two weeks, on the usual schedule. As a result, the Fedora CoreOS and QA teams have organized a test week. Refer to the wiki page for links to the test cases and materials you’ll need to participate.
It begins Monday, October 11,2021 and runs through the end of the week.
How do test days work?
A test day or week is an event where anyone can help make sure changes in Fedora Linux work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. Test days are the perfect way to start contributing if you not in the past.
The only requirement to get started is the ability to download test materials (which include some large files) and then read and follow directions step by step.
Detailed information about all the test days are on the wiki page links provided above. If you are available on or around the days of the events, please do some testing and report your results.
I hope that easy instructions will follow and so the testing show can go on. I will help with testing like now with Fedora 35 Beta.
I think I’m in the MP movie the “Holy Grail”, Where 3=5
No , you’re not. It’s just 3 different test happens in one event starting on Monday, October 11.
“There are three upcoming test events in the coming weeks” then it lists 5 test events, that’s what I meant with the reference to Monty Python’s Quest for the Holy Grail. Alas, when humor is needed to be explained it is no longer funny.
“Test days are the perfect way to start contributing if you not in the past.”
Damn, I’d love to help but I’m still in 2009.
Leslie Satenstein, Montreal,Que
Will I be able to test the documentation? The Fedora documentation for installation was really just a global change from 33 to 34, and with many mixed spellings , eg disc disk, (to name two), as well as obsolete Fedora 21 stuff.
I have rewritten 100 pages of the Fedora 34 install guide documentation to add commas, to stop run-on sentences, and the like. I tried to make it available, but disappointedly, there is no interest.
However, I can put the document (libreoffice .odtformat), which can easily be converted to asciidoc format to a shared location. I and much of the world uses libreoffice.*, but disappointedly, few who use Fedora use asciidoc. My sharing will be via a git repository with a LibreOffice format file.
There is interest! We just need you to submit your changes as pull requests.
Hey Leslie. I see that you “forked” the installation guide three years ago but you do not appear to have ever submitted any pull requests. You are half way there! Maybe I can help you get the rest of the way to submitting a successful PR with the below instructions?
1. Clone your copy (“fork”) from pagure.io and bring it up to speed with the current (“upstream”) version that Fedora is using.
$ cd install-guide
$ git remote add upstream https://pagure.io/fedora-docs/install-guide.git
$ git pull --rebase upstream master
$ git push
2. Generate a preview of your local copy to be sure it is good (use Ctrl+C to terminate the preview).
3. Create a local “branch”. The main branch is called “master”. But you will want to create a temporary one for each changeset that you want to submit as a pull request. Keep your changesets small so they are more likely to be accepted. Use ‘git status’ at any time to see what branch you are on (or ‘git branch’ to list all branches).
4. Correct an error.
4.5. If you want to revert/undo changes made to a file before they are “commited” to the repository, you can do so with the ‘git checkout <filename>’ command.
5. Verify your changes.
6. If everything looks good, commit your changes with a brief note about what was changed and push your new branch back up to your fork on pagure.io.
$ git push
7. Your new branch with the changes should show up on your fork of the project on pagure.io. There should also be a button to submit your branch as a new pull request to the original (“upstream”) copy of the project. You can delete your temporary branch after the PR has been accepted and then you will want to rerun ‘git pull ‐‐rebase upstream master’ to resync your local “master” branch with the upstream version.
Hope that helps and thanks for contributing!
Leslie Satenstein, Montreal,Que,
Here is what happened historically.
My background is 15+ years of Fedora (pre-core to Fedora 35 + some Fedora 36/Rawhide). I have 60 years in IT, and experience with technical writing. When I tried to submit past work, the upload was entirely refused because the thought was that LibreOffice was not the right/official software tool.
My rework of a section of the installation guide was done using LibreOffice and the “track changes and commenting” options.
What I marked up was the grammar, some corrections about topics and some other corrections.
Fedora had chosen asciidoc as the tool, It is definitely a good final publishing product, but definitely not as good for collaboration by one or more users, or for document maintenance
What is track changes?
Libreoffice/MSword track changes, is compatible with MSoffice. as well as adding comments to document. The difference between using LibreOffice and asciidoc is script processing. LibreOffice output format includes *pdf, epubs, web etc and *odt.
“Track changes” allows a user to add/modify/delete mark text. The revised changes are marked in a way that a second person could review and accept, reject or even revise the markups.
With track changes, a clean document can usually be completed, generally with two, or occasionally with three reviews.
Both Asciidoc and LibreOffice can have top level and support #include “files” so that chapters of writing could be done by experts for that technical area covered by Fedora
I still have my old stuff, but again, if I can’t use LibreOffice to do the markups and for collaboration, then I have other wonderful projects to work on.
If you are not familiar with track changes, may I suggest you send me an email address and I will forward one section that I edited.
For what it is worth mentioning, I posted on several forums, the idea of collaborating on producing a clean maintainable document. In the 6 weeks I had the requests, there was zero responses. People like to use a project, but rarely like to give back to the project.
I can plop the stuff into a git repository. You have my email address below. I am also a member of the “fedora forum website” at fedoraforum.org
I’m not really that familiar with the “behind-the-scenes” infrastructure that the Fedora Project uses. But I think there are quite a few components (both software and documentation) that are heavily vested in the pagure/git workflow. I’m not surprised that there isn’t much interest in adopting other systems. As for tracking changes, part of the problem with LibreOffice may be authorization and authentication. How do you know that the person who claimed they made a change is who they say they are? Or how do you otherwise verify the authenticity of the document? The existing system that the Fedora Project uses is deeply integrated with the Fedora Account System (FAS) so that permissions/groups and authentication can be easily managed.
Leslie Satenstein, Montreal,Que,
Before I convert my doc to your format, please review (my marked up section).
I just skimmed the first few pages and, to me, it looks superb. The changes will need to be merged with other changes that have already been made though. For example, on Fri Aug 27 03:10:01 2021 +0000 Petr Bokoc changed MacOS to macOS. I think the only practical way to merge the changes at this point is to submit them individually through the git system.
I see that you have some verbose explanations for your changes. You can put those in your git commits too. To do so, omit the “-m ‘<short commit note>’” part from the “git commit -a …” command and you should be presented with a text editor where you can enter a more verbose commit message. The first line will be the title text for the commit. After the first line, leave a single blank line and then enter the remaining paragraphs in “block indentation” style. Use ‘git log‘ to see examples of the commit messages from others (and to review your own before pushing them back up to the server).
October 07 , is to test Upgrade.
F35 no sund:(
Sound Blaster Z card
Try a new install using netinstall iso instead of live.iso
The test install does not include a Hungarian language option. I hope it will be included in the full version
Just a quick thought – It looks like (possibly) easier updating of documentation may be achievable (that is to say, easier upstream sharing of updates) by using Atom instead of LibreOffice for editing. See https://atom.io/
Tried it and it sure seems to be handy. Cheers all.