Feature #15288

Document tricks for power users vs. bigger downloads for automatic upgrade

Added by anonym 2018-02-05 16:17:55 . Updated 2020-04-06 18:01:32 .

Status:
Confirmed
Priority:
Normal
Assignee:
sajolida
Category:
Installation
Target version:
Tails_4.7
Start date:
2018-02-05
Due date:
% Done:

0%

Feature Branch:
feature/15281-single-squashfs-diff
Type of work:
User interface design
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

Doing a manual upgrade (not including IUKs) will make the IUKs you download for the next release smaller. Power users might want to know about this so they can optimize their bandwidth usage. And they (e.g. if they are an instructor) can tell users with such needs about it.

This is not part of the official deliverables for Sponsor 2 but we thought that it was an important task anyway.

Files

base.svg (44987 B) sajolida, 2020-01-06 14:17:24

Subtasks

Related issues

Related to Tails - Feature #12493: Have Tails Upgrader automatically point to manual upgrade if running from an old version Confirmed 2017-04-29
Related to Tails - Feature #15281: Stack one single SquashFS diff when upgrading Resolved 2016-04-13
Blocks Tails - Feature #15289: Make Tails Upgrader suggest a manual upgrade to decrease future IUK sizes Confirmed 2018-02-05
Blocked by Tails - Feature #16991: Cognitive walkthrough of automatic and manual upgrades Resolved
Blocks Tails - Feature #17247: Core work 2020Q1 → 2020Q2: Technical writing Confirmed

History

#1 Updated by anonym 2018-02-05 16:18:24

  • blocked by Feature #15281: Stack one single SquashFS diff when upgrading added

#2 Updated by anonym 2018-02-05 16:23:16

  • blocks Feature #15289: Make Tails Upgrader suggest a manual upgrade to decrease future IUK sizes added

#3 Updated by intrigeri 2018-02-06 16:53:38

  • Subject changed from Document tricks for power users vs 1BigIUK to Document tricks for power users vs. bigger downloads for automatic upgrade

#4 Updated by anonym 2019-01-15 13:04:17

  • Target version changed from 2018 to 2019

#5 Updated by sajolida 2019-07-31 19:34:25

  • Assignee changed from anonym to sajolida
  • Parent task set to Feature #15281

Let’s put it under Feature #15281 as one of the doc updates.

#6 Updated by sajolida 2019-11-21 18:26:21

  • Target version changed from 2019 to Tails_4.2

Endless upgrades will be in 4.2.

#7 Updated by intrigeri 2019-11-27 08:42:39

sajolida wrote:
> Endless upgrades will be in 4.2.

FWIW, the first time users may need this doc is when upgrading to 4.3. So it seems to me that if you don’t do this in time for 4.2, the only drawback is that these tricks won’t be documented in the offline version of the doc that’s included in 4.2.

#8 Updated by sajolida 2019-11-27 17:13:10

  • blocked by Feature #16991: Cognitive walkthrough of automatic and manual upgrades added

#9 Updated by sajolida 2019-11-27 17:18:21

Sure. I’m doing pretty good in terms of busyness and budget right now so the earlier the better :)

@intrigeri: The best place to display this information might actually be in the interface itself (in addition to the doc). Is it conceivable to display a string about this in Tails Upgrader when, let’s say, it detects that the base version on the USB stick is more than N versions old or the IUK is more than N MB or N % of a full image? With no pressure, it could be either for Sponsor 2 or stored in Feature #14544 for a later point in time.

#10 Updated by sajolida 2019-11-27 19:15:27

  • related to Feature #12493: Have Tails Upgrader automatically point to manual upgrade if running from an old version added

#11 Updated by intrigeri 2019-12-15 08:49:13

  • Type of work changed from End-user documentation to User interface design

> Is it conceivable to display a string about this in Tails Upgrader when, let’s say, it detects that the base version on the USB stick is more than N versions old or the IUK is more than N MB or N % of a full image?

Yes. More specifically:

  • more than N versions old: with a rough approximation, it’s doable, but requires more work than the other options (and gives less relevant/accurate feedback to the user IMO)
  • more than X MB: it’s the easiest to code initially; but we need to figure out what N should be, and possibly to update this value later
  • more than Y % of a full image: doable

