Commit 9eb29299 authored by Cyril 'kibi' Brulebois's avatar Cyril 'kibi' Brulebois
Browse files

Merge remote-tracking branch...

Merge remote-tracking branch 'origin/doc/17571-interface-between-developers-and-rm' (Closes: #17571, #17772)
parents 5b9cd18c 6b82658e
......@@ -12,7 +12,7 @@ So read on to find out how you can make a difference in Tails.
<p>Every user can help others or provide developers with useful information.</p>
<li>[[Report bugs|doc/first_steps/bug_reporting]]</li>
<li>[[Test experimental ISO images|contribute/how/testing]]</li>
<li>[[Test experimental Tails images|contribute/how/testing]]</li>
<li>[[Provide input to developers|contribute/how/input]]</li>
<li>[[Help other Tails users|contribute/how/help]]</li>
......@@ -138,7 +138,8 @@ Tools for contributors
- [[Building a Tails image|contribute/build]]
- [[Build a local copy of the website|contribute/build/website]]
- [[Customize Tails|contribute/customize]]
- [Nightly ISO builds](
- [Nightly Tails image builds](
- [[Jenkins CI|contribute/working_together/roles/sysadmins/Jenkins]]
- Debian packages
- [[APT repository|contribute/APT_repository]], to store our custom Debian packages
- How we manage and upgrade the [[Linux kernel|contribute/Linux_kernel]].
......@@ -191,6 +192,8 @@ Collective process
- [[UX designers|contribute/working_together/roles/ux]]
- [[Verification extension
- Interfaces between roles and teams
- [[Developers and Release Managers|contribute/working_together/interfaces/developers_and_release_managers]]
- Roles for sponsor deliverables:
- [[Team manager|contribute/working_together/roles/sponsor_deliverables/team_manager]]
- [[Worker|contribute/working_together/roles/sponsor_deliverables/worker]]
......@@ -15,8 +15,8 @@
- the issues [[!tails_gitlab groups/tails/-/milestones desc="fixed for the upcoming release"]]
- If a release candidate was announced, read the call for testing
- Analyze the diff of packages
- in testing for a major release: `wget`
- in stable for a bugfix release: `wget`
- in testing for a major release: `wget`
- in stable for a bugfix release: `wget`
- `diff -u ~/Persistent/master/wiki/src/torrents/files/tails-amd64-*.packages latest.packages | wdiff --diff-input --terminal --auto-pager`
- If an important application was updated to a new upstream release, read its Changelog to find relevant highlights:
- Tor: <>
......@@ -41,5 +41,5 @@ Feature previews
Every now and then, we also publish ISO images to test more specifically a new
feature we are working on.
They are available on <> and are announced
They are available on <> and are announced
together with specific testing instructions.
......@@ -42,3 +42,8 @@ identify the root cause of it to a recent commit, fix it if you wish,
but don't let it disturb you otherwise: just revert the faulty commit
and inform the other developers on [[|about/contact#tails-dev]] so that the author knows
s/he needs to fix his/her stuff before reapplying it at a later point.
## Coordinate major changes and freeze exceptions with Release Managers
See the coordination guidelines [[for developers with Release
......@@ -1888,7 +1888,7 @@ If you just released a final release
EXPIRY="$(curl --silent "${ARCHIVE:?}/dists/${DIST:?}/snapshots/${SERIAL:?}/Release" | sed -n 's/^Valid-Until:\s\+\(.*\)$/\1/p')"
EXPIRY="$(curl --silent "${ARCHIVE:?}/dists/${DIST:?}/snapshots/${SERIAL:?}/Release" | sed -n 's/^Valid-Until:\s\+\(.*\)$/\1/p')"
echo "* Archive '${ARCHIVE:?}' uses snapshot '${SERIAL:?}' which expires on: ${EXPIRY:?}"
......@@ -16,7 +16,7 @@ the Tails images build process.
1. The first time you do this requires some additional steps (WARNING!
this will download almost 2 GiB of data):
1. Clone [Tails' Thunderbird repo](
1. Clone [Tails' Thunderbird repo](
1. Add a remote for Debian:
......@@ -27,7 +27,7 @@ at best is a few months.
To solve this, we host ourselves the Tor Browser tarballs we need, and
point to [this permanent
location]( for anything that
location]( for anything that
we tag.
Still, one can set an arbitrary download location in
......@@ -71,3 +71,12 @@ Versioning scheme
* The second number is incremented for every release that does not
increment the first number.
* We add an extra, third number for emergency releases.
Release candidates and beta releases
Most Tails stable releases are published directly, without a prior beta release
or release candidate (RC). But some changes deserve more caution, in which case
we often choose to release a beta or RC. See how to [[decide whether to release
a beta or
a RC|contribute/working_together/interfaces/developers_and_release_managers#beta-or-rc]].
[[!meta title="Interfaces between roles and teams"]]
[[!map pages="contribute/working_together/interfaces/*"]]
[[!meta title="Interface between developers and Release Managers"]]
Code changes merged into our release branches (`stable`, `testing`, `devel`) may
impact the [[Release
Managers|contribute/working_together/roles/release_manager]]' work: for example,
the Release Manager on duty is on the frontline when manual testing done during
the release process identifies critical breakage at the last minute before we
publish a new version of Tails. This can disrupt the release schedule and lead
to highly stressful situations.
These guidelines are meant to decrease the risk of seeing such problems happen.
[[!toc levels=2]]
# Changes that may impact automatic upgrades
For changes that may impact automatic upgrades, the responsible developers MUST
put the Release Managers into the loop in advance, way before the code is
merged. This allows the Release Managers to:
- Raise any concerns they may have about the design or implementation
of the proposed changes.
- Propose extra manual tests that could be done ahead of merging
and/or during the manual testing session of the release process,
in order to build confidence in the proposed changes.
- Make developers benefit from an independent "What can possibly go
wrong?" brainstorming.
# During a code freeze
We sometimes [[freeze|contribute/release_schedule]] one of our release branches,
in order to stabilize it before a release.
During such a code freeze, developers MUST notify the Release Manager on duty
about freeze exceptions they intend to propose or merge. And then:
- If the proposed changes may impact automatic upgrades, as a developer, ensure
you get feedback from the Release Manager on duty, before you apply
a freeze exception.
- Else, that is in the general case, as a developer you don't need to block on
the Release Manager's feedback before you apply the freeze exception.
<a id="beta-or-rc"></a>
# Deciding whether to release a beta or a RC
We use beta releases and/or release candidates to get risky changes tested by
enthusiastic users, more broadly than what developers and automated tests can do.
This allows us to identify problems before we release those changes in a stable
Tails release, that we will recommend all users upgrade to.
Compared to a release candidate (RC), in general a beta release:
- is prepared by someone else than Release Manager: most often, one of the
developers who worked on the feature announces a beta release;
- does not necessarily go through any, or all of, our
[[manual test suite|contribute/release_process/test]];
- is often published as an non-trusted
[Jenkins nightly build](;
- cannot be automatically upgraded from; it follows a beta release
comes with no security support;
- is scheduled in an ad-hoc manner, while release candidates are
[[scheduled|contribute/release_schedule]] in our [[contribute/calendar]]
months ahead;
- does not imply freezing any release branch.
As a consequence of the above, compared to a RC, a beta release:
- requires vastly less effort and coordination to publish;
- is tested only briefly and by fewer people: Tails users should not upgrade
their "production" Tails USB stick to a beta.
It can be tough to decide whether a given change requires a RC, as opposed to
a mere beta. Here are some guidelines that may help:
- If the change has a broad impact, and carries a risk to break any part of
Tails, then a RC may be worth it: production usage has a vastly greater test
coverage than our automated test suite.
For example, migrating from `aufs` to `overlayfs` was first
done in a [beta](, then in 4.5~rc1, before being shipped in a stable release.
- If the change can be tested very quickly, then a beta may be sufficient.
- If the change affects only specific hardware, then it may be sufficient
to release a beta and call for testing on that specific hardware.
......@@ -21,7 +21,7 @@ Debian packages and is neither modified nor recompiled by Tails.
[[our Git repositories|contribute/git]].
- The source code of the Debian packages included in Tails is available
in the [APT snapshot](
in the [APT snapshot](
that we created for that version of Tails.
- The [[!tails_gitweb
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment