[Tails-dev] TBB in Tails: Release timing in general

このメッセージを削除

このメッセージに返信
著者: anonym
日付:  
To: tbb-dev
CC: The Tails public development discussion list
題目: [Tails-dev] TBB in Tails: Release timing in general
Hi,

For years Tails has shipped with an Iceweasel with the (relevant) Tor
Browser patches applied. It has worked ok, but it's been high
maintenance, and keeping the preferences synced with TBB was a bit of a
chore, among other issues. Since Tails 1.2 we've migrated to installing
the Tor Browser from the actual (32-bit Linux) TBB tarballs you
distribute. We're very much interested in your comments on how we do
this, so please have look at our design page: [1]

[1] https://tails.boum.org/contribute/design/#index40h3

The main source of *potential* issues this has introduced is the added
dependency on the timing of your TBB releases (rather, when the tarballs
are made available). We aim at releasing Tails with a browser based on
Firefox X.Y.Zesr on the same day as Mozilla officially releases it, i.e.
every sixth Tuesday. Due to the time required for Tails' release process
(including QA) that means that we need the final TBB tarballs based on
that Firefox release *at the very latest* 24 hours before the planned
Tails release.

Just to get an idea, let's have a look at TBB's release history. Below
I'll list the last -buildX tag for a given TBB release that upgrades to
a new Firefox ESR (but I'm skipping exceptions outside the 6-week cycle)
and the timing of when the tag was made vs the "ideal" time of a Tails
release, which we say is at 18:00:00 (UTC) on the Firefox ESR (official)
release day. Just to be clear, a high timing value is good for Tails.

TBB release tag   Tag date (UTC)       Timing vs ideal Tails release
tbb-4.0-build1    2014-10-13 17:34:22  +24 hours
tbb-3.6.5-build1  2014-09-01 05:48:33  +36 hours
tbb-3.6.3-build1  2014-07-24 08:58:10  -39 hours
tbb-3.6.2-build6  2014-06-11 13:30:06  -19 hours
tbb-3.6.1-build1  2014-05-06 12:19:26  -138 hours
tbb-3.5.3-build1  2014-03-17 23:05:35  +19 hours
tbb-3.5.2-build5  2014-02-07 18:14:41  -72 hours


So, now we assume that the "Tag date" above also is the time when the
tarballs are made available for download (and preferable announced on
tor-qa@). Given that we want at least a +24 hours, this history doesn't
look super promising for our (Tails') plans. I'm not sure the above
assumption is very sound, though; for instance, the initial 4.0 tarballs
(before the rebuild for POODLE but we're ignoring such exceptions) was
announced on tor-qa@ on 2014-10-13 10:19:08 (UTC), which was 7 hours
before the tbb-4.0-build1 tag.

In any case it's true that if Tails had migrated to using the TBB in the
beginning of 2014, we'd have trouble with several of our releases due to
late TBB rebuilds. Of course, I'm not complaining that you have
misbehaved. :) So far you haven't been working as an upstream for other
projects so that they get a time window to include TBB and then do a
same-day releases with you, e.g. like how Mozilla is an upstream to you,
and was an upstream for Tails prior to our TBB-migration.

However, do you think you can become such an upstream for Tails by
trying to provide the time window detailed above? If you believe that
window is too narrow, I suppose Tails could drop the "same-day release"
goal and adopt a "day-after release" goal or possible even later. What
do you think is possible? How can we help?

To get a more concrete understanding of what exactly I'm proposing,
let's use the next Tails release, 1.2.1, as an example: It's aimed to be
released at 2014-11-25 18:00:00 (UTC), the same day as Firefox 31.3.0esr
will be officially released. We'd need the (final) TBB (32-bit Linux)
tarballs based on that Firefox version at the latest 24 hours before
that, i.e. 2014-11-24 18:00:00 (UTC). Does that seem reasonable? I'm
actually genuinely interested in an answer to this specific question,
since I'm writing the Tails 1.2.1 release schedule as we speak and may
have to adjust it if this turns out difficult for you to "promise".

Cheers!