Changes
Page history
Adjust for ikiwiki → GitLab wiki
authored
Jan 12, 2021
by
intrigeri
Show whitespace changes
Inline
Side-by-side
Debian_testing.md
View page @
a5d53a93
[[!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 O
ngoing
T
ransitions
desc="o
ngoing
t
ransitions
"]]
that
[
o
ngoing
t
ransitions
](
https://wiki.debian.org/O
ngoing
T
ransitions
)
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.