intrigeri:
>> 1. The menu launcher is called Tails Upgrader.
>> While doing for initial brainstorming on the documentation I realize
>> that we will still have to document both processes: full upgrade and
>> incremental upgrade. They are very different kind of beasts, so the
>> differences between the two need to be explain and we should use
>> different terminology. We can try to stick to "full upgrade" and
>> "incremental upgrade" for the time being. But then the menu launcher
>> should be rename "Tails Incremental Upgrader" or something like that.
>> That's not a blocker from a technical point of view but it might prevent
>> writing doc with a coherent terminology.
>
> Done in feature/incremental-upgrades-integration (3d9eae7).
I bet you mean d54025d. Looks good.
>> 2. No feedback while looking for upgrade.
>> When the menu launcher is first started it takes several seconds before
>> having any visual feedback. This can be really confusing. How hard would
>> it be to display a spinner or something? That looks pretty important to me.
>
> I have no idea how to plug with GNOME's "application is starting"
> mechanism, but I can have a look and evaluate how painful it is.
> Please file a ticket assigned to me, with category = "Incremental
> upgrades". Unsure if this will make it as part of phase three yet.
Then, see:
https://labs.riseup.net/code/issues/6500
>> 3. The "click link" in the dialog messages are unclear.
>> I know we already talked about that, so feel free to remind me of the
>> technical limitations here but I thought we agreed on displaying the
>> full path of the link so people can type it in.
>
> FTR, we're talking of strings like:
>
> copy <a href='%{details_url}s'>this link</a> and open it in the
> browser to learn more.
>
> The technical limitation is that the user under which the upgrade
> frontend runs has no rights to instruct the browser (run by `amnesia')
> to do anything (and no, I don't want to set up a wrapper that allows
> the former to run stuff with sudo as the `amnesia' user).
>
> I have implemented exactly what (I understood from what) we have
> decided together. Is your current proposal:
>
> copy <a href='%{details_url}s'>%{details_url}s</a> and open it in
> the browser to learn more.
>
> ... or anything else? I'm happy to change this, once I know why
> and how.
That's it. In which commit is that? I can't find it...
>> 4. The buttons labels should be more explicit than "Yes" and "No".
>> Every time we have buttons in a dialog, we should try to make their
>> label as explicit as possible. For example, in the first dialog it could
>> be "Cancel" and "Upgrade", or "Cancel" and "Try again" on network
>> errors, or "Restart now" and "Restart later" once the upgrade
>> is over.
>
> Agreed. Seems easy to implement with zenity's --ok-label
> and --cancel-label options. Would you please file a ticket assigned to
> me, category = "Incremental upgrades", parent ticket = #6014?
Here you go:
https://labs.riseup.net/code/issues/6501
>> 5. Give an ETA while downloading.
>> It is good to have a progress bar while downloading the IUK, but it
>> would be much better to have an ETA.
>
> Most ETA's I see displayed are seriously wrong, so I'm not convinced
> it generally helps at all UX-wise. Is it really considered as a best
> practice these days to display an ETA along with progress bars for
> long operations?
Seems like GNOME recommends that:
https://developer.gnome.org/hig-book/3.0/windows-progress.html.en
https://developer.gnome.org/hig-book/3.0/controls-progress-bars.html.en
« - The progress bar text should provide an idea of how much work has
been completed. It is better to provide specific information rather
than a unit less percentage. For example, "13 of 19 images rotated"
or "12.1 of 30 MB downloaded" rather than "13% complete".
- If possible, an estimate of the time left until the operation is
complete should also be included in the progress bar text. Indicate
that the "time left" is an estimate using the word "about". »
>> How hard would that be?
>
> I think that having "an ETA" displayed while downloading is easy).
> The harder part is making it accurate enough to be marginaly useful.
> There might be good algorithms available to do that, but the software
> I use apparently don't use these :p
Don't kill yourself over that. As an alternative, what about displaying
the progress of the size of download ("Downloading upgrade: XX of
XXXMB") and a clock saying "Elapsed time: X:XX"?
>> But that's not a blocker for the initial release, I'd say.
>
> Sure. This could still be worth a low-priority ticket (not assigned to
> me, and not part of phase three this time). It might even be tagged
> "Easy", given our current definition.
Yeap:
https://labs.riseup.net/code/issues/6502
>> 6. Give an explicit title to each dialog.
>> I don't have all the precise examples at hand but the title of the
>> dialog should be more explicit. For example, instead of "Error", say
>> "Error while downloading the upgrade" or something like that.
>
> Seems totally doable as part of phase three. Please file a sub-task of
> #6014.
https://labs.riseup.net/code/issues/6503
>> 8. Hide the details of the error by default.
>> The technical details of the error will be of little use for most user.
>
> At least for a while, I think that any such error should be reported
> as a bug, so in the current state of things I beg to disagree with
> this statement.
>
>> It is mainly displayed to be copy & pasted for debugging purpose. So we
>> should hide it by default and have a expandable area and a "Show
>> technical details" button or similar.
>
> I agree it will be nicer this way once this code is tested more
> broadly, that is, after it is enabled by default, and most bugs are
> fixed. Once such errors will be more likely to be caused by issues on
> the user's side (e.g. network problems) than by bugs in our software,
> I'll like your proposal very much. IMHO this is worth a normal
> priority ticket, in the "Incremental upgrades" category, but not as
> part of phase three. Could possibly be assigned to me, but I'm not
> asking for it.
Make sense. Then:
https://labs.riseup.net/code/issues/6505
>> 9. Display a summary of the documentation page in error dialogs.
>> As a follow-up on comment #3 and #6, a summary of the documentation,
>> that would allow most users to understand what happened and what to do
>> directly from the dialog. The summary would also make it clear when it
>> is required to really check the documentation for more info.
>
> I'm unsure how it can possibly work in practice, but I'm curious and
> willing to give it a try. Could you please provide an example of what
> you would like for #9, so that we can evaluate something
> more concrete?
>
> Also, assuming we agree this is the way to go, will you provide these
> summaries as part of writing the doc, or should I schedule time for
> this after the doc is written?
I'll do that as part of the documentation work. I'll have to write new
pages, review all the error pages and probably propose changes on the
error messages themselves.
>> I think a combination of comment #3, #8, and #9 are a blocker.
>
> I don't really see what #8 has to do in there, which probably means
> I have misunderstood something you wrote (or didn't). You think this
> combination is a blocker, so this must be important. I want to avoid
> reacting (possibly defensively ;) on what would be guesses from my
> part => please elaborate.
I put #8 together because the three of them will help having more
informative and less confusing error messages. Hide providing more
useful information with #9 and hiding confusing information with #8 will
make better error messages overall. But since I agree with your argument
on #8, let's focus on #9 for the moment. And that's on my plate.
>> 10. Mention lack of memory as a possible cause of error.
>> In the documentation "This is probably caused by a network problem.
>> Restart Tails." doesn't seems really logic at first sight.
>
>> It should mention to check the network connectivity, and also that
>> a lack of memory could be the cause of the error, and that's when
>> restarting Tails makes sense (even though maybe not only).
>
> I'll assume you are talking of download errors here.
>
> First, well, *you* are supposed to write this doc, so I find it
> strange to read my crapy draft reviewed (I'm honored that it looked
> like something worth commenting on, though ;)
>
> I only quickly drafted something so that you have an idea what you
> should talk about, in the hope it might be helpful, but I'm certainly
> not considering it's a done thing. Feel free to improve, rephrase,
> rewrite, and/or delete anything in doc/upgrade/error/* :)
>
> It's way easier to explain how to restart Tails, that to document how
> to restart the network only and wait for it to be ready. This is why
> I wrote it this way.
>
> In case there was a misunderstanding, or perhaps a failed attempt at
> second-guessing what I didn't write: this advice has nothing to do
> with memory, as least this was not what I meant when writing it.
>
> Does it solve your concern regarding this phrasing?
Ok, understood. And yes, this is supposed to be my work. I'll work on
that this week hopefully.
> Slightly OT, but still: the current code checks that there's enough
> available memory before doing anything, but sure, if the user starts
> hacking huge pictures in Gimp while the download is in progress, it
> may fail. IMHO this is a UI or doc issues: we should probably tell the
> user right away, when proposing them to perform an incremental
> upgrade, that they should simply wait, and avoid starting
> applications: doing so might have the download fail (or leave their
> Tails system in a broken state, if this happens while the upgrade is
> applied). Thoughts, phrasing proposals?
Well, noted. Will do that while writing the doc.
>> 11. Do not disable the networking without warning.
>> At the end of the process the network is disabled: we should warn the
>> user about that as this might be unexpected and problematic.
>
> It took me a few minutes, but I now understand why I didn't think of
> this at all, and why this whole topic looks very strange to me.
>
> I think I can explain. On the one hand, the current state of the UX
> suggests that one may freely use Tails during this process, with no
> risks implied; the timing of the "we're now going to shutdown the
> network" warning shows up clearly suggests this. On the other hand,
> the current code (and its author, and its design) doesn't take this
> requirement into account. Well.
>
> 1. I'd be pissed off to see this requirement explicitly added *now*.
> I'm very sorry that the current UI has been suggesting, for more
> than a year, that I was already, and implicitly, taking this
> requirement into account.
I think it's ok to require the user to stop her activity while doing the
upgrade.
> 2. I think we really have to make this all more consistent, starting
> with avoiding making promises we can't hold (well, these promises
> are not explicit, but the current UI suggests it, which is enough
> to be a problem IMHO). See below.
>
>> So either
>> we warn them at some point in the process that this will happen at the
>> end, for example in the first dialog before choosing to do the upgrade,
>> either we add another confirmation dialog between the download and the
>> upgrade. I prefer the second one but it implies more code.
>
>> I think this is important but not a blocker.
>
> The first one could be done right now, as part of phase three.
> It's just a sentence to write and add, feel free to file a child
> ticket of #6014, assigned to me. This could go with a general warning
> against running apps during the upgrade process, and generally solve
> the mismatch between the code and what the UI suggests.
>
> The second one encourages people to do things while the upgrade is
> downloaded and applied, which I'd rather not to. If one wants to go
> this way, IMHO one would at least have to check available memory
> again, before displaying this confirmation dialog, and think seriously
> of the consequences of trying to support this usecase.
Ok, so let's go for the first option then:
https://labs.riseup.net/code/issues/6506
>> 12. Explain you need to restart to apply the upgrade.
>> I don't remember the phrasing of the last dialog,
>
> FTR (and to help others participate in this discussion), it is:
>
> "<b>The system was successfully upgraded.</b>\n\n".
> "The Tails partition on the USB stick is not write-protected ".
> "anymore for this working session.\n".
> "This is not safe, and you should restart Tails <b>as soon as ".
> "possible</b>.\n\n".
> "Restart the computer <i>now</i>?"
>
>> but I think it says
>> that you need to restart to get the network back and for security
>> reasons but it should be made more explicit that the upgrade is not
>> running yet. For example, the About Tails page still displays the old
>> version and that's expected.
>
>> So, the sentence "The system was successfully upgraded" could maybe be
>> replaced by "The Tails device was upgraded, restart to be on the new
>> version" or something like this.
>
> My feelings don't fully agree with thist: IMHO the security issue
> seems enough of a reason to reboot, and I'm not sure if adding more
> reasons will help in any way.
>
> ... but I trust you more than myself to make excellent decisions on
> this kind of things, so I won't block on it. Please propose a phrasing
> you find better, and I'm happy to take it.
>
> I just did that to start with, but it clearly doesn't address your
> concern:
>
> - "<b>The system was successfully upgraded.</b>\n\n".
> + "<b>The Tails device was successfully upgraded.</b>\n\n".
>
>> Conclusion: most of that is actually editing work that I should really
>> start working on, probably in parallel with the user documentation.
>
> Yep.
Agreed as well.
>> Regarding deadlines: will we be able to ship such fixes in Tails 0.22.1?
>
> IMHO, everything I've agreed to do above will be ready in time for
> 0.22.1, yes. I don't think coding tasks will be a major blocker.
> My bet is that it'll mainly depend on how much feedback we get this
> time, on other issues discovered, on user doc, on how fast things are
> discussed / tested / decided, and on reviewers' availability.
>
>> What do you mean exactly when you say "enable it by default for all
>> Tails users"? Are you talking about Tails 0.22.1 → Tails 0.23
>
> I would very much like to see this happen: enabled by default in
> 0.22.1, so users will be proposed to do it when 0.23 is out.
>
> Technically, switching to a entirely new security upgrade warning
> system (feature/incremental-upgrades-integration) does not meet our
> point-release criteria. I've suggested we do it nonetheless when
> posting the 0.22.1 release schedule a few days ago, and I've seen no
> objection raised yet.
Fine with me.
>> because I can't seen any point update in our calendar until Tails
>> 1.1. Rock'n roll!
>
> I'm starting to think that we should not prevent ourselves from
> providing incremental upgrades for major releases as well. I've not
> dared updating the design doc in this direction yet. I propose we try
> this for every release until 1.0, and see how it goes in practice.
>
> (Presumably, the 1.0..1.1 diff will be that huge that it's useless to
> publish an IUK for it.)
That's a good plan. You already told me that the IUK mechanism could
pill-up a bunch of upgrades. But we don't really know how many. Still we
can try to have an IUK for each release until Tails 1.1 which is a pile
of 3 IUK (0.22.1, 0.23, 1.0) and see how things go.
> Also, note that there is some lag involved by all this: if we ship
> some crappy code in version N, and discover issues only six weeks
> later when people use it to upgrade to N+1, then it's too late to fix
> it in N+1, and it can only be be fixed in N+2. So, we really have to
> find bugs in release candidates.
:(
