Re: [Tails-dev] Changing Tails 3.0 release date?

On Thu, 2017-06-01 at 10:18 +0200, intrigeri wrote:
> hi!
>
> anonym:
> > intrigeri:
> > > I'll make the call as the 3.0 release manager if no consensus
> > > emerges,
>
> After re-reading this discussion, it appears that the only people
> substantially affected by this decision (apart of Tails users of
> course) will be myself and our usual manual testers. So I'll make the
> call by the end of this week, depending on how I feel about committing
> to RM'ing an extra release. I may follow anonym's very reasonable
> position, or go crazy for the sake of communication and
> Debian/Tails/FOSS relationships. I'm undecided yet and want to sleep
> on it and balance all this very carefully.
>
> > > A. Coordinate Tails 3.0 and Debian Stretch releases
>
> [...]
> > > B. Don't bother and proceed as our calendar says
> > >  - 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.
>
> OK, thanks for the insight!
>
> > >  - 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. :)
>
> Great :)
>
> > > 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.
>
> Absolutely. This will be particularly painful for those who will have
> to do a manual upgrade to 2.12.1, as everyone will have to do a manual
> upgrade to 3.0 anyway.
>
> On the other hand, if 2.12.1 is a thing, we give users almost two
> months to upgrade to 3.0 (vs. 0 days if we don't release 2.12.1),
> which is nice as they're often scared by such drastic change; also,
> anyone affected by a serious regression can temporarily downgrade to
> 2.12.1 until Tails 3.1 fixes their problem.
>
> So all in all it's not clear cut to me which option provides the
> greater UX (once considering dozens of thousands of real-world users,
> and not only some theoretical, ideal one who would immediately upgrade
> to 3.0 and not have any big problem with it).

Agreed ....
IMHO users come first ... continuity is not an optional.
3.x can wait

> > 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.
>
> OK, thanks for sharing, I want to take this into account.
>
> I'm committed to be the RM for 3.0 already; I understand you don't
> feel like taking care of 2.12.1 so let's assume I would handle both
> releases myself (if I convince myself that option A is the way to go).
> And then the additional work is only on my shoulders (I don't feel
> exhausted personally) and manual testers' (no idea how they feel about
> it, but we had no problem getting manual testers recently, did we?).
>
> In passing: we have 4 emergency releases budgeted this year, and we
> did none of them yet. Given this data + the feelings you're sharing,
> I think we should acknowledge that we probably won't do more than
> 2 emergency releases this year. If you agree, I'll update our
> accounting accordingly, so nobody counts on (paid) RM work that's
> unlikely to happen in practice, first because there's no need for it,
> second because our RMs are not exactly thrilled at the idea of doing
> this work. Fair enough?
>
> > Yup, I'm quite a lot in favor of option B.
>
> Got it.
>
> > > 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.
>
> [...]
>
> > [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? :)]
>
> I'm sorry I even asked this question, as it doesn't make any sense:
> the only work option A adds to our reproducible builds developers'
> plate is reviewing'n'merging a branch for Tor Browser 7.0, which
> pretty often we just skip anyway (the RM often has to merge his own
> work at this point of the release process), and if we do it this time,
> the amount of additional work feels totally negligible compared to
> your remaining workload for 3.0. So I really don't see how the option
> A vs. option B decision can affect whether Tails 3.0 is reproducible
> or not.
>
> > > > 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.
>
> Well, usually we freeze for the RC ~10 days before the release.
> This time, if we keep our current snapshots (2017051803) then we would
> lose 3 weeks of updates.
>
> Given there's no security archive for Debian testing, the only way to
> get security fixes is to bump these snapshots, or manually go through
> the list of updates and go through our freeze exception process for
> a (probably not that small) number of packages that fix security
> issues or bugs that can affect Tails. I'm utterly confident with the
> job the Debian release team is doing wrt. avoiding regressions in
> testing at this stage of the freeze, so I vastly prefer just bumping
> the snapshots compared to spending time cherry-picking a plateful of
> security updates and bugfixes. Sounds reasonable?
>
> Of course, if we were not during a time when testing is very very
> frozen, I would probably make the opposite decision.
>
> > I believe this bump will require us to cherry-pick at least these
> > commits from devel into testing: […]