Document tricks for power users vs. bigger downloads for automatic upgrade
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.
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.
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 #14544 for a later point in time.
- 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 #14544 for a later point in time.
ACK. I had tentatively put this under #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 #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.
I just (re)discovered #15289. Reverse engineering how these 2 tickets relate to each other, it seems to me that the idea was:
- First, document the manual upgrade trick via #15288.
- 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 #15289: let's continue the discussion and UX design that started here already :)
- File base.svg added
I drafted (exciting) plans for this doc but I don't think I should work on this now and rather focus on #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 #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.