ubuntu-phone team mailing list archive

[Jim Hodapp <jim.hodapp@xxxxxxxxxxxxx>]

Does anyone know if there's a bug filed for this issue and against the
appropriate packages/projects? It'd be nice to know if the right person is
looking into fixing this apport issue.

Jim

On Tue, Sep 8, 2015 at 11:06 AM, Andrea Bernabei <
andrea.bernabei@xxxxxxxxxxxxx> wrote:

>
>
> 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
>>>
>>>
>>
>