On Mon, 22 Jun 2015, Oliver Grawert wrote:
>Am Montag, den 22.06.2015, 20:21 +0200 schrieb Torsten Sachse:
>> On Mon, 22 Jun 2015, Steve Langasek wrote:
>> > The only part that should be running when not on wifi is the crash
>> > collection. We certainly *should* be running that when not on
>> > wifi; you don't get a second chance to run the kernel crash
>> > handler, and we want to know about crashes that only happen when
>> > not on wifi (including, possibly, crashes that happen /because/
>> > you're not on wifi).
>>
>> While that may be true, there has to be an option to switch off such
>> crash collection permanently or temporarily. This must not be
>> enforced on the user, which is the way it is right now, if I
>> understood all this correctly.
>
>there is a bug, bugs happen, people make mistakes ... you make it
>sound like this is intentional ...
I know that people make mistakes as I just made a stupid one myself. To
me, Steve's email sounded as if it was intentional due to the
highlighted "should" which I misunderstood as a "must". I know now that
I completely missed the point of the message.
Thank you for the link, I must have overlooked that one somehow. Sorry
for that. However, I can confirm that the option sticks after making the
system writable. Actually, after remounting / as ro again, the option
can no longer be switched on (consistent which what's decribed in the
above thread).
> I was responding to the suggestion that the behavior should somehow be
> dependent on whether the device is connected to wifi at the time of
> the crash. That's just wrong.
I completely agree. The data should either be collected or not at all,
irrespective of the current network connectivity.
> While the shell can't do anything with the crashed app until the crash
> handler has finished, that *shouldn't* mean that it prevents the shell
> from, e.g., switching apps. This is why people were asking about
> crash files for unity8. It's unexpected that a crashed app should
> take out the /whole/ UI, and if that happens that's a bug in unity8,
> not just a bug in the app that's crashing.
On Mon, 22 Jun 2015, Oliver Grawert wrote:
>Am Montag, den 22.06.2015, 20:21 +0200 schrieb Torsten Sachse:
>> On Mon, 22 Jun 2015, Steve Langasek wrote:
>> > The only part that should be running when not on wifi is the crash
>> > collection. We certainly *should* be running that when not on
>> > wifi; you don't get a second chance to run the kernel crash
>> > handler, and we want to know about crashes that only happen when
>> > not on wifi (including, possibly, crashes that happen /because/
>> > you're not on wifi).
>>
>> While that may be true, there has to be an option to switch off such
>> crash collection permanently or temporarily. This must not be
>> enforced on the user, which is the way it is right now, if I
>> understood all this correctly.
>
>there is a bug, bugs happen, people make mistakes ... you make it
>sound like this is intentional ...
I know that people make mistakes as I just made a stupid one myself. To
me, Steve's email sounded as if it was intentional due to the
highlighted "should" which I misunderstood as a "must". I know now that
I completely missed the point of the message.
On Mon, 22 Jun 2015, Steve Langasek wrote: /bugs.launchpad .net/ubuntu/ +source/ whoopsie- preferences/ +bug/1437633
> There is an option, and there is reportedly a bug in the handling of
> that option, as was already mentioned in this thread.
> https:/
Thank you for the link, I must have overlooked that one somehow. Sorry
for that. However, I can confirm that the option sticks after making the
system writable. Actually, after remounting / as ro again, the option
can no longer be switched on (consistent which what's decribed in the
above thread).
> I was responding to the suggestion that the behavior should somehow be
> dependent on whether the device is connected to wifi at the time of
> the crash. That's just wrong.
I completely agree. The data should either be collected or not at all,
irrespective of the current network connectivity.
> While the shell can't do anything with the crashed app until the crash
> handler has finished, that *shouldn't* mean that it prevents the shell
> from, e.g., switching apps. This is why people were asking about
> crash files for unity8. It's unexpected that a crashed app should
> take out the /whole/ UI, and if that happens that's a bug in unity8,
> not just a bug in the app that's crashing.
Thanks for all the information.
Cheers,
Torsten