Jump to content

Quality Assurance

From KDE Community Wiki
Revision as of 17:42, 10 July 2022 by Ngraham (talk | contribs) (Create basic QA page)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Quality Assurance is the backbone of user satisfaction, and you can help make it happen for KDE software by joining the QA team!

The QA team has two primary tools to accomplish this goal:

  1. Test merge requests and make sure they work and don't introduce regressions
  2. Use pre-release versions of KDE software and report bugs

Test Merge Requests

To test Merge Requests, you'll compile the relevant piece of KDE software from source code after applying the changes from the merge request to it, and then perform QA. This is described in detail at Infrastructure/GitLab#Testing_someone_else.27s_Merge_Request.


Use pre-release software

By using pre-release versions of KDE software, you'll encounter bugs and regressions before users do. When this happens, file a bug report at https://bugs.kde.org and mark it with the "regression" keyword.

There are a few ways to use pre-release versions of KDE software, and you can choose whichever version works best for you. The following options are ordered from least risky to most risky:

Use nightly Flatpak apps

Nightly builds of all KDE applications are available via Flatpak, using the kde-unstable repo. You can uninstall your distro-provided KDE apps, and install them from the KDE nightly build Flatpak repo instead. This is described at Guidelines_and_HOWTOs/Flatpak

Build everything from source

This approach entails using the kdesrc-build tool to compile all KDE software from source code, and then log into your compiled-from-source Plasma session too. This has the advantage that you can fall back to your distro-provided Plasma session should something go wrong with the built-from-source software. If you are using a rolling or semi-rolling distro, are also doing development activity, and/or are testing a lot of merge requests, this may be the easiest way to go. If you are using a distro that ships very old software, another approach may be preferred. It is described in detail at Get_Involved/development#Building_software_with_kdesrc-build

Use distro-provided pre-release software

KDE Neon Unstable and openSUSE Krypton ship pre-release KDE software by default. Other distros allow you to apply a non-default repo to get pre-release KDE software; a full list can be found at https://community.kde.org/Distributions. Using distro-provided pre-release KDE software for daily use is exceptionally adventurous, but many people do it!