From Fedora Project Wiki

(various cleanups, extra links, modern references, etc etc)
Line 2: Line 2:
__NOTOC__
__NOTOC__


The [[Repositories#updates-testing|'''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.-->
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. 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.-->


== Using the updates-testing repository ==
== Using the updates-testing repository ==
Line 8: Line 8:
=== Enabling the repository permanently ===
=== Enabling the repository permanently ===


The following command will enable the updates testing repository permanently
The following command will enable the updates testing repository permanently:


<pre> yum-config-manager --enable updates-testing </pre>
yum-config-manager --enable updates-testing


Use yum repolist to verify.  If you wish to disable it again, run the following command
Use yum repolist to verify.  If you wish to disable it again, run the following command:


<pre> yum-config-manager --disable updates-testing </pre>
yum-config-manager --disable updates-testing


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.  
{{admon/tip|yum distro-sync|{{command|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. }}


Note that yum-config-manager command is available as part of yum-utils package and should be installed by default.  
Note that the {{command|yum-config-manager}} command is available as part of the {{package|yum-utils}} package and should be installed by default.  


=== Enabling the repository temporarily ===
=== Enabling the repository temporarily ===
Line 24: Line 24:
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:
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:


<pre>yum update --enablerepo=updates-testing</pre>
yum update --enablerepo=updates-testing


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


<pre>yum install <foo> --enablerepo=updates-testing</pre>
yum install <foo> --enablerepo=updates-testing


will install or update only the package named <foo> from the updates-testing repository.
will install or update only the package named <foo> from the updates-testing repository.
Line 34: Line 34:
== 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.
 
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 [[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.
 
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.
 
=== Using fedora-easy-karma ===


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]].
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]].


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.
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}} 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.


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]].
=== Using 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. 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.
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'', which leave 0, +1 or -1 karma, as described above.


=== Note on using [http://dnf.baseurl.org/ DNF] with updates-testing and dependency errors ===
=== Note on using [http://dnf.baseurl.org/ DNF] with updates-testing and dependency errors ===
Line 57: Line 65:


==See also==
==See also==
* [[Bodhi Guide]]
* [[Bodhi]]
* [https://fedorahosted.org/bodhi/wiki/CLI Bodhi CLI guide]
* [{Fedora Gooey Karma]]

Revision as of 02:11, 26 September 2014

QA.png


The updates-testing repository, also referred to as Test Updates, contains updates scheduled to be released for Branched pre-releases (after the [[Updates Policy#Bodhi enabling|Bodhi enabling point]]) and stable releases of Fedora. 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.

Using the updates-testing repository

Enabling the repository permanently

The following command will enable the updates testing repository permanently:

yum-config-manager --enable updates-testing

Use yum repolist to verify. If you wish to disable it again, run the following command:

yum-config-manager --disable updates-testing
Idea.png
yum distro-sync
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.

Note that the yum-config-manager command is available as part of the Package-x-generic-16.pngyum-utils package and should be installed by default.

Enabling the repository temporarily

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:

yum update --enablerepo=updates-testing

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

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

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

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

There is a tool you can use to ease the process of reporting your feedback, called Package-x-generic-16.pngfedora-easy-karma. The tool 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 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.

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. Underneath the comment box are three options: Untested, Works for me, and Does not work, which leave 0, +1 or -1 karma, as described above.

Note on using DNF with updates-testing and dependency errors

If you use the DNF tool rather than yum, note that unlike yum, it does not notify you of dependency errors in the set of available updates by default. yum will, by default, print some information about the dependency errors, and then fail the update: you have to run yum update --skip-broken to install all the updates that do not have dependency errors. DNF essentially does --skip-broken by default, and silently - it will install all updates that do not have dependency errors, and not tell you about those that do.

To use dnf to spot updates with dependency errors, you can run dnf update --best, which should act like yum's default behaviour.

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 repository is enabled by default. 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 are 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 move into the base repository when approved, not the updates repository.

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.

See also