[Tails-dev] Basing Tails on quarterly snapshots of Debian Testing: status update… and next steps?

intrigeri intrigeri at boum.org
Tue Nov 7 19:31:24 CET 2017


at the summit this year, contagious enthusiasm from our Foundations
Team lead us to decide to finally give a try to an ambitious project
we've had in mind for a while: basing Tails on quarterly snapshots of
Debian testing (https://tails.boum.org/blueprint/Debian_testing/).

The timeline we picked was: evaluate the feasibility of this idea by
the end of November, then make a decision, and possibly release
a first version of Tails based on Debian testing in 2018-01 or

We did quite some work already:

 - We ported most of Tails to Debian Buster. It works pretty well!
 - We adjusted most of our test suite accordingly. A few glitches
   remain but I'm not worried.
 - We designed a process and implemented tools that will allow us to
   tell technical writers what part of the documentation is affected
   by changes in our code, test suite, or installed packages.
 - We adapted the Debian Security Tracker code to track security
   issues fixed in Debian but not in the snapshots Tails uses, and
   started to think about how exactly we'll triage them and fix the
   most important ones.

It made us quite confident that this idea was not totally stupid.

Quite some more work is needed before we can reasonably say "yeah,
let's do it for a year". Besides, between such work sessions we need
to let some time pass: some of the things we need to evaluate are
about dealing with external changes that we can't easily simulate.

I estimate we need three things to happen before we can make
a decision:

1. A first work session to:

    - finish porting the test suite so we can assess the quality of
      our current Tails/Buster ISO
    - make progress on the evaluation of "how to deal with security
      issues" and set up everything we need for step #2
    - bootstrap the evaluation of "how to deal with transitions"
      and set up everything we need for step #2
    - start looking into smaller issues like those caused by larger
      automatic upgrades (IUKs) and where Additional Software Packages
      will be pulled from
    - freeze APT snapshots!

2. A 6-12 weeks period during which we continuously do the work we
   would have to do, were we based on a snapshot of Debian testing, to
   keep track of and address security issues, in a real-world context,
   i.e. with ongoing transitions in Debian.

3. A second work session to:

    - complete the evaluation of "how to deal with security
      issues" and "how to deal with transitions"
    - bump APT snapshots, adjust our code base and test suite as
      needed, check the impact on documentation
    - decide something

My Foundations Team colleague had to drop the ball on this project for
personal reasons, and it would be unreasonable from me to commit to do
all this alone in the initially planned time-frame. And regardless,
how I see it today, we really need step #2 to last at least 6 weeks,
so steps 1-3 can't be done by the end of November.

So I see three options:

A. Drop the ball entirely for the Buster cycle, and possibly come back
   to it for the next Debian release cycle (Debian 11 aka. Bullseye)

    - pros: less work to do right now
    - cons: we get none of the expected benefits of this project, e.g.
      we have to deal with Stretch bugs and backports for ~18 more

B. I keep working on this alone and at my own pace

   I think I can do step #1 by the end of the year, and step #2 + #3
   by the end of March, worst case by the end of April. So we would
   target the June release and we'll only be based on a non-frozen
   Buster for a something like 3-6 months.

    - pros: less ambitious than the original plan so if this doesn't
      work well between June and the Buster freeze, we don't suffer
      for too long; and we already get some data points that will help
      us make our decision for Bullseye

    - cons: we get less data points to make a decision for Bullseye
      than with the origin plan or with option B

C. I get team-mates and we do the work in a timely manner in order to
   reach a decision ASAP, say by the end of January, so we can target
   the 2018-03-06 release

   Pros/cons: exactly the opposite of B's

   Required skills: good knowledge of the Debian ecosystem (release
   cycle, transitions, handling of security issues) and/or of Tails
   system integration glue i.e. what we call "code" here.

   We don't have many potential candidates in Tails currently, and
   they're all busy with other projects that I absolutely don't want
   to disrupt.

   It's unclear if we can pay this work right now, which is a blocker:
   I can't reach out to my favorite external contractors who would
   probably be happy to get onboard. If we think we should try this
   I can look into the money aspect more closely.

My personal preference would be:

  C (assuming the money thing is solved) >> B >> A

How do you feel? What do you think? Other options I overlooked?


More information about the Tails-dev mailing list