2017-03-20 21:33:08 -04:00
|
|
|
---
|
2021-03-13 13:06:18 -05:00
|
|
|
lang: en
|
2017-03-20 21:33:08 -04:00
|
|
|
layout: doc
|
2021-06-16 22:56:25 -04:00
|
|
|
permalink: /doc/testing/
|
2021-03-13 13:06:18 -05:00
|
|
|
ref: 147
|
2021-06-19 05:36:05 -04:00
|
|
|
advanced: true
|
2021-06-17 07:23:57 -04:00
|
|
|
title: Testing New Releases and Updates
|
2017-03-20 21:33:08 -04:00
|
|
|
---
|
|
|
|
|
|
2021-06-20 00:06:40 -04:00
|
|
|
Testing new Qubes OS releases and updates is one of the most helpful ways in
|
|
|
|
|
which you can [contribute](/doc/contributing/) to the Qubes OS Project. There
|
|
|
|
|
are several different types of testing, which we'll cover below.
|
2017-03-20 21:33:08 -04:00
|
|
|
|
2021-06-20 00:06:40 -04:00
|
|
|
**Warning:** Software testing is intended for advanced users and developers.
|
|
|
|
|
You should only attempt to do this if you know what you're doing. Never rely on
|
|
|
|
|
code that is in testing for critical work!
|
2021-06-12 22:29:17 -04:00
|
|
|
|
2021-06-20 00:06:40 -04:00
|
|
|
## Releases
|
2021-03-13 12:03:23 -05:00
|
|
|
|
2017-03-20 21:33:08 -04:00
|
|
|
How to test upcoming Qubes OS releases:
|
|
|
|
|
|
2021-04-10 18:09:05 -04:00
|
|
|
* Use [qubes-builder](/doc/qubes-builder/) to build the latest release.
|
2021-06-20 00:06:40 -04:00
|
|
|
* Test the latest release candidate (RC), if one is currently available.
|
|
|
|
|
* (No support) Experiment with devel alpha ISOs found from time to time at
|
|
|
|
|
[Qubes OpenQA](https://openqa.qubes-os.org/).
|
2017-03-20 21:33:08 -04:00
|
|
|
|
2021-06-12 22:29:17 -04:00
|
|
|
Please make sure to [report any bugs you encounter](/doc/reporting-bugs/).
|
|
|
|
|
|
2021-06-20 00:06:40 -04:00
|
|
|
See [Version Scheme](/doc/version-scheme/) for details about release versions
|
|
|
|
|
and schedules. See [Release Checklist](/doc/releases/todo/) for details about
|
|
|
|
|
the RC process.
|
2017-03-20 21:33:08 -04:00
|
|
|
|
2021-06-20 00:06:40 -04:00
|
|
|
## Updates
|
2021-03-13 12:03:23 -05:00
|
|
|
|
2017-03-20 21:33:08 -04:00
|
|
|
How to test updates:
|
|
|
|
|
|
2021-06-20 00:06:40 -04:00
|
|
|
* Enable [dom0 testing
|
|
|
|
|
repositories](/doc/how-to-install-software-in-dom0/#testing-repositories).
|
|
|
|
|
* Enable [template testing
|
|
|
|
|
repositories](/doc/how-to-install-software/#testing-repositories).
|
|
|
|
|
|
|
|
|
|
Every new update is first uploaded to the `security-testing` repository if it
|
|
|
|
|
is a security update or `current-testing` if it is a normal update. The update
|
|
|
|
|
remains in `security-testing` or `current-testing` for a minimum of one week.
|
|
|
|
|
On occasion, an exception is made for a particularly critical security update,
|
|
|
|
|
which is immediately pushed to the `current` stable repository. In general,
|
|
|
|
|
however, security updates remain in `security-testing` for two weeks before
|
|
|
|
|
migrating to `current`. Normal updates generally remain in `current-testing`
|
|
|
|
|
until they have been sufficiently tested by the community, which can last weeks
|
|
|
|
|
or even months, depending on the amount of feedback received (see [Providing
|
|
|
|
|
feedback](#providing-feedback)).
|
|
|
|
|
|
|
|
|
|
"Sufficient testing" is, in practice, a fluid term that is up the developers'
|
|
|
|
|
judgment. In general, it means either that no negative feedback and at least
|
|
|
|
|
one piece of positive feedback has been received or that the package has been
|
|
|
|
|
in `current-testing` for long enough, depending on the component and the
|
|
|
|
|
complexity of the changes.
|
|
|
|
|
|
|
|
|
|
A limitation of the current testing setup is that it is only possible to
|
|
|
|
|
migrate the *most recent version* of a package from `current-testing` to
|
|
|
|
|
`current`. This means that, if a newer version of a package is uploaded to
|
|
|
|
|
`current-testing`, it will no longer be possible to migrate any older versions
|
|
|
|
|
of that same package from `current-testing` to `current`, even if one of those
|
|
|
|
|
older versions has been deemed stable enough. While this limitation can be
|
|
|
|
|
inconvenient, the benefits outweigh the costs, since it greatly simplifies the
|
|
|
|
|
testing and reporting process.
|
|
|
|
|
|
|
|
|
|
## Providing feedback
|
|
|
|
|
|
|
|
|
|
Since the whole point of testing software is to discover and fix bugs, your
|
|
|
|
|
feedback is an essential part of this process.
|
|
|
|
|
|
|
|
|
|
We use an [automated build
|
|
|
|
|
process](https://github.com/QubesOS/qubes-infrastructure/blob/master/README.md).
|
|
|
|
|
For every package that is uploaded to a testing repository, a GitHub issue is
|
|
|
|
|
created in the
|
|
|
|
|
[updates-status](https://github.com/QubesOS/updates-status/issues) repository
|
|
|
|
|
for tracking purposes. We welcome any kind of feedback on any package in any
|
|
|
|
|
testing repository. Even a simple <span class="fa fa-thumbs-up" title="Thumbs
|
|
|
|
|
Up"></span> or <span class="fa fa-thumbs-down" title="Thumbs Down"></span> on
|
|
|
|
|
the package's associated issue would help us to decide whether the package is
|
|
|
|
|
ready to be migrated to a stable repository. If you [report a
|
|
|
|
|
bug](/doc/reporting-bugs/) in a package that is in a testing repository, please
|
|
|
|
|
reference the appropriate issue in
|
|
|
|
|
[updates-status](https://github.com/QubesOS/updates-status/issues).
|
