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: […]
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
