Zen

Source string Source string

491/10000 · 491

The string is read only.

English Actions
While modifying the macro configuration on side-tags can be useful, it can also be problematic. As such, macros must be approved by FESCo and the list of currently supported macros is available in the xref:fesco::Policy_for_buildroot_macros.adoc[Policy for Buildroot Macros].
Removing a side tag
To conserve build system resources, side tags that are not needed anymore should be removed. This can be achieved with `fedpkg` as follows:
fedpkg remove-side-tag <side-tag>
Bodhi automatically removes side tags used for updates pushed to stable, so removing them manually is usually not necessary.
Bodhi multi-package updates
You can also create an update with multiple packages directly in Bodhi, either with the https://bodhi.fedoraproject.org[Bodhi web application], or with the `bodhi` command line tool. This is usually a worse method than using a side tag, because managing the build root is more difficult and will affect packages outside of the group. It may be appropriate if the packages logically belong together as an update, but do not have any build-time interdependencies. You cannot use this method for Rawhide or early Branched updates, because of the automatic update creation system.
You can pass multiple package names to `bodhi updates new` command to create a new multi-package update, or use `bodhi updates edit` to edit an existing update.
It is possible you will run into problems with permissions when you are not the maintainer of the package you are trying to add to an update, or when you are trying to add packages to an update created by somebody else. If you encounter a situation like this, you should contact the https://docs.pagure.org/releng/[release engineering] team or a proven packager for help.
Buildroot overrides
When trying to do a multi-package update without using side tags, you may need to use https://fedoraproject.org/wiki/Bodhi/BuildRootOverrides[buildroot overrides]. A buildroot override puts a build that is not yet stable into the main build root for the release. Before on-demand side tags, this was the usual way to create a multi-package update when the packages have build-time interdependencies. Unlike with side tags, buildroot overrides are not isolated and thus should be only used in special cases where side tags do not suffice.
Update attributes
At the time you submit an update, you will be asked for several attributes. The type of the update should be fairly self-explanatory: Either it fixes bugs, adds new features, or is a new package.
If you are asked whether you want to send the update to _updates-testing_ or _stable_, this is a no-op: all updates now go through _updates-testing_. It does not matter what you choose.
There are several schools of thought on filling out the update description. Some would suggest you consider the target audience: for a stable release, in particular, many Fedora users will see this text, and many of them may not be particularly familiar with your package. Consider not simply describing literally the changes in the update, but explaining as if to an outsider why your are updating the package, what benefits it will bring to them (if any), and anything they may want to note in order to have a smooth update experience.
If you associate one or more bug reports with your update, Bodhi will post comments into Bugzilla to alert those following the bug reports that an update is available. If you mark your update as fixing the bug(s), Bodhi will move the report(s) through the `MODIFIED`, `ON_QA` and `CLOSED ERRATA` states of the xref:bug_status.adoc[Bug Status Workflow] as your update reaches various points in the process. Using this mechanism can be very useful both for you and for users of your package.
You may set thresholds for automatic push to stable based on positive feedback (karma) and/or time spent in updates-testing. If your update's total karma (items of positive feedback minus items of negative feedback) reaches the karma threshold, it will be pushed stable automatically. If your update reaches the threshold for time in updates-testing without the builds changing or the total karma going so low it is unpushed, it will be pushed stable automatically.
There are defaults for these thresholds which vary at different points in the release process.
If you choose to use the karma auto-push threshold, please carefully consider an appropriate feedback level. For a relatively obscure package which is quite stable, 1 or 2 may be an appropriate value. For a popular, sensitive and complex package such as `firefox` or `kernel`, the default may be insufficient and a choice of 5 or even 10 may be appropriate.
Handling feedback from automated tests
Fedora's automated testing systems, including Fedora CI, openQA, and Fedora CoreOS CI, may run automated tests on your update.
In the Bodhi web interface, updates have an _Automated Tests_ tab which displays the results of all automated tests. Tests with an asterisk (star) at the left-hand side of the row are "gating" tests. These are the tests which prevent your update going stable if they fail. If a test does not have an asterisk, it is not gating, and does not affect whether your update can be pushed stable. For updates in the critical path, some gating tests are always present. For updates not in the critical path, there may be gating tests if any package in the update has configured them in its package-level gating configuration. If a failed gating test is waived, the asterisk is replaced with a thumbs-up.
Tests shown with a red background failed.
Tests shown with a green background passed.
Tests shown with a blue background and an "i" icon had some minor issue, but effectively passed.
Tests shown with a blue background and an hourglass icon are pending.
The tests are not all 100% accurate, but they are fairly often correct. Especially failures of openQA tests - those whose name starts with _update._ - should always be investigated and resolved before an update is pushed stable. If you see a failure, it is a very good idea to click on the result (which will take you to a detailed log) and investigate the issue. If you are unsure what the test indicates, you can contact the relevant team for help. When a test has failed gating, a box is shown with contact details.
The Fedora Quality team proactively investigates failed openQA tests and will usually resolve them or post a comment on the update explaining the problem and suggesting a resolution.
Waive a result
Any failure of a gating test will prevent your update from being released. On the update's _Details_ page in the Bodhi web interface, the *Test Gating* status will be shown as _N of N required tests failed_, and one or more red rows with asterisks should be present on the _Automated Tests_ tab. If you are absolutely sure such a failure is a false one, you can 'waive' all failed gating tests from the Bodhi web interface by clicking the *Waive Test Results* button. This button is only present when an update has failed gating tests, and you have privileges to control the update. At present it is not possible to waive the absence of a result for a gating test in this way. If needed, this can be done with `waiverdb-cli`. Please do not waive failures of openQA tests - those whose names start with _update._ - without checking with the https://fedoraproject.org/wiki/QA#Communicate[Fedora Quality team].
A tool called `waiverdb-cli` exists for filing waivers manually, though this should rarely be necessary. The tool is also missing some features needed to correctly specify waivers in some cases, like the ability to specify a scenario. It is not currently packaged in Fedora. You can get it from the https://pagure.io/waiverdb[the waiverdb repository], which also has some instructions on usage.

Loading…

User avatar None

String added in the repository
If you associate one or more bug reports with your update, Bodhi will post comments into Bugzilla to alert those following the bug reports that an update is available. If you mark your update as fixing the bug(s), Bodhi will move the report(s) through the `MODIFIED`, `ON_QA` and `CLOSED ERRATA` states of the xref:bug_status.adoc[Bug Status Workflow] as your update reaches various points in the process. Using this mechanism can be very useful both for you and for users of your package.
If you associate one or more bug reports with your update, Bodhi will post comments into Bugzilla to alert those following the bug reports that an update is available. If you mark your update as fixing the bug(s), Bodhi will move the report(s) through the `MODIFIED`, `ON_QA` and `CLOSED ERRATA` states of the xref:bug_status.adoc[Bug Status Workflow] as your update reaches various points in the process. Using this mechanism can be very useful both for you and for users of your package.
4 months ago
Browse all string changes

Things to check

Unpluralised

The string is used as plural, but not using plural forms

Reset

Glossary

English English
No related strings found in the glossary.

String information

Source string description
type: Plain text
Flags
placeholders:r"`[\w\d -_<>(){}\[\]@$;.\*+=]*`":r"(link:)?https?://[\w\d\-_#?&%=\./]*":r"xref:[\w\d\-_/]*\.adoc(#[\w\d\-_/]*)?", read-only
Source string location
./pages/Package_Update_Guide.adoc:378
String age
4 months ago
Last updated
4 months ago
Source string age
4 months ago
Translation file
pot/master/pages/Package_Update_Guide.pot, string 78