Re: Quick update about crash reporting and some open issues

[Alexander Thurgood]

Le 28/06/2016 à 11:55, Markus Mohrhard a écrit :
> Hey,
> 
> 
> 
> No, it is not supported on OSX and at least from my side there are no
> plans to fix that any time soon.
> 

OK, thanks, just wanted to check :-)

Alex



___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Quick update about crash reporting and some open issues

[Markus Mohrhard]

Hey,

On Tue, Jun 28, 2016 at 11:42 AM, Alexander Thurgood <
alex.thurg...@gmail.com> wrote:

> Le 27/06/2016 à 06:00, Markus Mohrhard a écrit :
>
> Hi Markus,
>
> > so here is a quick update about the crash reporting and a few questions
> > about open issues. It would be good if people who are going to use the
> > service to have a quick look through the items and tell me their opinion
> > about the open items.
> >
>
>
> Does this also work on OSX and if so, is it activated automatically, or
> is there an option to tick in th UI to do so ?
>
>

No, it is not supported on OSX and at least from my side there are no plans
to fix that any time soon.

Markus
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Quick update about crash reporting and some open issues

[Alexander Thurgood]

Le 27/06/2016 à 06:00, Markus Mohrhard a écrit :

Hi Markus,

> so here is a quick update about the crash reporting and a few questions
> about open issues. It would be good if people who are going to use the
> service to have a quick look through the items and tell me their opinion
> about the open items.
> 


Does this also work on OSX and if so, is it activated automatically, or
is there an option to tick in th UI to do so ?


Alex


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Quick update about crash reporting and some open issues

[Markus Mohrhard]

Hey,

On Mon, Jun 27, 2016 at 11:28 AM, Michael Stahl  wrote:

> On 27.06.2016 06:00, Markus Mohrhard wrote:
> > Do we want to notify the crash reporter if there was a commit
> > referencing a crash report? Similar to how bugzilla is automatically
> > updated we could do something like this for the crash reporter. That
> > might help with keeping track if there was already a fix for a crash and
> > we are only seeing more reports because it is not yet in a released
> version.
> > What would be the format of the reference?
>
> so if we do the below anyway...
>
> > For the bugzilla to crash report direction we had planned to handle it
> > with a bot monitoring the crash report field in bugzilla and update the
> > crash reporter website.
>
> ... can we do it such that the crash-reporter gets updated when the
> bugzilla bug changes state, so you could then see in the crash-reporter
> ui if it's already fixed?
>

Yes, we can. Actually the plan is to add some javascript at some point that
will mark the bug number as strike through if the bug has been closed.

But that does not solve the problem that we have many fixes for crashes
reported that have no corresponding bug report. E.g caolan, miklos and I
already fixed bugs by referencing a crash report and not a bug report
because there was none.


> > How do we want to handle stuff that requires user interaction? Examples
> > are adding new versions, adding references to bug reports and possibly
> > export of crash reports to bugzilla.
>
> how about a button "create bugzilla bug", that is only displayed if
> there isn't one already, and links to the create-bug page with the crash
> metadata pre-filled.  then we can use bugzilla to add reproduction
> steps, uninformed speculation, or whatever.
>

Ok, might be a solution.


>
> > There are maybe more tasks in the future that will require some actions
> > that cause DB changes by users. Duplicating the login system from
> > bugzilla seems like a horrible concept and will just cause us to have
> > even more logins that nobody remembers.
>
> yes, better to have any interaction go via bugzilla if that is possible.
>
> > How do we want to handle old crash reports? We can't keep the reports
> > forever and will most likely delete them as soon as a branch becomes
> > EOL. The question is whether there is value in exporting them to some
> > format (most likely json) and archive them or just forget completely
> > about old reports.
>
> what's the problem with keeping them?  surely there should be enough
> space on the server to store them?
>


They are stored in the database and will let the db grow quite huge. Keep
in mind that even right now with just a few hundred users we get about 20
to 30 crashes a day. And each entry is quite huge right now. The problem is
in the end not the disk size and instead having way too many entries in the
db. There are quite a few maintenance tasks that go through all reports and
try to find some stuff.

