summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint/Debian_Stretch.mdwn
blob: bda9a1ddc762c2c9f98ffff55a9a719d666ff449 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
[[!meta title="Porting Tails to Debian Stretch"]]

This is about the effort to create [Tails
3.0](https://labs.riseup.net/code/projects/tails/issues?query_id=198),
based on Debian Stretch.

[[!toc levels=2]]

# Big picture

When porting to Wheezy, our main problem has been that we started the
work too late, which made us discover Debian bugs too late (after the
Debian Wheezy freeze, or even after its release), and in the end we
had to workaround lots of problems on our side.

So we started much earlier the porting work to Jessie, which indeed
essentially avoided the aforementioned problem. But we didn't allocate
enough focused resources to this effort, and as a result the total
duration of the porting to Jessie work has lasted too much (July 2014
to January 2016, included = 19 months), and we've spent too much time
just keeping our feature/jessie branch up-to-date wrt. the changes we
were making in our Wheezy production branches.

For Stretch we would like to avoid both problems. We want to start early,
in order to fix problems directly in Debian Stretch before it's
released. And, we want the porting work to fit into a shorter time
span, so as soon as we start we'll allocate more resources to it, and
in a better organized, team-based and focused way.

Additionally, we would like to use this process as an opportunity to
evaluate the idea of basing Tails on snapshots of Debian testing.

# Schedule

* 2016Q1 — Tails 2.0 is out
* August 2016 — start working on Tails 3.0 (1 week sprint with
  all involved people) :intrigeri:anonym:kytv:
  - get feature/stretch to build and boot
  - update the automated test suite to test Tails/Stretch ISO images
* August 2016 to April 2017 — have one dedicated half-time, 1-week sprint
  every 6 weeks.
  - Schedule these sprints in advance, announce them
    publicly, and invite other contributors (e.g. doc writers).
  - Most of these sprints will probably be attended remotely, but at
    least some could happen face-to-face (at least the first sprint;
    and then, one out of two, i.e. every one every 3 months?).
  - At the beginning of each Stretch sprint, we import a new snapshot
    of Debian testing into our freezable APT repository, so that:
    * during the sprint we update our stuff as required by changes
      that happened in Debian since the last sprint;
    * our stuff is not broken by changes in Debian neither during
      sprints, nor between them;
    * we get a feeling of how "being based on snapshots of Debian
      testing" would work.
* November 14-18th: second sprint (in-person, organized by intrigeri)
* December 20-23: third sprint (remotely attended for everybody except
  a couple of us)
* January 30 - Febuary 3: fourth sprint (remotely attended)
* February 5 2017 — Debian Stretch freeze starts
* March 13-17th: fifth sprint (in-person, organized by sajolida)
* June 2017 (???) — Debian Stretch is released
* June-August 2017 — Tails 3.0 is released

<a id="rolling"></a>

# Let's go rolling

## Stretch cycle

Let's use this porting cycle to evaluate how being based on snapshots
of Debian testing would feel like. During the entire cycle:

* Keep the automated test suite up-to-date on feature/stretch :kytv:
  - Whenever the porting work feels painful, e.g. because it requires
    updating images, consider fixing the problem at its root in our
    current devel branch, e.g. thanks to dogtail
    ([[!tails_ticket 10721]]).

* Keep the documentation up-to-date on feature/stretch (:sajolida:),
  or if it is too ambitious:
  - attend at least one sprint really early in the process, and one
    quite late
  - start doing it for real only once Stretch is frozen
  - before Stretch is frozen, during each Stretch sprint, test the
    documentation in order to:
    * find and report bugs while it is still time to fix them in the
      right place
    * identify what would have required work if we wanted to keep the
      documentation up-to-date on feature/stretch, and take notes
      about it; the goal is here is to gather useful data regarding
      the need to update the same piece of documentation multiple
      times over a given Debian release cycle, which will help us make
      a decision further down the road; it also might help us pinpoint
      specific parts of our documentation that could be updated to
      depend less on varying factors, if any
    * this testing work can be easily joined by newcomers (and we
      should make this clear)

* Take notes of issues we see from the perspective of "how would it go
  if we were based on testing already?". E.g.:
  - How to keep track of security issues that affect us, and whether
    their fix has been uploaded and has migrated to testing yet?
    See e.g. how security support for Debian testing [used to be
    (briefly) done](http://secure-testing-master.debian.net/), and in
    particular the
    [Vulnerable source packages in the testing suite](https://security-tracker.debian.org/tracker/status/release/testing)
    and the
    [Candidates for DTSAs](https://security-tracker.debian.org/tracker/status/dtsa-candidates).
  - How to deal with
    [[!debwiki OngoingTransitions desc="ongoing transitions"]] that
    block migration of security updates from sid to testing?

* Make testing ISOs available widely with clear explanations of what
  to test and what *not* to test. This should happen starting around the freeze
  of Stretch. We could have a message about what to test displayed at bootup of
  test ISOs.

Note that during half of the cycle, we'll be based on a frozen Debian
testing, so the changes rate coming from Debian, that impact the
documentation and test suite work, won't be crazy. Of course there
will be changes coming from our own porting efforts.

Also, note that the work we will be doing after Stretch is frozen is
work we would have to do to port Tails to Stretch anyway: so the only
part of this that is somewhat experimental, and might make us do extra
work, is limited to 4 months (August to November 2016).

## And after?

And then, once Tails 3.0 is out: we're not lagging behind anymore, and
are thus in a position to decide whether we want to base Tails on
snapshots of Debian testing. Chances are that we won't want to be
based on Debian testing during the 6 months that follow a Debian
stable release, so we will have time to make up our mind, and to
prepare the infrastructure and tooling we may need if we decide to
be based on Debian testing.

To sum up how a ~2 years Debian release cycle could look like from our
perspective, if we were based on snapshots of Debian testing:

1. a new Debian stable is released
2. 6 months during which Tails is based on Debian stable that was just
   released
3. 12 months during which Tails is based on a non-frozen Debian
   testing
4. 6 months during which Tails is based on a frozen Debian testing

Let's now analyze and discuss some consequences of this scenario.

We would be based on a moving target half of the time; the remaining
half of the time we are based on something that doesn't change much.

We would need to track 2 Debian versions at the same time (and
continuously forward-port development that was based on the oldest
one) during the first phase only, that is 6 months, compared to the 19
months during which we did that in the Jessie cycle. We would save
lots of time there, that could be re-invested in aspects of this
proposal that will require more time: essentially this idea is about
doing a different kind of work, and doing it at different places; it
won't necessarily lower the total amount of effort we have to do, but
it likely will make such efforts generate less frustration, more
happiness, and a warm feeling of being part of a broader community.

Another aspect is that we would essentially stop having to produce and
maintain backports of Debian packages.