|
|
[[!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
|
|
|
|
|
|
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"
|
|
|
cycle to evaluate how it would feel like. See the
|
|
|
[[initial plan & analysis|blueprint/Debian_Stretch/#rolling]].
|
|
|
[initial plan & analysis](Debian_Stretch#rolling).
|
|
|
|
|
|
## Calendar
|
|
|
|
... | ... | @@ -91,7 +96,7 @@ part of a broader community. |
|
|
|
|
|
- Transitions
|
|
|
* 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?
|
|
|
* How to select the right snapshot we shall take, e.g.
|
|
|
during transitions?
|
... | ... | @@ -102,7 +107,7 @@ part of a broader community. |
|
|
* too many software regressions and not well tested new features
|
|
|
* confused users due to constant incremental changes
|
|
|
* 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:
|
|
|
- RAM requirements: XXX
|
|
|
- download time: XXX
|
... | ... | @@ -144,13 +149,13 @@ part of a broader community. |
|
|
the code & test suite during sprints. If the work doesn't fit into
|
|
|
these sprints then we'll need to draw conclusions.
|
|
|
* 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
|
|
|
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
|
|
|
if we decide something else.
|
|
|
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
|
|
|
* January 16: first Tails release based on Debian testing
|
|
|
|
... | ... | @@ -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?
|
|
|
|
|
|
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:
|
|
|
|
|
|
- [[!tails_gitweb bin/doc-impacted-by]]
|
|
|
- [[!tails_gitweb doc-source-relationships.yml]]
|
|
|
- [bin/doc-impacted-by](https://gitlab.tails.boum.org/tails/tails/-/blob/master/bin/doc-impacted-by)
|
|
|
- [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:
|
|
|
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 |
|
|
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
|
|
|
too much.
|
|
|
|