Regards,
Markus


>
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Quick update about crash reporting and some open issues

[Michael Stahl]

On 27.06.2016 06:00, Markus Mohrhard wrote:
> Do we want to notify the crash reporter if there was a commit
> referencing a crash report? Similar to how bugzilla is automatically
> updated we could do something like this for the crash reporter. That
> might help with keeping track if there was already a fix for a crash and
> we are only seeing more reports because it is not yet in a released version.
> What would be the format of the reference?

so if we do the below anyway...

> For the bugzilla to crash report direction we had planned to handle it
> with a bot monitoring the crash report field in bugzilla and update the
> crash reporter website.

... can we do it such that the crash-reporter gets updated when the
bugzilla bug changes state, so you could then see in the crash-reporter
ui if it's already fixed?

> How do we want to handle stuff that requires user interaction? Examples
> are adding new versions, adding references to bug reports and possibly
> export of crash reports to bugzilla.

how about a button "create bugzilla bug", that is only displayed if
there isn't one already, and links to the create-bug page with the crash
metadata pre-filled.  then we can use bugzilla to add reproduction
steps, uninformed speculation, or whatever.

> There are maybe more tasks in the future that will require some actions
> that cause DB changes by users. Duplicating the login system from
> bugzilla seems like a horrible concept and will just cause us to have
> even more logins that nobody remembers.

yes, better to have any interaction go via bugzilla if that is possible.

> How do we want to handle old crash reports? We can't keep the reports
> forever and will most likely delete them as soon as a branch becomes
> EOL. The question is whether there is value in exporting them to some
> format (most likely json) and archive them or just forget completely
> about old reports.

what's the problem with keeping them?  surely there should be enough
space on the server to store them?


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Quick update about crash reporting and some open issues

[Markus Mohrhard]

Hey,

so here is a quick update about the crash reporting and a few questions
about open issues. It would be good if people who are going to use the
service to have a quick look through the items and tell me their opinion
about the open items.

So starting with the update:

I just fixed the signature generation and started the work on the 64bit
Windows system library support. All reports have been reprocessed and the
signature no longer contains an offset. This finally merges x64 and x86
reports under the the same signature.
The summary view in the signature page has a basic implementation and just
needs some extending to other things that are useful. A few that are on my
list are OpenGL device, OpenGL vendor, better windows version summaries and
generic metadata support.

What still needs to be implemented and is quite high on the issue list is
to add a reference from the crash details page back to bugzilla.



Then a few open questions about process around the crash reporting:


Do we want some way for the ESC to get a list of the 10 most frequent
crashes of the last week or something like that?

Do we want to notify the crash reporter if there was a commit referencing a
crash report? Similar to how bugzilla is automatically updated we could do
something like this for the crash reporter. That might help with keeping
track if there was already a fix for a crash and we are only seeing more
reports because it is not yet in a released version.
What would be the format of the reference?

How do we want to handle stuff that requires user interaction? Examples are
adding new versions, adding references to bug reports and possibly export
of crash reports to bugzilla.
For the bugzilla to crash report direction we had planned to handle it with
a bot monitoring the crash report field in bugzilla and update the crash
reporter website.
There are maybe more tasks in the future that will require some actions
that cause DB changes by users. Duplicating the login system from bugzilla
seems like a horrible concept and will just cause us to have even more
logins that nobody remembers.

How do we want to handle old crash reports? We can't keep the reports
forever and will most likely delete them as soon as a branch becomes EOL.
The question is whether there is value in exporting them to some format
(most likely json) and archive them or just forget completely about old
reports.

There is an exploitability feature in breakpad that can do an automatic
assessment but I have no idea how good the reports are. I know that it is
enabled but only visible in the Mozilla version. Do we want something like
that and if we want it do we want to hide it?


I'll have most likely a few more items that will come up after the release.
I hope that the current service is already useful. If there is anything
else missing please let me know.

Regards,
Markus
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice