Adjust for ikiwiki → GitLab wiki authored by intrigeri's avatar intrigeri
[[!meta title="Basing Tails on quarterly snapshots of Debian Testing"]] ---
title: Basing Tails on quarterly snapshots of Debian Testing
---
Tracking ticket: [[!tails_ticket 12615]]
[[!toc levels=2]] Tracking ticket: tails/tails#12615
[[_TOC_]]
# The big picture # The big picture
We've been thinking for a while of being based on quarterly snapshots We've been thinking for a while of being based on quarterly snapshots
of Debian testing. We've used the "porting Tails to Debian Stretch" of Debian testing. We've used the "porting Tails to Debian Stretch"
cycle to evaluate how it would feel like. See the cycle to evaluate how it would feel like. See the
[[initial plan & analysis|blueprint/Debian_Stretch/#rolling]]. [initial plan & analysis](Debian_Stretch#rolling).
## Calendar ## Calendar
...@@ -91,7 +96,7 @@ part of a broader community. ...@@ -91,7 +96,7 @@ part of a broader community.
- Transitions - Transitions
* How to deal with * How to deal with
[[!debwiki OngoingTransitions desc="ongoing transitions"]] that [ongoing transitions](https://wiki.debian.org/OngoingTransitions) that
block migration of security updates from sid to testing? block migration of security updates from sid to testing?
* How to select the right snapshot we shall take, e.g. * How to select the right snapshot we shall take, e.g.
during transitions? during transitions?
...@@ -102,7 +107,7 @@ part of a broader community. ...@@ -102,7 +107,7 @@ part of a broader community.
* too many software regressions and not well tested new features * too many software regressions and not well tested new features
* confused users due to constant incremental changes * confused users due to constant incremental changes
* bigger upgrades on average: according to research done on * bigger upgrades on average: according to research done on
[[!tails_ticket 14622]], we should assume ~600MB large IUKs; tails/tails#14622, we should assume ~600MB large IUKs;
there will be consequences in terms of: there will be consequences in terms of:
- RAM requirements: XXX - RAM requirements: XXX
- download time: XXX - download time: XXX
...@@ -144,13 +149,13 @@ part of a broader community. ...@@ -144,13 +149,13 @@ part of a broader community.
the code & test suite during sprints. If the work doesn't fit into the code & test suite during sprints. If the work doesn't fit into
these sprints then we'll need to draw conclusions. these sprints then we'll need to draw conclusions.
* At the end of 2017-11: * At the end of 2017-11:
1. [[!tails_ticket 14578 desc="Decide"]] whether we want to release 1. Decide (tails/tails#14578) whether we want to release
Tails based on Debian testing Tails based on Debian testing
in 2018-01, 2018-04, or give up and rather release it mid-2019. in 2018-01, 2018-04, or give up and rather release it mid-2019.
The following assumes "in 2018-01" and will need to be adjusted The following assumes "in 2018-01" and will need to be adjusted
if we decide something else. if we decide something else.
2. The Foundations Team tells technical writers what needs to be 2. The Foundations Team tells technical writers what needs to be
updated ([[!tails_ticket 14579]]) updated (tails/tails#14579)
* November-January: technical writers update the documentation * November-January: technical writers update the documentation
* January 16: first Tails release based on Debian testing * January 16: first Tails release based on Debian testing
...@@ -161,12 +166,12 @@ part of a broader community. ...@@ -161,12 +166,12 @@ part of a broader community.
## How can the Foundations Team tell Technical Writers what part of our doc needs to be updated? ## How can the Foundations Team tell Technical Writers what part of our doc needs to be updated?
The first time we'll have to deal with this problem is The first time we'll have to deal with this problem is
[[!tails_ticket 14579]], but it will come back every quarter. tails/tails#14579, but it will come back every quarter.
Current implementation: Current implementation:
- [[!tails_gitweb bin/doc-impacted-by]] - [bin/doc-impacted-by](https://gitlab.tails.boum.org/tails/tails/-/blob/master/bin/doc-impacted-by)
- [[!tails_gitweb doc-source-relationships.yml]] - [doc-source-relationships.yml](https://gitlab.tails.boum.org/tails/tails/-/blob/master/doc-source-relationships.yml)
We want to automate this as much as we can, but let's be clear: We want to automate this as much as we can, but let's be clear:
automation will not fully solve this problem unless we switch to automation will not fully solve this problem unless we switch to
...@@ -409,3 +414,4 @@ while ideally we'd rather update the documentation _before_ the ...@@ -409,3 +414,4 @@ while ideally we'd rather update the documentation _before_ the
corresponding changes are released to our users. So if we receive such corresponding changes are released to our users. So if we receive such
notifications, e.g. at RC time, fine, but let's not count on it notifications, e.g. at RC time, fine, but let's not count on it
too much. too much.