GitLab

We don't ship this add-on anymore.

For details, see this email thread:

  [Tails-dev] [Proposal] Redmine workflow simplification: drop "Fix committed" status
  https://lists.autistici.org/message/20191024.090149.76eba7c8.en.html

I guess this instance escaped my grep's because it's split between 2 lines.

- We've had 2 places to document manual upgrades since 2016,
  /doc/upgrade then pointing to /upgrade for the actual meat. Having a
  single place prevents people to jump around needlessly.

- Tails Upgrader has been pointing to /doc/upgrade since 2014 and these
  old versions of Tails will continue to point to it.

- We could as well redirect /doc/upgrade/#manual to /upgrade but
  /doc/upgrade has the advantage of putting both techniques in
  perspective.

- /doc/upgrade (formerly /doc/first_steps/upgrade) is very well indexed
  by search engines while we prevented /upgrade to be indexed by
  'noindex'.

To get 6% more compression on average.

Doing mat2 before trimage leads to slightly bigger files than trimage
only but to better compression than doing trimage before mat2.

It was documenting the use of "startup option" for boot options
while the #boot entry is documenting the use of "boot option" instead.

Currently translated at 17.7% (11 of 62 strings)

Translation: Tails/wiki/src/news/version_3.14.1.*.po
Translate-URL: http://translate.tails.boum.org/projects/tails/wikisrcnewsversion_3141po/pt/

Currently translated at 39.0% (16 of 41 strings)

Translation: Tails/wiki/src/news/version_3.11.*.po
Translate-URL: http://translate.tails.boum.org/projects/tails/wikisrcnewsversion_311po/it/

It's an official Twitter app that works with the same login, so doesn't
affect the security of our account.

"Changes" has a probably stronger meaning as the first word in the title
when put in parallel with "[New] features" and "[Fixed] problems".
Upgrades are one type of changes.

This "Change" section doesn't bring much and look especially weird in
short release notes.

Make release notes writing instructions consistent with the implicit expectations of our release process doc (Closes: #16586)

Our release process assumes that tech writers will push the release notes
directly to the $WEBSITE_RELEASE_BRANCH (web/release-${TAG:?}) branch. But the
tech writers doc told them to do something else. Let's resolve this conflict.

It's probably less dangerous and confusing to show upgrade first to
people who want to install than to show install first to people who want
to upgrade as they could erase their persistence is their follow the
installation instructions

- Separate them more
- Clarify the impact on persistent storage
- Put on the same level as download only in release notes