This article is focused on package or software testing for OpenMandriva ROME (rolling) and Rock branches. Sometimes a branch is called a release. For ISO testing see this article.
First the simple explanation of packaging workflow is:
Cooker > ROME > Rock
Cooker is development platform where developers and package maintainers upgrade or add packages and where most package fixing is done.
Developers are a most valuable source of testing due to their greater technical knowledge and awareness.
Packages are moved from Cooker to rolling/testing repos by the ABF autobuilder unless a package is in blacklist. For packages in blacklist these are moved manually (or with a script) by the appropriate developer.
This blacklist does not mean something in the list is bad, it is for packages that we have learned should not be done automatically by the autobuilder.
ROME is the rolling release of OMLx.
ROME is designed to be stable and to have up to date software. The ROME branch uses “rolling” repositories.
ROME release would be best choice for most individual users.
Rock is designed for business, servers, and for users that do not like change.
The Rock branch uses “rock” repositories. Rock release or branch by design will get very few software upgrades.
OpenMandriva repositories are not designed to be mixed between branches, this can and usually does cause problems.
It you use ROME use rolling repos only. If you use Rock use rock repos only.
Who or what is QA?
QA or Quality Assurance in most organizations is a team of people devoted to testing the product and seeing to it that issues are acknowledged and corrected to the extent possible.
Functionally in OpenMandriva QA is the entire OM contributor group. Currently this is thought to be the best and wisest use of our resources.
The Contributor Group and by extension QA consists of part-time, unpaid, volunteers. There are no employees.
The contributor group communicates with one another in the OpenMandriva Cooker matrix channel.
The Package Testing Process for ROME and Rock:
The tester enables either the main/testing repo or testing repos for any other repos that tester normally uses. This can be easily done in the Software Repository Selector application (om-repo-picker).
Tester upgrades system on a regular basis. Rolling testers should use dsync rather than upgrade command.
Tester looks at commonly used applications and checks to see that they at least open and have basic function. Tester will pay attention to any loss of function or glitches that may indicate some problem with system or tool-chain packages that were upgraded.
Testers also check applications that they use regularly.
Ideally if tester has time they will check any applications that were upgraded.
Any applications that were know to have been fixed for a forum report or bug report in issue tracker should also be tested.
Testers also test things when specifically asked to do so by Cooker devs.
This happens often in the context of trying to solve issues users report in forum or in issue tracker. This also may happen when a dev has specific concerns about something.
If tester believes they have encountered some new issue typically they will first report this in OpenMandriva Cooker matrix channel and then if issue is at all serious they will file a bug report.
Filing bug reports will also require a Github username and password. For any important or technical issue bug reports are best as this provides a permanent record that is easy for other folks to find. For new bug reports it is a good idea to mention the report in the OpenMandriva Cooker matrix channel.
Tester reporting such an issue then will likely be asked to help test any solutions or workaround that my be forthcoming.
Packages in testing repos are voted on by testers in Kahinah.
You will need a Github account to log in to Kahinah. One may vote to accept or reject a package. Ideally 3 accept votes are required to move a package to rolling/release or rock/updates repo for users. 3 reject votes means the package is rejected for publishing for users. In addition if a package does not get the required 3 votes either way then the package is to be moved after 7 days to rolling/release or rock/updates repo unless a developer or package maintainer tells us not to move a package.
We need more people and hardware for testing in both Rolling and Rock.
Easy ways to enable/disable testing repositories:
Use the om-repo-picker aka: Software Repository Picker.
Note that there is a box specifically to enable testing repos for the repos you normally use:
Another way to do this is to use the --enablerepo option on a per transaction basis. We will use ROME x86_64 as an example:
For main repo only:
sudo dnf --refresh dsync --enablerepo rolling-testing-x86_64
For all 4 commonly used repositories:
sudo dnf --refresh dsync --enablerepo rolling-testing-x86_64 --enablerepo rolling-testing-x86_64-unsupported --enablerepo rolling-testing-x86_64-restricted --enablerepo rolling-testing-x86_64-non-free
To change this for Rock system you change each instance of word rolling to rock.
For znver1 system you change each instance of x86_64 to znver1.
You can create your own copy and paste command and save it in a file somewhere like Documents directory.
To avoid unnecessary problems
Some package groups need to be upgraded or dsynced as a group. These include qt5, qt6, KDE Frameworks, KDE Plasma desktop, and KApps (or KDE Gear). The qt ones are easy to identify the package name begins with qt5 or qt6. The KDE ones are identified by version number. For example KDE Frameworks 5.101.0-2, KDE Plasma desktop 5.26.5-1, or KApps 22.0.12-1. Testing user needs to learn to identify these and install them all at the same time. It is strongly recommended for testing user to wait during such upgrades until the package groups in question are finished before upgrading or dsyncing. Additionally for qt5 or qt6 there can be a lot of other packages that have to rebuilt for changes in qt. In that case it is best to ask.
Note: Sometimes some testing repos are empty and you will get a 404 error. This is normal and expected behavior.
If you want to check the repository to verify this you will need to get the correct URL from the correct .repo file in /etc/yum.repos.d directory.
Another note: Sometimes you might catch a repository right after a new package has been published and while the repodata is being rewritten.
Again this shows a 404 error and can happen with any repo. In this case just wait a bit and try again.
Suggestions to improve this process or the this document are welcome. Please make such suggestions in the English/Development Testing forum. Use a descriptive tile for your forum posts.
In the Resources forum we lock threads to prevent pollution, off topic comments, spam, ect.
This post updated 2023-01-08.