Hi,
[this time, explicitly adding "Modified" to the subject line; I'll
ping the team leads for affected sponsor deliverables off-list so they
can check with their team; same for release managers.]
Deadline to reach a conclusion: January 15
Mozilla announced that the next Firefox ESR will be 60. This impacts
our release schedule because it implies that Tor Browser will switch
to this new ESR on 2018-08-28. Too bad, we've already adjusted all our
plans in function of the 2018-07-03 release being a major one, and the
2018-08-28 one being a bugfix one, which cannot work anymore :/
Lesson learnt: next time, wait until January to finalize our plans,
and before that treat all kinds of planning as subject to change.
If you're in a rush, skip directly to the "Proposal" section and make
sure it works for you.
Current (obsolete) plan
=======================
For the record our current, now obsolete plans are:
* 2018-01-23: Release 3.5 (bugfix release) — anonym is the RM
* 2018-03-13: Release 3.6 (major release) — bertagaz is the RM
* 2018-05-08: Release 3.7 (bugfix release) — bertagaz is the RM
* 2018-07-03: Release 3.8 (major release) — intrigeri is the RM
→ includes ESR59 and our work on Additional Software Packages
* 2018-08-28: Release 3.9 (bugfix release) — anonym is the RM
* 2018-10-23: Release 3.10 (major release) — anonym is the RM
→ adds VeraCrypt support
* 2018-11-27: Release 3.11 (bugfix release) — anonym is the RM
Proposal
========
Here's my proposal (see below for the detailed reasoning):
* 2018-01-23: Release 3.5 (bugfix release) — anonym is the RM
* 2018-03-13: Release 3.6 (major release) — bertagaz is the RM
* 2018-05-08: Release 3.7 (bugfix release) — bertagaz is the RM
* 2018-07-03: Release 3.8 (bugfix release) — intrigeri is the RM
* 2018-08-28: Release 3.9 (major release) — anonym is the RM
→ includes ESR60 + VeraCrypt support + Additional Software Packages
* 2018-10-23: Release 3.10 (bugfix release) — anonym is the RM
* 2018-11-27: Release 3.11 (major release) — anonym is the RM
→ the most likely first Tails release based on Debian testing,
*if* we decide to try it out.
Detailed reasoning
==================
Here's the source code, happy debugging!
Regarding version numbers: there's been enough confusion with changing
numbers and dates of upcoming releases in the last few months, so
I propose we do not change the version number <-> date mapping we
already have for 2018. And I've (finally…) changed my mind recently
wrt. the cost/benefit of sticking to the odd=bugfix/even=major
convention, after I heard a Tails contributor explaining in a talk
that "we'll skip 3.4 because the project lacks resources". I think
I was the only one explicitly pushing for this scheme so I bet
(almost?) everyone will be happy to switch to meaningless — but less
confusing — incrementing version numbers, starting with Tails 3.5.
If I'm guessing wrong, let me know. I'm flexible on that topic this
year and don't want to discuss it endlessly, especially since we'll
need to discuss it again if we end up basing Tails on Debian testing
one of these days.
Regarding the January and March releases: by now, I think too many of
us have organized their work based on the fact they would respectively
be a bugfix and a major one, so let's keep it this way.
We need to make the 2018-08-28 a major release. I don't think we can
afford doing 3 major releases in a row in July, August and October we
need to change our plans at least for the July and October releases,
and hopefully the domino effect won't be too big. Let's see.
Let's assume the July release is a bugfix one. This implies we cannot
release the Additional Software Packages work in there. The current
plan is to write the code early in March, release a beta on April 15,
then conduct user testing and fix issues it will identify. It might be
doable to shift all this and release in May but that would imply doing
two major releases in a row (March + May), so let's forget it and
release in August instead.
Regarding VeraCrypt, the plan encoded on Redmine is to have everything
upstreamed and integrated into Tails in time for the August release,
so we should be able to release it on 2018-08-28 and make the
2018-10-23 release a bugfix one (and in turn, the 2018-11-27 becomes
a major release). @segfault + @anonym: if Redmine is wrong and that
does not work, let's talk.
Regarding RM'ing, I've just kept release date <-> RM as-is and then
we'll discuss possible changes within the RM team.
Regarding plans some of us might have had to ship new features in July
(that can't work anymore if the July release is a bugfix one): I've
checked Redmine and could find no such thing.
Regarding porting to ESR60 (#15023): I *think* that doing this work in
July + August may actually be nicer to anonym than May + June.
@anonym: if this new schedule does not work for you, let's talk.
Cheers,
--
intrigeri
