Autor: intrigeri Data: A: The Tails public development discussion list Assumpte: Re: [Tails-dev] Proposal: new Tails version scheme and RM
optimizations
At first glance I like this one. I don't feel like re-reading the
thread we had last year about the same topic to refresh my memories of
what trade-offs we did when we picked our current versioning scheme,
and why. If both you and sajolida like the new proposed one, I'm sure
it's good and I trust you :)
> 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.
OK.
> 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.
I agree with manually testing only the affected areas by comparing
ISOs. In practice, I doubt we can do this in a way that's both enough
of a time-saver, and doesn't let us overlook important changes, before
we have reproducible builds. So until we do have reproducible builds,
I would like us to keep doing the full manual test suite even for
emergency releases, if we can.
> 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.
Agreed. Anyone who wants to raise the bar here should be prepared to
throw some work hours into it, on a regular (and unplanned) basis,
in order to make it happen.
> Proposal 3: treat X.esr as just another emergency 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.
That sounds like a possibly important problem to me, but that's
perhaps because I'm not quite sure what exact bug fixes would qualify
for inclusion in these releases. I've seen your proposed definition
above, but it would help me understand better if you gave examples of,
say, 3 bug fixes we have included in previous point releases, that
would satisfy the new criterion, and 3 bug fixes we have included in
previous point releases, that would *not* satisfy it. Please? :)
> 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?
One problem with this is that we won't be able to merge the live
website branch into our other release branches (e.g. 'security' and
'testing') anymore, since its history will include changes that are
not suitable for those branches. This implies that any change done on
the live website branch since the last release, such as translation
updates, won't be included in the copy of the website we ship in the
ISO. This sounds like a blocker, no?
