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]

2017-05-31 Thread anonym
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]

2017-05-31 Thread u
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] [review'n'merge] unfuzzy page in testing branch

2017-05-31 Thread intrigeri
xin:
> Hello, I found another page, please review and merge.

> Repo: https://git-tails.immerda.ch/xin/tails/
> Branch: testing/unfuzzy2
> Last Commit: d4e9d5d8b7fc6b8f51fdc770ec37f5cc4579772c

merging, thanks!
___
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.