ubuntu-phone team mailing list archive

[Andrea Bernabei <andrea.bernabei@xxxxxxxxxxxxx>]

On Tue, Sep 8, 2015 at 3:33 PM, Jim Hodapp <jim.hodapp@xxxxxxxxxxxxx> wrote:

>
>
> On Tue, Sep 8, 2015 at 10:26 AM, Andrea Bernabei <
> andrea.bernabei@xxxxxxxxxxxxx> wrote:
>
>>
>> On Tue, Sep 8, 2015 at 3:17 PM, Sergio Schvezov <
>> sergio.schvezov@xxxxxxxxxxxxx> wrote:
>>
>>> On Tue, Sep 8, 2015 at 9:31 AM, Alan Pope <alan.pope@xxxxxxxxxxxxx>
>>> wrote:
>>>
>>>> Hi Jim,
>>>>
>>>> On 8 September 2015 at 13:24, Jim Hodapp <jim.hodapp@xxxxxxxxxxxxx>
>>>> wrote:
>>>> > Or couldn't we just deprioritize apport as a process so that it can't
>>>> use up
>>>> > all of the CPU and truly make it a background task. Is there any
>>>> reason why
>>>> > apport would need normal priority while running?
>>>> >
>>>>
>>>> The result could be worse.
>>>>
>>>> If for example Unity8/Mir crashes, then while apport does its business
>>>> the shell isn't available (obviously, as it's just crashed) and
>>>> doesn't restart until after apport is done. This likely results in the
>>>> user seeing longer periods of "lock up" and will more likely reboot
>>>> the device (the only remedial measure they can take) almost certainly
>>>> resulting in an unusable crash dump, leading to us having no way to
>>>> determine the reason for the initial crash.
>>>>
>>>>
>>>
>> I think we should at the very least warn the user that the phone is
>> uploading crash reports or generating core dumps, so that he at least knows
>> we're slowing down the system on purpose.
>>
>
> I completely disagree. This is a technical detail that I believe should be
> hidden from the user. Your average user will have no clue what a crash
> report is. I would say that if we can't actually report a crash in the
> background without taking up all of the spare CPU cycles, then this process
> is broken. Perhaps apport just isn't suited for mobile yet and needs to be
> fixed so that it doesn't peg the CPU and to popey's feedback, doesn't block
> the shell from starting again until after apport has finished. That would
> be the ideal user interaction - crash reports just happen in the background
> and the user can't tell performance-wise that it's even occurring.
>
>
I agree 100%.
Having everything working in background without locking the device up would
be ideal. That's what I meant with "at the very least", as in, if we really
have to lock the device, we should tell the user that it's intentional and
we know what we're doing (and ask for some patience). We have to give
feedback, *if* we really really have to lock his phone (which we shouldn't,
of course).

It doesn't have to be a technical message, as you correctly pointed out.
But having the user look at the device and think "wtf is going on" is bad
UX, imho :) Locking his phone for our debugging pleasure is still bad UX,
but it's a bit better if the user at least gets some kind of feedback on
what's going on.

Andrea

Jim
>
>
>
>>
>> I would still think, though, that it makes more sense to get a few
>> corrupted crash dumps than to lock every phone so often just because things
>> fall apart.
>>
>>
>>> I'm going to chime in my usual request of asking if apport could be run
>>> only when plugged in to a power source :-) I currently have it disabled now
>>> since it is a pain when on the go where I ended up manually power cycling
>>> because it was faster and "I needed to make that call".
>>>
>>> --
>>> Mailing list: https://launchpad.net/~ubuntu-phone
>>> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~ubuntu-phone
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> --
>> Mailing list: https://launchpad.net/~ubuntu-phone
>> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~ubuntu-phone
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>