Rationale:

 - Right now:

   - These pages' Markdown will be rendered when browsing our
     repository in the GitLab web interface

   - The .md extension is more common nowadays: GitHub, GitLab, and various
     other major players have settled on it. Let's get used to it.

 - If we decide to migrate our blueprints to GitLab (#18079),
   this will be a necessary first step.

incremental_upgrades.md

+[[!tag archived]]
+
+[[!toc levels=4]]
+
+See also:
+
+ * the [[corresponding design document|contribute/design/incremental_upgrades]];
+ * the tickets with the _C: Upgrader_ label on [[!tails_gitlab "" desc="GitLab"]].
+
+# Random ideas for future improvements
+
+These are not worth creating tickets yet, as it's not even clear these
+changes are useful enough to put time in it.
+
+### Packaging could be more self-contained
+
+Move `/etc/sudoers.d/zzz_upgrade` and IUK-related user creation from
+the Tails main Git repository to the `tails-iuk` Debian package, so
+that it's more self-contained and easier to test.
+
+### Button for aborting upgrade cleanly
+
+### Compute and display ETA
+
+### Multi-step incremental upgrade
+
+E.g. 0.11 boots after 0.11.1 and 0.11.2 are out. Tails fetches
+https://tails.boum.org/upgrade/v1/Tails/0.11/i386/stable/upgrades.yml,
+that shall contain an incremental upgrade path with two target files:
+the 0.11 to 0.11.1 IUK, and the 0.11.1 to 0.11.2 IUK. The upgrader
+would download these two files and install the two IUKs in the
+correct order.
+
+### sharing upgrade material
+
+Once the incremental upgrade has been applied, I may be proposed to
+save a copy of the target files to a location of my choosing.
+
+### allow one to download target files in the clear
+
+The downloader program could provide an opt-in way to have the
+download happen in the clear, that is without going through the Tor
+network. It looks doable given it's a separate process: we may run it
+as a dedicated user, and reuse the `clearnet` infrastructure
+implemented for the Unsafe Browser.
+
+[[!tails_ticket 7878]]
+
+### "Retry with new circuit" button
+
+Circuit throughput varies wildly, and since this is a large download,
+it'll quickly wear out users' patience if a bad circuit is picked.
+Or maybe this can happen behind the scenes, e.g.:  Automatically
+switch circuit every X minutes or Y% progress? That could even make
+fingerprinting the download on the Tor client <-> Entry Node side of
+the pipe a bit more difficult, for whatever that's worth.
+
+### Surviving key compromise
+
+* https://wiki.ubuntu.com/ImageBasedUpgrades/GPG