intrigeri:
> Hi,
>
> [this time, explicitly adding "Modified" to the subject line; I'll
> ping the team leads for affected sponsor deliverables off-list so they
> can check with their team; same for release managers.]
>
> Deadline to reach a conclusion: January 15
>
> Mozilla announced that the next Firefox ESR will be 60. This impacts
> our release schedule because it implies that Tor Browser will switch
> to this new ESR on 2018-08-28. Too bad, we've already adjusted all our
> plans in function of the 2018-07-03 release being a major one, and the
> 2018-08-28 one being a bugfix one, which cannot work anymore :/
>
> Lesson learnt: next time, wait until January to finalize our plans,
> and before that treat all kinds of planning as subject to change.
Agreed!
> Current (obsolete) plan
> =======================
>
> For the record our current, now obsolete plans are:
>
> * 2018-01-23: Release 3.5 (bugfix release) — anonym is the RM
>
> * 2018-03-13: Release 3.6 (major release) — bertagaz is the RM
>
> * 2018-05-08: Release 3.7 (bugfix release) — bertagaz is the RM
>
> * 2018-07-03: Release 3.8 (major release) — intrigeri is the RM
> → includes ESR59 and our work on Additional Software Packages
>
> * 2018-08-28: Release 3.9 (bugfix release) — anonym is the RM
>
> * 2018-10-23: Release 3.10 (major release) — anonym is the RM
> → adds VeraCrypt support
>
> * 2018-11-27: Release 3.11 (bugfix release) — anonym is the RM
>
>
> Proposal
> ========
>
> Here's my proposal (see below for the detailed reasoning):
>
> * 2018-01-23: Release 3.5 (bugfix release) — anonym is the RM
>
> * 2018-03-13: Release 3.6 (major release) — bertagaz is the RM
>
> * 2018-05-08: Release 3.7 (bugfix release) — bertagaz is the RM
>
> * 2018-07-03: Release 3.8 (bugfix release) — intrigeri is the RM
>
> * 2018-08-28: Release 3.9 (major release) — anonym is the RM
> → includes ESR60 + VeraCrypt support + Additional Software Packages
>
> * 2018-10-23: Release 3.10 (bugfix release) — anonym is the RM
>
> * 2018-11-27: Release 3.11 (major release) — anonym is the RM
> → the most likely first Tails release based on Debian testing,
> *if* we decide to try it out.
+1
It still looks good to me, RM-wise (I get an extra major release, back to my usual 2/year, which means less these days when reviewing is on the FT plate). However, Mozilla's change most likely does fuck my vacation plans in July since starting to work on ESR60 integration when I planned to return in the beginning of August seems risky.
> Detailed reasoning
> ==================
>
> Here's the source code, happy debugging!
>
> Regarding version numbers: there's been enough confusion with changing
> numbers and dates of upcoming releases in the last few months, so
> I propose we do not change the version number <-> date mapping we
> already have for 2018. And I've (finally…) changed my mind recently
> wrt. the cost/benefit of sticking to the odd=bugfix/even=major
> convention, after I heard a Tails contributor explaining in a talk
> that "we'll skip 3.4 because the project lacks resources". I think
> I was the only one explicitly pushing for this scheme so I bet
> (almost?) everyone will be happy to switch to meaningless — but less
> confusing — incrementing version numbers, starting with Tails 3.5.
Yes, I will be happy! However, I also pushed for this (I might even have been the one proposing it?), thinking it would a good idea from my RM PoV. Lesson learned, it was too confusing, KISS rules! :)
> Regarding the January and March releases: by now, I think too many of
> us have organized their work based on the fact they would respectively
> be a bugfix and a major one, so let's keep it this way.
>
> We need to make the 2018-08-28 a major release. I don't think we can
> afford doing 3 major releases in a row in July, August and October we
> need to change our plans at least for the July and October releases,
> and hopefully the domino effect won't be too big. Let's see.
>
> Let's assume the July release is a bugfix one. This implies we cannot
> release the Additional Software Packages work in there. The current
> plan is to write the code early in March, release a beta on April 15,
> then conduct user testing and fix issues it will identify. It might be
> doable to shift all this and release in May but that would imply doing
> two major releases in a row (March + May), so let's forget it and
> release in August instead.
>
> Regarding VeraCrypt, the plan encoded on Redmine is to have everything
> upstreamed and integrated into Tails in time for the August release,
> so we should be able to release it on 2018-08-28 and make the
> 2018-10-23 release a bugfix one (and in turn, the 2018-11-27 becomes
> a major release). @segfault + @anonym: if Redmine is wrong and that
> does not work, let's talk.
>
> Regarding RM'ing, I've just kept release date <-> RM as-is and then
> we'll discuss possible changes within the RM team.
>
> Regarding plans some of us might have had to ship new features in July
> (that can't work anymore if the July release is a bugfix one): I've
> checked Redmine and could find no such thing.
Thanks for the source code! :) I agree so far.
> Regarding porting to ESR60 (#15023): I *think* that doing this work in
> July + August may actually be nicer to anonym than May + June.
> @anonym: if this new schedule does not work for you, let's talk.
I would really rather keep my July completely free of Tails-work. Any way, none of this blocks your proposed schedule so let's discuss that in some other thread/channel if needed (I'll think about it).
Cheers!
