Hi,
(A meta note I'd like to raise first, so that everyone can understand
better my position in this discussion: more than a year ago, this
stuff was ready to be tested, was tested, and we've decided what was
blocking, and what was not, before we deploy incremental upgrades in
production; all this was done. I'm willing to get feedback, and
I already promised to do various improvements based on it, but I may
be or seem a bit defensive with new blocking requirements added *now*,
and I hope you'll understand that.)
Alan wrote (14 Dec 2013 13:01:38 GMT) :
>> > 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.
> In the .desktop, you had
> StartupNotify=false
> Just set this to true and you're done.
Thanks, I'll try this (#6495).
Note that the .desktop starts a shell wrapper that itself starts the
actual Perl app after (quicly) doing some checks. What takes time is
the Perl app startup. I'm not sure if StartupNotify=true will be
enough to display a spinner during the Perl application startup.
We'll see.
In any case, I don't see why this is so important, but I see why you
folks don't share this feeling, as you're missing some background info
that didn't make it out of my mind to a public document yet: this
launcher was only added to make testers' life easier, until
incremental upgrades are enabled by default. Then, my plan is to
remove it.
Fair enough?
>> > 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).
>>
> Why? Why not a wrapper to launch this specific link as amnesia?
I'm sure it's easy to implement and have "working", but I don't feel
like thinking through the security implications of allowing some user
open any URL in the web browser without breaking the current privilege
separation in some way. If someone feels like it (which likely
requires sanitizing the input URL somehow), they're welcome. A careful
analysis might prove that it's easy to implement, or not.
>> > 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.
>>
> I support sajolida's remark. The debugging info looks scary.
Well... given the explanation I've given, this position does not make
any sense to me, and I trust you're not gratuitously insisting without
taking my words into account, so I'll assume we're not understanding
each other somehow. Let's try to clarify and improve this :)
My assumptions are:
- currently, such an error is more likely to be caused by a software
bug than by issues on the user's side
- so, such an error shall be reported as a bug
- such a bug report must contain the debugging information
So, most users who see an error will need the debugging information.
Until this point, do we agree?
Add to this that we'll need to document any additional step that is
required to access it, and users will need to read and follow
these instructions.
Then, in the *current* state of things, hiding this debugging info by
default only seems to make things more complicated both for the user
and for us, and I don't see what would be the advantage.
What my reasoning is missing is the "it's scary" part. Is it better
not to scare the user, if it makes it more complicated for them to do
anything useful with the error? I'm unsure, but I guess I could be
convinced by any side of the argument :)
Anyway, once we enable this feature by default, as I already said,
I agree hiding this info by default is better. So, contrary to what
I previously wrote, I'm fine writing the needed code for 0.23,
assuming 0.22.1 has this feature enabled by default.
Fair enough? I'll create a ticket if sajolida and/or Alan agree.
>> 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?
> Stupid question: couldn't a task tell the kernel to "reserve" the memory
> it will need?
... and to free it on demand only to give it to a process and child
processes? I'd bet that cgroups allow to do this. Looks fun, but IMHO
it would be pure over-engineering, and the benefit doesn't seem worth
the code and design complication (=> bugs and maintenance).
> I think it's fine to tell the user they shouldn't do something else
> during the upgrade and add this as a requirement.
OK, thank you.
> On the long run, perhaps there could even be an "upgrade" mode,
> selected in the greeter, that would start an upgrade-only session?
> If I remember well, you can have a GTK application be "system modal",
> meaning it is the only usable application.
Surely worth thinking about it and submitting this idea to UX experts.
Note that the user still should be able to configure the network (and
Tor bridges if needed, using Unsafe Browser if needed), so it could
very well be non-trivial.
At some point, it was even suggested to integrate the upgrade process
into the greeter.
>>> 12. Explain you need to restart to apply the upgrade.
>>> I don't remember the phrasing of the last dialog,
> Why not to force the user to restart, like "You should now restart
> Tails, click here to restart"?
I don't get how this proposal differs from what we already have.
Could you please elaborate?
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
