From Fedora Project Wiki

(add a tip about yum distro-sync)
 
(43 intermediate revisions by 19 users not shown)
Line 1: Line 1:
{{header|qa}}
{{header|qa}}
__NOTOC__


The '''updates-testing''' repository, also referred to as '''Test Updates''', contains updates scheduled to be released for the maintained releases of Fedora. User testing and feedback provided via [http://bodhi.fedoraproject.org Bodhi], on the [https://admin.fedoraproject.org/mailman/listinfo/test test] mailing list and the relevant [http://bugzilla.redhat.com Bugzilla] is vital to ensure that good updates are released quickly and bad ones kept away from release. <!--Proven testers dormant as of 2013-02-05: If you are interested in doing this testing, please also consider becoming a [[Proven_tester|proven tester]]. Feedback from proven testers is required for [[Critical_Path_Packages_Proposal|critical path]] package updates, so this is a vital task.-->
{{autolang|base=yes}}


== Using the updates-testing repository ==
The [[Repositories#updates-testing|'''updates-testing''' repository]], also referred to as '''Test Updates''', contains updates scheduled to be released for [[Releases/Branched|Branched]] pre-releases (after the [[Updates Policy#Bodhi enabling|Bodhi enabling point]]) and stable releases of Fedora.<del> The [[Repositories#updates-testing-modular|'''updates-testing-modular''' repository]] is the equivalent repository for module updates.</del>* User testing and feedback provided via [http://bodhi.fedoraproject.org Bodhi], on the [https://admin.fedoraproject.org/mailman/listinfo/test test] mailing list and the relevant [http://bugzilla.redhat.com Bugzilla] is vital to ensure that good updates are released quickly and bad ones kept away from release.<br><br>'''*No longer include fedora-repos-modular in default installations since F39.'''  <!--Proven testers dormant as of 2013-02-05: If you are interested in doing this testing, please also consider becoming a [[Proven_tester|proven tester]]. Feedback from proven testers is required for [[Critical_Path_Packages_Proposal|critical path]] package updates, so this is a vital task.-->


=== Enabling the repository permanently ===
== Using the updates-testing repositories ==


The following command with enable the repository permanently
=== Enabling the repositories permanently ===


<pre> yum-config-manager --enable updates-testing </pre>
With dnf (Fedora 22 and later):


If you wish to disable it again, run the following command
dnf config-manager --set-enabled updates-testing
<del>dnf config-manager --set-enabled updates-testing-modular</del>


<pre> yum-config-manager --disable updates-testing </pre>
With dnf5:


Tip: yum distro-sync will sync the packages to the versions available in the repository and might be useful to run after you disable the testing repository to downgrade packages back to the stable versions.  
  dnf config-manager setopt updates-testing.enabled=true


Note that yum-config-manager command is available as part of yum-utils package and should be installed by default.
Use {{command|dnf repolist}} to verify. To disable the repositories again, with dnf (Fedora 22 and later):


=== Enabling the repository temporarily ===
dnf config-manager --set-disabled updates-testing
<del>dnf config-manager --set-disabled updates-testing-modular</del>


If you'd rather not enable the updates-testing repository permanently but just use it on a case-by-case basis, you can do this with ''yum''. The command:
With dnf5:


<pre>yum update --enablerepo=updates-testing</pre>
dnf config-manager setopt updates-testing.enabled=false


will update the entire system using packages from the updates-testing repository, while the command:
{{admon/tip|distro-sync|{{command|dnf distro-sync}} will sync the packages to the versions available in the repository and might be useful to run after you disable the testing repository to downgrade packages back to the stable versions.}}


<pre>yum install <foo> --enablerepo=updates-testing</pre>
Note that the {{command|dnf config-manager}} command is available as part of the {{package|dnf-plugins-core}} package and should be installed by default on Fedora 22 and later.


will install or update only the package named <foo> from the updates-testing repository.
=== Enabling the repositories temporarily ===
 
If you'd rather not enable the updates-testing repositories permanently but just use them on a case-by-case basis, you can do this with {{command|dnf}}. On Fedora 22 or later, use the command:
 
dnf update --enablerepo=updates-testing<del>,updates-testing-modular</del>
 
will update the entire system using packages from the updates-testing repositories, while the command:
 
dnf install <foo> --enablerepo=updates-testing<del>,updates-testing-modular</del> --best
 
will install or update only the package named <foo> from the updates-testing repositories.
 
=== Testing updates for EPEL with CentOS or RHEL ===
 
CentOS and RHEL (Until version 8) used yum instead of DNF, but the basic procedure for installing a particular test update for EPEL is similar:
 
yum install <foo> --enablerepo=epel-testing
 
will install or update only the package named <foo> from the epel-testing repository.
 
=== Using it with Fedora Silverblue (Kinoite, Sericea...) ===
 
rpm-ostree rebase fedora/32/x86_64/testing/silverblue
 
Going back to stable:
 
rpm-ostree rebase fedora/32/x86_64/silverblue
 
This affects the core Silverblue image itself. For testing updates to Flatpaks, see below. For other immutable variants, change 'silverblue' to 'kinoite', 'sericea' etc.
 
=== Testing updates for Fedora Flatpaks ===
 
To enable the testing remote:
 
flatpak remote-modify --enable fedora-testing
 
To switch to the build of a specific Flatpak from the fedora-testing remote:
 
flatpak install fedora-testing <org.foo.Bar> --reinstall
 
Replace <org.foo.Bar> with the correct name.
 
=== Using it with Fedora CoreOS ===
 
Fedora CoreOS offers a few [https://docs.fedoraproject.org/en-US/fedora-coreos/update-streams/ update streams], but none of those directly follow the Fedora Bodhi Updates/Updates Testing repositories.  Please follow the `testing` stream in Fedora CoreOS to preview what is coming to the next `stable` stream release.


== What to test, testing, and reporting results ==
== What to test, testing, and reporting results ==


The [http://bodhi.fedoraproject.org Bodhi] system is used to track and collate feedback on testing updates. All testing updates will be shown in the Bodhi system. First of all, if any test update package works worse for you in any respect than the pre-update version did, this is a problem that should be communicated to the developers. Secondly, when you click on a certain update, you will see a screen with more information on the update. The ''Details'' section should give you information on what the update is intended to fix. You should, if possible, test that the update does indeed fix the issues it claims to fix.
The [http://bodhi.fedoraproject.org Bodhi] system is used to track and collate feedback on testing updates. All testing updates will be shown in the Bodhi system. The [[QA:Update_feedback_guidelines|update feedback guidelines]] explain what feedback you should leave in what situations, based on your testing of the package.


There is a tool you can use to ease the process of reporting your feedback, called {{package|fedora-easy-karma}}. The tool is available as a package for all supported Fedora releases. Installation instructions can be found [[Fedora_Easy_Karma#Installation|here]].
In the web interface, each ''Works for me'' adds 1 to the test update's ''karma'', while each ''Does not work'' subtracts 1 from it. ''Untested'' leaves the karma unchanged. Other tools present this in different ways, but the +1/-1/0 mechanism is the same.


After installation, you can launch the tool at any time by running {{command|fedora-easy-karma}} in a console. If your FAS account name is not the same as your user name, use the <tt>--fas-username</tt> parameter to specify your FAS account name. It will automatically discover what packages, if any, you currently have installed from the updates-testing repository, and let you file your feedback before moving on to the next package, all in one linear process.
By default, test updates with karma of 3 are automatically sent out as full official updates, while test updates with karma of -3 are automatically withdrawn from the testing repository. The [[Updates Policy]] specifies minimum levels of karma that different types of update must meet at different points in the [[Fedora Release Life Cycle|development cycle]]. As you can see, your testing and feedback is vital to make sure that good updates are released quickly and bad ones don't get out to the general public.


You can also give your feedback on a test update by using the [http://bodhi.fedoraproject.org Bodhi web interface]. There is a ''Login'' link in the left-hand sidebar. Log in using your Fedora account. If you don't have a Fedora account, you can [https://admin.fedoraproject.org/accounts/user/new create an account here]. Once you are logged in, you will be able to leave a comment on the update. Underneath the comment box are three options: ''Untested'', ''Works for me'', and ''Does not work''. For a guide on when to leave each type of feedback, read the [[QA:Update_feedback_guidelines|update feedback guidelines]].
For pre-releases, karma may be required for important package builds to become a part of the final release. Look out for mails to the {{fplist|test-announce}} mailing list requesting karma for specific builds.


Each ''Works for me'' adds 1 to the test update's ''karma'', while each ''Does not work'' subtracts 1 from it. ''Untested'' leaves the karma unchanged. Usually, test updates with karma of 3 are automatically sent out as full official updates, while test updates with karma of -3 are automatically withdrawn from the testing repository. As you can see, your testing and feedback is vital to make sure that good updates are released quickly and bad ones don't get out to the general public.
=== Using fedora-easy-karma/fedora-update-feedback ===


=== Updates-testing enabled by default in development releases ===
There are tools you can use to ease the process of reporting your feedback.


Starting with the Fedora 13 development,  Rawhide has become a permanent development branch. In Fedora 13 development branch and above updates-testing repository is enabled by default for any development release (Alpha, Beta, Nightly builds etc). Package maintainers in Fedora are encouraged to test their updates via this repository first to keep the development branch more robust while providing the latest updates. If you a tester, it is recommended to leave this repository enabled and provide feedback to help make the general release that follows a robust one. In the development branch,  packages that are in the updates-testing repository will eventually transition into the base repository instead of the updates repository.
{{packageNew|fedora-easy-karma}} is available as a package for all supported Fedora releases. Installation instructions can be found [[Fedora_Easy_Karma#Installation|here]].


Before release, a fedora-release update will automatically disable the updates-testing repository and enable the updates repository.  After the general release, the updates repository will start filling up as more updates gets pushed through but until the release time, updates repository will remain empty.
After installation, you can launch the tool at any time by running {{command|fedora-easy-karma}} in a console. If your FAS account name is not the same as your user name, use the {{command|--fas-username FAS_USERNAME}} parameter to specify your FAS account name. It will automatically discover what packages, if any, you currently have installed from the ''updates-testing repository'' (it currently supports only package updates, not module updates or flatpak updates), and let you file your feedback before moving on to the next package, all in one linear process.
 
{{packageNew|fedora-update-feedback}} is another tool inspired by fedora-easy-karma that also allows submitting feedback for bugs and test cases in addition to providing a comment and karma. Instructions on configuring the tool can be found [https://crates.io/crates/fedora-update-feedback here].
 
=== Using the web interface ===
 
You can also give your feedback on a test update by using the [http://bodhi.fedoraproject.org Bodhi web interface]. There is a ''Login'' link in the left-hand sidebar. Log in using your Fedora account. If you don't have a Fedora account, you can [https://admin.fedoraproject.org/accounts/user/new create an account here]. Once you are logged in, you will be able to leave a comment on the update. To the right of the comment box are three radio button options that effect karma, represented by three icons that depict FAIL, Untested and PASS. The label for these options asks ''"Is the update generally functional?"''
 
The icon on the left (which looks like an X) represents ''"FAIL - Does not fix the bug or pass the test case."'' The middle option (shaped like an open box) indicates ''"Untested".'' And the rightmost icon (which looks like a check mark) designates ''"PASS - Fixes the bug or passes the test case."'' These options will leave -1, 0, or +1 karma respectively for the update.
 
=== Updates-testing enabled by default in development (Branched) releases ===
 
In Fedora [[Releases/Branched|Branched releases]] - the next release, once it has branched from Rawhide, but before it is released - the updates-testing repositories are enabled by default. Package maintainers in Fedora are encouraged to test their updates via these repositories first to keep the development branch more robust while providing the latest updates. If you are a tester, it is recommended to leave these repositories enabled and provide feedback to help make the general release that follows a robust one. In the development branch, packages that are in the updates-testing repositories will move into the relevant base repository when approved, not the relevant updates repository.
 
Before release, a fedora-release update will automatically disable the updates-testing repositories and enable the updates repositories.  After the general release, the updates repositories will start filling up as more updates gets pushed through but until the release time, updates repositories will remain empty.


==See also==
==See also==
* [[Bodhi Guide]]
* [[Bodhi]]
* [[Bodhi/bodhi-client|Bodhi CLI]]
* [[Fedora Gooey Karma]]
 
[[Category:QA]]

Latest revision as of 07:10, 24 October 2024

The updates-testing repository, also referred to as Test Updates, contains updates scheduled to be released for Branched pre-releases (after the Bodhi enabling point) and stable releases of Fedora. The updates-testing-modular repository is the equivalent repository for module updates.* User testing and feedback provided via Bodhi, on the test mailing list and the relevant Bugzilla is vital to ensure that good updates are released quickly and bad ones kept away from release.

*No longer include fedora-repos-modular in default installations since F39.

Using the updates-testing repositories

Enabling the repositories permanently

With dnf (Fedora 22 and later):

dnf config-manager --set-enabled updates-testing
dnf config-manager --set-enabled updates-testing-modular

With dnf5:

dnf config-manager setopt updates-testing.enabled=true

Use dnf repolist to verify. To disable the repositories again, with dnf (Fedora 22 and later):

dnf config-manager --set-disabled updates-testing
dnf config-manager --set-disabled updates-testing-modular

With dnf5:

dnf config-manager setopt updates-testing.enabled=false
distro-sync
dnf distro-sync will sync the packages to the versions available in the repository and might be useful to run after you disable the testing repository to downgrade packages back to the stable versions.

Note that the dnf config-manager command is available as part of the dnf-plugins-core package and should be installed by default on Fedora 22 and later.

Enabling the repositories temporarily

If you'd rather not enable the updates-testing repositories permanently but just use them on a case-by-case basis, you can do this with dnf. On Fedora 22 or later, use the command:

dnf update --enablerepo=updates-testing,updates-testing-modular

will update the entire system using packages from the updates-testing repositories, while the command:

dnf install <foo> --enablerepo=updates-testing,updates-testing-modular --best

will install or update only the package named <foo> from the updates-testing repositories.

Testing updates for EPEL with CentOS or RHEL

CentOS and RHEL (Until version 8) used yum instead of DNF, but the basic procedure for installing a particular test update for EPEL is similar:

yum install <foo> --enablerepo=epel-testing

will install or update only the package named <foo> from the epel-testing repository.

Using it with Fedora Silverblue (Kinoite, Sericea...)

rpm-ostree rebase fedora/32/x86_64/testing/silverblue

Going back to stable:

rpm-ostree rebase fedora/32/x86_64/silverblue

This affects the core Silverblue image itself. For testing updates to Flatpaks, see below. For other immutable variants, change 'silverblue' to 'kinoite', 'sericea' etc.

Testing updates for Fedora Flatpaks

To enable the testing remote:

flatpak remote-modify --enable fedora-testing

To switch to the build of a specific Flatpak from the fedora-testing remote:

flatpak install fedora-testing <org.foo.Bar> --reinstall

Replace <org.foo.Bar> with the correct name.

Using it with Fedora CoreOS

Fedora CoreOS offers a few update streams, but none of those directly follow the Fedora Bodhi Updates/Updates Testing repositories. Please follow the testing stream in Fedora CoreOS to preview what is coming to the next stable stream release.

What to test, testing, and reporting results

The Bodhi system is used to track and collate feedback on testing updates. All testing updates will be shown in the Bodhi system. The update feedback guidelines explain what feedback you should leave in what situations, based on your testing of the package.

In the web interface, each Works for me adds 1 to the test update's karma, while each Does not work subtracts 1 from it. Untested leaves the karma unchanged. Other tools present this in different ways, but the +1/-1/0 mechanism is the same.

By default, test updates with karma of 3 are automatically sent out as full official updates, while test updates with karma of -3 are automatically withdrawn from the testing repository. The Updates Policy specifies minimum levels of karma that different types of update must meet at different points in the development cycle. As you can see, your testing and feedback is vital to make sure that good updates are released quickly and bad ones don't get out to the general public.

For pre-releases, karma may be required for important package builds to become a part of the final release. Look out for mails to the test-announce mailing list requesting karma for specific builds.

Using fedora-easy-karma/fedora-update-feedback

There are tools you can use to ease the process of reporting your feedback.

fedora-easy-karma is available as a package for all supported Fedora releases. Installation instructions can be found here.

After installation, you can launch the tool at any time by running fedora-easy-karma in a console. If your FAS account name is not the same as your user name, use the --fas-username FAS_USERNAME parameter to specify your FAS account name. It will automatically discover what packages, if any, you currently have installed from the updates-testing repository (it currently supports only package updates, not module updates or flatpak updates), and let you file your feedback before moving on to the next package, all in one linear process.

fedora-update-feedback is another tool inspired by fedora-easy-karma that also allows submitting feedback for bugs and test cases in addition to providing a comment and karma. Instructions on configuring the tool can be found here.

Using the web interface

You can also give your feedback on a test update by using the Bodhi web interface. There is a Login link in the left-hand sidebar. Log in using your Fedora account. If you don't have a Fedora account, you can create an account here. Once you are logged in, you will be able to leave a comment on the update. To the right of the comment box are three radio button options that effect karma, represented by three icons that depict FAIL, Untested and PASS. The label for these options asks "Is the update generally functional?"

The icon on the left (which looks like an X) represents "FAIL - Does not fix the bug or pass the test case." The middle option (shaped like an open box) indicates "Untested". And the rightmost icon (which looks like a check mark) designates "PASS - Fixes the bug or passes the test case." These options will leave -1, 0, or +1 karma respectively for the update.

Updates-testing enabled by default in development (Branched) releases

In Fedora Branched releases - the next release, once it has branched from Rawhide, but before it is released - the updates-testing repositories are enabled by default. Package maintainers in Fedora are encouraged to test their updates via these repositories first to keep the development branch more robust while providing the latest updates. If you are a tester, it is recommended to leave these repositories enabled and provide feedback to help make the general release that follows a robust one. In the development branch, packages that are in the updates-testing repositories will move into the relevant base repository when approved, not the relevant updates repository.

Before release, a fedora-release update will automatically disable the updates-testing repositories and enable the updates repositories. After the general release, the updates repositories will start filling up as more updates gets pushed through but until the release time, updates repositories will remain empty.

See also