anonym:
> I have a few somewhat inter-related proposals, all with quite
> significant implications. I suggest that if we want to implement any of
> them (even in variations), we do so all at the same time immediately
> after releasing Tails 3.0.
You sent this to tails-dev, tails-project, and tails-ux which is good
but didn't specify on which list we should centralize the rest of the
discussion. Last time [1] we did that on tails-dev, so let's do the same
this time again.
[1]:
https://mailman.boum.org/pipermail/tails-dev/2015-May/008960.html
> Proposal 1: let's adopt a skip-free versioning scheme
> -----------------------------------------------------
>
> [...]
>
> * There's never any need for skipping releases! => less user confusion.
> And for some bizarre reason I like that it is economical by not wasting
> numbers so it will even bring me some mental satisfaction! :P
Another benefit in being economical is that we'll be less likely to
reach two digit numbers and have for example 2.11 and 2.1.1 which could
also lead to confusion.
> Old New
> ----- -----
> 2.0 2.0
> 2.0.1 2.0.1
> 2.2 2.1
> 2.2.1 2.1.1
> 2.3 2.1.2
> 2.4 2.2
> 2.5 2.2.1
> 2.6 2.3
> 2.7 2.3.1
> 2.7.1 2.3.2
> 2.9 2.3.3
> 2.9.1 2.3.4
I like that!
> Proposal 2: simplify the QA of emergency releases
> -------------------------------------------------
>
> [...]
>
> As the (Mostly) Eternal Release Manager, who has experienced quite a few
> emergency releases by now, less QA at those times would be ${deity}sent.
> In fact, if we could formalize the practice of comparing the new ISO
> with the last release [1], and make that + manual tests of only
> upgraded/modified software + a full pass of the complete automated test
> suite all the QA we require, then emergency releases would be a single
> days work for an RM and no one else is blocking the release. Except the
> "Changes" section of the manual test suite, which must be done by
> someone else than the RM. I think we can allow the review to happen up
> to a few days after the emergency release was made public. If you
> disagree, well, this is what has already happened to us a couple of
> times (e.g. both 2.9 and 2.9.1 :)) so if we enforced your wish that
> means we sometimes will stall security fixes in fear of *potential*
> security issues [2] ... which feels wrong.
>
> Proposal 3: treat X.esr as just another emergency release
> ---------------------------------------------------------
>
> [...]
>
> This would also significantly reduce the amount of manual testing we do
> -- we'd only do it for RCs and major releases, so twice every 12 weeks
> instead of three or more times (i.e. emergency releases) during the same
> duration. It would also reduce the RM budget since what we now call
> "point releases" would be a bit less work. Yup, I'm slowly initiating my
> own retirement (as RM! Not from Tails! :)).
>
> [...]
>
> The only real drawback I see with this is that low-prio bugfixes will
> take a longer time to reach users, since we won't ship those in X.esr
> releases any more.
Seeing the RM work only from very far away, I'm very happy to see that
this is going in the direction of doing less RM work overall. Which
means less work, less testing, less money, less stress, more fun, etc.
Even if the cost to pay is to have to wait longer before changes
(improvements or low-prio bugfixes) get to the users I think it's worth
it given the current state of the project in terms of resources.
> Proposal 4: drop the 'devel' branch and use 'master' for development
> --------------------------------------------------------------------
>
> [Depends on Proposal 3.]
>
> While we are going crazy and retiring 'stable', why not retire 'devel'
> as well, and make 'master' the actual development + live website branch?
> I think there might have been historical reasons for this split, but I
> fail to see any good reasons now. I think this model is simpler and more
> self-explanatory, and it's also more "standard" of how most Git repos
> are organized (in my experience). That would decrease the barrier to get
> involved in Tails development, I think.
I'm not sure to fully understand the consequences here. But would this
still work when we update the doc (sometimes heavily) in devel? Like
when we prepared the replacement of Claws Mail by Icedove? In which
branch would we merge this (along with the corresponding code) in your
proposal?
> PS. Proposal 5: rename the 'master' branch to something more inspiring
> and egalitarian, like 'comrade'... :)
Don't get me started on terminology discussions! :)
