Hi,
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
2018-03.
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
months
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?
Cheers,
--
intrigeri
