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
Re: [Tails-dev] Changing Tails 3.0 release date?
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
Re: [Tails-dev] Changing Tails 3.0 release date? [Was: Planned release of stretch on 2017-06-17 and the last weeks up to the release]
intrigeri: > Hi, > > ni...@thykier.net: >> 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
Re: [Tails-dev] Changing Tails 3.0 release date? [Was: Planned release of stretch on 2017-06-17 and the last weeks up to the release]
Hi! intrigeri: > ni...@thykier.net: >> Release date >> > >> We plan to release on 2017-06-17. > > 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. > > Pros and cons: > > - Option A costs us one more "Emergency releases" i.e. 2.25 days >of work (release management + manual testing). > > - 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? > > - 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: > > * Ulrike (who committed to handle such communication) and sajolida > (who'll likely be needed to review it), do you think you can > realistically take advantage of this opportunity? I think option B being less work in general, for all of us, so IMO we should go this way instead. I can absolutely take the time to prepare communication next week so that sajolida would have enough time to review it. Cheers! u. ___ 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.
Re: [Tails-dev] Changing Tails 3.0 release date? [Was: Planned release of stretch on 2017-06-17 and the last weeks up to the release]
intrigeri: > ni...@thykier.net: >> 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'm sorry but I have no opinion about this. I think it's a cool idea and I'm happy that it motivates you so do whatever option you like best and I'll have the release notes ready by then. Also, don't count on my for time communicating about this release outside of writing the release notes (and I will mention the sync with Debian in there of course). And yes, I know I should start writing these notes early because they are going to be long and complex and require a couple of round trips of reviews :) ___ 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.
[Tails-dev] Changing Tails 3.0 release date? [Was: Planned release of stretch on 2017-06-17 and the last weeks up to the release]
Hi, ni...@thykier.net: > 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. Pros and cons: - Option A costs us one more "Emergency releases" i.e. 2.25 days of work (release management + manual testing). - 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? - 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: * Ulrike (who committed to handle such communication) and sajolida (who'll likely be needed to review it), do you think you can realistically take advantage of this opportunity? * 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. - 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? 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. > 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. 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.
