Re: Quick update about crash reporting and some open issues
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
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
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
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
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
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