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 < [email protected]> wrote: > > > On Tue, Sep 8, 2015 at 3:33 PM, Jim Hodapp <[email protected]> > wrote: > >> >> >> On Tue, Sep 8, 2015 at 10:26 AM, Andrea Bernabei < >> [email protected]> wrote: >> >>> >>> On Tue, Sep 8, 2015 at 3:17 PM, Sergio Schvezov < >>> [email protected]> wrote: >>> >>>> On Tue, Sep 8, 2015 at 9:31 AM, Alan Pope <[email protected]> >>>> wrote: >>>> >>>>> Hi Jim, >>>>> >>>>> On 8 September 2015 at 13:24, Jim Hodapp <[email protected]> >>>>> 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 : [email protected] >>>> Unsubscribe : https://launchpad.net/~ubuntu-phone >>>> More help : https://help.launchpad.net/ListHelp >>>> >>>> >>> >>> -- >>> Mailing list: https://launchpad.net/~ubuntu-phone >>> Post to : [email protected] >>> Unsubscribe : https://launchpad.net/~ubuntu-phone >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> >
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
