Release Tails soon after Tor Browser and Firefox

Why?

This would lower our time-to-remediation for vulnerabilities fixed in Firefox (and thus Tor Browser) releases.

Other requirements

We value some properties, to be balanced with other factors and expected benefits:

• predictability
• robustness against small unexpected-but-somewhat-foreseeable delays, that happen pretty often: they should not lead to postponing RM and QA work significantly
• little (ideally no) work outside of our preferred hours

Background

A few years ago we lacked predictability of when the Tor Browser tarballs would be ready: this varied a fair bit. Since this blocks our release process, and we needed predictability of our own release management work, we settled on releasing the next Tuesday after Firefox and Tor Browser. Since then, the Tor Browser team grew stronger and now gets these tarballs ready on a more predictable schedule. Also, in case this predictability is not 100% yet: our own RM+FT team has grown stronger, and we're changing how we're doing the corresponding QA ( #19018), so we are in a slightly better position to cope if we exceptionally have to postpone a bit the release process and QA.

Statu quo

version	announced on tor-qa	Tails release
13.0.9	Mon Jan 22 14:07:27 UTC 2024	Tails 5.22
13.0.10	Tue Feb 20 11:06:06 UTC 2024	Tails 6.0
13.0.11	Wed Mar 6 11:54:15 UTC 2024	irrelevant
13.0.12	Tue Mar 19 15:03:24 UTC 2024	irrelevant
13.0.13	Fri Mar 22 16:38:16 UTC 2024	Tails 6.1
13.0.14	Tue Apr 16 00:53:47 UTC 2024	Tails 6.2
13.0.15	Mon May 13 14:36:47 UTC 2024	Tails 6.3
13.0.16	Tue Jun 11 17:57:50 UTC 2024	Tails 6.4
13.5.1	not announced	Tails 6.5
13.5.2	Tue Aug 6 07:09:14 UTC 2024	Tails 6.6
13.5.3	Tue Sep 3 16:33:44 UTC 2024	Tails 6.7
13.5.4	Tue Sep 17 15:33:14 UTC 2024	irrelevant
13.5.5	Thu Sep 26 19:15:53 UTC 2024	irrelevant
13.5.6	Tue Oct 1 15:42:50 UTC 2024	Tails 6.8

• week N, Tuesday: the final Tor Browser build is ready
  • See archives of the tor-qa@ mailing list. In most cases we could use a build before it's announced there, but this increases the risk we have to ditch some work, redo it, and postpone our release. So to start with, let's look at the worst case scenario and see how much it buys us compared to the status quo.
• week N, Tuesday: Firefox and Tor Browser release
• week N, Wednesday-Sunday: a Tails developer updates Tor Browser on the stable branch
• week N+1, Monday-Tuesday: release process

Proposals

A. Release 2 days after Tor Browser

With a bit of occasional work outside of office hours on Tuesday night, we can do this:

• week N, Tuesday: the final Tor Browser build is ready
• week N, Tuesday: Firefox and Tor Browser release
• week N, Tuesday late afternoon: a Tails developer imports the new Tor Browser in a MR
• week N, Wednesday first thing in the morning: merge the MR
• week N, Wednesday-Thursday: release process

Analysis:

• Worth trying -- intrigeri

Feedback about 6.9

We've tried proposal A for Tails 6.9, here's our feedback about it:

• As the RM (intrigeri):
  • tl;dr: It was smooth sailing.
  • On Tuesday (Tor Browser release day, the day before I start the release process), I need clear communication wrt. whether the plan is realistic, from the team-mate who takes care of the Tor Browser update. (I don't need to follow the progress step-by-step. What I need is an assessment of how likely it is that I can start preparing the release on Wednesday 9am local time.) When everything goes according to plan, such communication is "only" (sic) a well-being thing: it builds confidence in the plan and decreases uncertainty. And in case not everything goes according to plan, such communication will be critical to adjust the plan (or at least, anticipate the need for such adjustments).
  • The release was published early on Thursday, so there was quite some margin for error: even with some bad surprises, I'm confident we would have managed to release today. And if the release notes had been prepared earlier on Wednesday, I would have published the release yesterday night, which would have cut our time to remediation down by another 14 hours or so.
  • I'm very happy I did not have to do RM work on days when we have recurring meetings. This lowers my stress levels and allows me to be more focused and better prepared for the meetings. Multitasking is a myth, it's just high-frequency context switching, and a RM trying to attend a meeting while having an eye on the release process rarely manages to do both very productively.
• As the person who imported Tor Browser (anonym):
  • I find it hard to track the plan/status of the Tor Browser release, that info is not recorded in a consistent manner AFAICT, so with margins this tight I had to ask them. That used to be the case years back when we aimed to release Tails the same day as Tor Browser, and I always felt like I was nagging them. It would be awesome if we were more in the loop about the plans without having to waste a lot of time following everything.
  • If I were the RM I would definitely not delegate this to another team member unless absolutely necessary (i.e. I'm not available that day), and do it myself. It's not a lot of work, and I'd much prefer that over the overhead/uncertainty intrigeri mentions above about having it delegated.
• As people who did the QA work (anonym, boyska)
  • anonym: No difference compared to other releases.
  • boyska: just fine: I book some slots of my workday and I'm available during that slots, so it doesn't really matter (assuming the release is smooth).
• As the technical writer who wrote the release notes (sajolida)
  • TBD

B. Release 6 days after Tor Browser

With no work outside of our preferred hours ever, it looks like we can't reasonably plan more optimistically than this:

• week N, Tuesday: the final Tor Browser build is ready
• week N, Tuesday: Firefox and Tor Browser release
• week N, Wednesday: a Tails developer updates Tor Browser on the stable branch
• week N, Thursday: start the release process (build, start QA)
• week N+1, Monday morning: finish release process

Analysis:

• I don't think releasing 1 day earlier is worth changing what we're currently doing. -- intrigeri

Drawbacks

• Releasing earlier probably implies we generally won't include the corresponding Thunderbird security release.
  • Rebuttal:
    • Most of the vulns fixed in Thunderbird don't affect Tails in the default configuration. While they do affect our Tor Browser.
    • That's a trade-off we made consciously when we switched to Thunderbird. That's why we bothered maintaining AppArmor policy for it.

Out of scope

• Emergency releases: they are their own thing and don't follow our usual schedule

To Do

• Gather data to fill the "XXX" above
• Draft proposed new schedule based on updated data
• Try proposal A
• Gather pros & cons
• Discuss → decide
• Implement
• Consider updating https://tails.net/contribute/release_schedule/
  • Possibly simplify or remove info we fail to maintain: this page seems very outdated, did that cause real problems?