Hi,
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.
Proposal 1: let's adopt a skip-free versioning scheme
-----------------------------------------------------
I have a feeling version skipping (as permitted by our versioning
scheme) is a bad idea after talking with some users (and I also get
those vibes from some core contributors). I'm sure the sudden jump from
2.7.1 to 2.9.1 will raise some questions.
So, I propose the following changes to the current scheme:
* The first two numbers are only used for major releases; the first
number works exactly like before, and the second number is now simply
dedicated to major releases. Whether numbers are even or odd doesn't
matter any more.
* The third number is used for both planned point releases and emergency
releases. It simply increments by 1 for each of them.
Think about it: what is the difference between an emergency release and
a point release? Well, the latter type of release is planned. We have
pretended that they are fixed points in time which is useful when
coordinating work (as codified on Redmine's Target version field). It
hasn't worked great in practice, e.g. tickets that aimed at "two cycles
in the future" when we released 2.7 was set to 2.9, but when we skipped
2.8 (due to downgrading a major release to a stable release) that
suddenly meant that those tickets moved a cycle back when we dropped
2.9. And so on.
[IMPORTANT: note that below "X" is a major release, so it is the first
two version numbers, e.g. 2.10, not just the first number!]
I think this new scheme combined with the following trick will only
improve things:
* Between each new major releases X and Y we create a placeholder
version called X.esr with the due date same as the next *planned*
Firefox ESR. Whenever we schedule an emergency release, we simply
increment the third number (imaging it as zero if absent) so after X we
have X.1, X.2, ... . All "Fix committed" tickets from X.esr or (X+1)
that has been merged into 'stable' are moved to this new release.
Some implications:
* 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
* For all major releases X, X and X.esr provide work synchronization
points with the same granularity as versions have for us now (i.e. each
*planned* Firefox ESR release) but they are more stable since there's no
skipping. Now Redmine comments and emails talking about release X will
retain their meaning forever! :)
* It's even easier than now to distinguish if a release is a major
release, but once an X.esr is renamed to a proper point release, then it
cannot be inferred that it actually was what we now call a "point
release". I'm not sure this is so bad (especially if we implement
Proposal 3 below).
Here's a comparison between our current version scheme, and the proposed
new one:
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
IMHO, the new scheme produces a much nicer looking progression with
fewer surprises for users, and communicate the type of the release more
clearly. Well, not for "point releases", but I sort of question the
relevance of being able to do that (also, Proposal 3 would fix this).
Also, look how the strange 2.7.1 -> 2.9.1 upgrade we have now turns into
2.3.2 -> 2.3.4, i.e. only 2.3.3 (=2.9) was never released (but not
skipped!).
Proposal 2: simplify the QA of emergency releases
-------------------------------------------------
[No dependencies. And unlike all other proposals, I'd like to implement
this one *now*.]
[Background: with our current branch organization and workflow, we will
ship all bugfixes that have been merged since the last release in
emergency releases. Even though they have been reviewed, it's not
uncommon that issues are detected during the manual test session.]
True emergency releases are not prepared from the 'stable' branch but
instead we prepare them in a new branch we could call 'security'. This
way we can remain even more conservative with new code for emergency
releases, making the QA way easier. So when merging a branch we'd merge
it into 'security' only if:
* it is a security fix triggering an emergency release.
* it is a security fix that is not important enough for triggering an
emergency release by themselves, but that still would be nice to have
out ASAP.
Note that "security fix" includes UX regressions since they imply bad
usability, and usability is just one of many aspects of a holistic
security perspective (Kumbaya!).
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.
[1] By trying to rule out every modified file as "not relevant" vs the
manual test we did last release, so it can be skipped this time. When
something seems relevant we require that the manual tests we suspect
might be influenced are performed for this emergency release.
[2] After all, getting the fix out ASAP guarantees that some issues are
fixed, which is more important to focus on compared to a reasonably
small probability that those fixes introduces serious regressions that
the "giant diff" review would catch.
Proposal 3: treat X.esr as just another emergency release
---------------------------------------------------------
[This depend on Proposal 2, I think. And if we don't adopt Proposal 1,
just read "X.esr" as "point releases".]
Let's treat X.esr as a true emergency release by also preparing it from
the 'security' branch with simplified QA (but it would always include
the browser parts of the manual test suite, of course). This means that
the 'stable' branch can be retired, I think, since we now have nothing
resembling our old "point releases" where we ship low-prio bugfixes.
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! :)).
Another implication of this is that at least for code tickets, we should
only use major releases as work synchronization points. We can work
around that by adopting: whenever we mark a X.esr code ticket as "Fix
committed" or "Resolved", we move those tickets to (X+1). Or, whenever
something targeting X.esr is merged into 'devel', it must be moved to (X+1).
Now I feel that the proposed new versioning scheme does a great job
reflecting on the nature of each release; now a bump of the third number
only means a security release.
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.
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 quite like the look of this branch organization:
master - development branch, and the live website
security - used for emergency releases; security (incl. UX) fixes only
testing - used for preparing RCs, and post-freeze merges
instead of what we have now:
master - live website, and ~the state of the last release
stable - used for emergency releases and point releases
testing - used for preparing RCs, and post-freeze merges
devel - development branch
Cheers!
PS. Proposal 5: rename the 'master' branch to something more inspiring
and egalitarian, like 'comrade'... :)
