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". Alex _______________________________________________ List Name: Libreoffice-qa mailing list Mail address: [email protected] Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
