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). > 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: […] ACK, added to the ticket. Cheers! -- intrigeri _______________________________________________ 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.
