[Libreoffice-qa] organizing our "crasher" bugs ?

Alex Thurgood alex.thurgood at gmail.com
Thu May 28 23:55:23 PDT 2015

Le 29/05/2015 04:07, Joel Madero a écrit :

Hi Joel,

> What I think would be minimum (and can be done) is:
> Confirm each crash on 5.0;
> _Ensure_ that each has easy steps;

> For the most straight forward ones that have easy steps we can just mark
> them as critical + highest - signaling that they are easy to reproduce
> and everything is there for devs to tackle them.

I foresee a problem with recognizing Base crashers as important in the
above scenario (I haven't checked to see whether there are any in the list).

By their very nature, database crashers usually require more effort and
more steps to reproduce than say, a formatting crasher bug in Writer or
Calc, or a call to some function, due, among others, to the following :

- Java : as ever, often problematic to debug from within gdb/lldb for
the casual QAer - the internal JVM signal catcher often baulks without
any really useful information when using debug builds ;

- the variety of different db engines we support - we have two embedded
engine possibilites, plus all the external possible backends and
associated driver problems to factor in ;

- the Report Builder - more Java, but funnily enough, most of the
crashers in this seem to relate to changes in other areas of the code
(Writer, Calc, OUString, configuration files).

None of that could be considered "easy".


More information about the Libreoffice-qa mailing list