So I propose we go with “more than X MB” for now, computing the hard-coded X value based on “Y % of a full image”.
And to compute this value, I propose we wait until we’ve built IUKs from 4.0 to 4.2 and from 4.0 to 4.3, so we have data about what size they are in practice.

But I guess the UX design can be done without knowing this value yet.

> With no pressure, it could be either for Sponsor 2 or stored in Feature #14544 for a later point in time.

ACK. I had tentatively put this under Feature #15281 under the assumption this would “only” require doc work. Given this requires UX design and new code, I doubt it’ll fit into the sponsor deadlines for Feature #15281. I won’t have time to implement this in 4.2 so no big hurry on your side to give me the UX design bits I need.

#12 Updated by sajolida 2019-12-18 11:12:45

Makes sense.

I’ll propose a design when working on the doc itself in time for 4.2.

#13 Updated by intrigeri 2019-12-24 12:35:09

Rationale: I would like Feature #15281 to track the subset of the “single SquashFS diff” work that has to go in 4.2 (and that will be ready for review very soon now).

#14 Updated by intrigeri 2019-12-24 12:35:35

  • related to Feature #15281: Stack one single SquashFS diff when upgrading added

#15 Updated by intrigeri 2019-12-24 12:36:03

  • Feature Branch set to feature/15281-single-squashfs-diff

#16 Updated by intrigeri 2019-12-25 10:36:21

I just (re)discovered Feature #15289. Reverse engineering how these 2 tickets relate to each other, it seems to me that the idea was:

  1. First, document the manual upgrade trick via Feature #15288.
  2. Second, design & code the Upgrader UI that will point to that new piece of doc when relevant.

This seems needlessly detailed to me and embeds assumptions that may or may not hold true once we dive into this. For example, it could be that the Upgrader UI can convey all the needed info itself, without having to point to a new dedicated doc page. We’ll see.
So for now, I’ll ignore Feature #15289: let’s continue the discussion and UX design that started here already :)

#17 Updated by sajolida 2020-01-06 12:35:30

  • File <del>missing: base.svg</del> added

I drafted (exciting) plans for this doc but I don’t think I should work on this now and rather focus on Feature #9814 in January.

See drawings in attachment :)

I’ll introduce the term “base version” to refer to the version that was originally installed. People can boost their base version with either a manual upgrade or by cloning.

@intrigeri: I was wondering how people could check which base version they have installed on their USB stick, for example if a trainer wants to know whether it’s worth upgrading someone by cloning. At first sight, it doesn’t seem obvious from the content of the system partition. I didn’t update to 4.1 because of Bug #17316 and I’ll have another look once I upgraded to 4.2 but I thought that you might have an idea already. Given the audience for this doc, a short command line would do I think.

#18 Updated by intrigeri 2020-01-06 12:58:42

> intrigeri: I was wondering how people could check which base version they have installed on their USB stick

This should do the trick:

grep '^TAILS_VERSION_ID=' \
/lib/live/mount/rootfs/filesystem.squashfs/etc/os-release

#19 Updated by sajolida 2020-01-06 14:16:35

  • File deleted (base.svg)

#20 Updated by sajolida 2020-01-06 14:17:27

#21 Updated by sajolida 2020-01-07 10:26:34

  • Target version changed from Tails_4.2 to Tails_4.3

#22 Updated by anonym 2020-02-11 15:25:33

  • Target version changed from Tails_4.3 to Tails_4.4

#23 Updated by CyrilBrulebois 2020-03-12 09:55:46

  • Target version changed from Tails_4.4 to Tails_4.5

#24 Updated by sajolida 2020-03-24 22:32:42

  • Description updated

#25 Updated by sajolida 2020-03-24 22:33:10

  • blocks Feature #17247: Core work 2020Q1 → 2020Q2: Technical writing added

#26 Updated by sajolida 2020-03-24 22:33:58

Adding to our core work view because it’s an important (but not required) tasks for Sponsor 2.

#27 Updated by sajolida 2020-04-06 18:01:32

  • Target version changed from Tails_4.5 to Tails_4.7