Quick update about crash reporting and some open issues

[Markus Mohrhard]

Hey,

On Mon, Jun 27, 2016 at 11:28 AM, Michael Stahl <mstahl at redhat.com> 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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20160628/8d9d0fc2/attachment.html>