intrigeri:
> Hi,
>
> niels@???:
>> Release date
>> ============
>
>> We plan to release on 2017-06-17.
>
>> […]
>
> Yeah! I'm relieved this is now public info and we don't have to
> discuss our plans privately within a tiny Tails release managers
> cabal anymore.
>
> So, what should we do about it? I'll make the call as the 3.0 release
> manager if no consensus emerges, but I first need some input from
> a few people (at least anonym, Ulrike, and sajolida) to make up my
> mind, so please read on :)
>
> I see two options:
>
> A. Coordinate Tails 3.0 and Debian Stretch releases
>
> We can prepare two releases at the same time: 2.12.1 and 3.0.
> Both should be ready (including release notes, uploading ISO,
> manual testing) on June 13. But on June 13 we release 2.12.1 only
> (we have to release _something_ on that day anyway due to the
> Firefox security updates), and we wait until June 17 to publish
> Tails 3.0, at the same time as Debian Stretch.
>
> B. Don't bother and proceed as our calendar says
>
> I.e. simply release Tails 3.0 on June 13.
I agree these are the only reasonable options we have.
> Pros and cons:
>
> - Option A costs us one more "Emergency releases" i.e. 2.25 days
> of work (release management + manual testing).
Ouch.
> - Option A forces us to integrate Tor Browser 7.0 into Tails 2.x:
> this work has been based on the Tails 3.x codebase so far. I don't
> know if rebasing it onto the stable branch would be trivial, or
> a lot of work. anonym, what's your feeling?
Cherry-picking these commits will not result in any difficult conflicts (it's mostly about s/32/64/, and some jessie vs stretch test suite images). But there could be issues with running 7.0a4 on Tails Jessie/i386 -- we haven't tested the 7.x series at all on that platform. Still I definitely believe it quite a bit more likely to Just Work rather than introduce issues we don't see on Tails Stretch/amd64. So my feeling is that this should be an hour of work.
> - Option B is less work, therefore it increases the chances that we
> manage to make 3.0 build reproducibly, which gives us good
> communication opportunities. So:
>
> [...]
>
> * anonym (who is our lead developer on the reproducibility front):
> if we go with option B, how confident are you that 3.0 can
> build reproducibly? #12608, #12567 and #12566 should be good
> starting points.
At least for me, locally, the only problem I see (after applying all unmerged fixes) is that Chris' patch for #12567 seems to miss some case. I've asked for an ETA of a fix. So assuming Chris is available, or I manage to identify and fix the issue, it's looking really good. :)
> - Option A gives good opportunities for communication:
>
> * On Tails' side: we can point out that we're releasing on the
> exact same day as Debian (which is a stronger symbol than 4 days
> earlier); I would love to see this happen as a way to re-affirm
> our strong relationship with Debian, which has been very
> important so far in terms of how we fit into the Debian
> community and the broader FOSS world.
>
> * On Debian's side: they can mention our release in
> their communication. But TBH they can probably do it anyway
> even if Tails based on Stretch is out earlier than June 17.
>
> Other pros/cons or thoughts?
A con for option A:
* Users will be prompted to do two updates within four days, which is a bit much both in terms of nagging frequency, bandwidth usage, and pure inconvenience.
I'd also like to stress (pun intended!) the fact that option A's "more work" (as in an extra release, 2.12.1) is not so suitable at this time. I think we're collectively exhausted, and should try to take whatever breaks we can.
Yup, I'm quite a lot in favor of option B.
> The decision algorithm I intend to use is:
>
> - If the reproducible builds people tell me they can make 3.0
> reproducible and communicate about it _only_ if we pick option B,
> then I'll go this way.
>
> - Otherwise, if the reproducible builds plans are less clear, then:
>
> if it's not too hard to integrate Tor Browser 7.0 into Tails 2.x,
> and anonym+I find a way to share the additional RM'ing work,
> then I'll pick option A
>
> else, I'll fallback to option B.
[I might consider sabotaging option A by pretending, as a reproducible buids person, that "Tails 3.0 will only be reproducible if we pick option B". Will I have to? :)]
>> The final weeks up to the release
>> =================================
>
> [...]
>
>> In the last week prior to the freeze, testing will be completely
>> frozen and only emergency bug fixes will be considered in this period.
>> Please consider Friday the 2017-06-09 at 13:00 UTC the absolute last
>> moment for changes to stretch.
>
> So I plan to bump our APT snapshots serials on 2017-06-09: #12609.
Huh, I thought we would stick with the snapshot we froze for ~rc1 as usual. I believe this bump will require us to cherry-pick at least these commits from devel into testing:
f9941c1c77 Fetch the torbrowser-launcher sources from Debian sid.
fc8d513540 Drop now irrelevant build hook causing FTBFS.
75f1a839eb Drop bilibop patch.
Cheers!
