Regarding "classification" of bugs (critical, etc.) and bug fixing.
The core question is how to increase the throughput of bug fixing, i.e. increase the number of fixes? If one analyse bug reporting process & fixing, it is usually done as 1/ User report bug 2/ Tester try to reproduce it, then 2.1/ confirm or not 2.2/ sets a priority 3/ Some developper will fix it when has time and very othen if feels like it, instead of developping some new features (s)he likes. This is a very bad way to handle bug and discourage reporter, tester and possibly developper. Indeed, often bug are fixed weeks later, not months if ever and priority are very subjective. How to improve that? 1/ First by reducing time between bug reporting and fixing and only delaying fixing when it's too ressource consumming. Work on it as it is hot reported and user expect to verify the fix. 2/ By notifing bug reporter of current ressources (for instance, red flag lack ressouce so handles only critical bugs) How to improve the time between bug reporting and fixing? By cracking down the problem to its core root. Irrelevant of the bug seriousness, there are user familliar with bug reporting and some not. So the first role of the bug tester is to validate it and have a test scenario. When there is a test scenario, then 6 things are often short-circuited, but would accelerate the bug fixing process. 0/ When lacking time, well how frequent in its USE does the bug appear, i.e. is it rather of general use or rather specific to some expert user? 1/ Simplify the reproducable bug test case to its core form. For instance, if it's a spreadsheet. Are all columns usefull? No, delete the rest. Are all lines usefull? No, delete the rest. Is the formating relevant? No, remove it. Is it file format specific? Is it language specific? Etc. Snif the trail of the bug to find its root. 2/ Narrow down the process involved to generate the bug, in order to identify the precise component For example, In the process to reproduce the bug, are they steps one can omit, what about changing the order sequence. 3/ If applicable, make a run-time debug run to narrow down which component of the code has the problem. See my post on run-time debug & tracing tools. Try to report something as Crash when executing line 1234 of file blabla.c 4/ Set a priority according the IMPACT it has one the confidence one has in the product. Examples. * Imagine Calc can't handle CSV files, with semi-colon as delimiter. Well, annoying, but there are temporary work around. * Now suppose Calc, take https://issues.apache.org/ooo/show_bug.cgi?id=119836 Won't you fear to use pivot? 5/ Ideally, make a macro to run the test case. Yours, Philippe 2013/6/21 Oliver-Rainer Wittmann <orwittm...@googlemail.com> > Hi, > > On 21.06.2013 08:57, Jürgen Schmidt wrote: > >> On 6/20/13 8:01 PM, Edwin Sharp wrote: >> >>> Yes. please allow to share the following objections: 1. in general, >>> bugs shouldn't be rated >>> >> >> I disagree here and you always rate issues starting with setting a >> priority. And as always you can't fix them all with a fix number of >> developers. It simply doesn't work. That means you have to >> prioritize and that is quite normal. >> >> 2. most are crashes - "release blocker" can be other than crash - >>> i.e. copy chart from Calc into Writer results in chart area without >>> curve. this is a huge bug that doesn't involve a crash >>> >> exactly and we have defined some criteria for issues, crashes, data >> loss and security issues have always high priority. Regressions are >> also very important especially when often used functionality is >> broken. >> >> It is documented in the wiki but I haven't the reference in place >> yet, have to look for it. >> >> 3. with all the respect to Norwegian users, print dialog too wide >>> is a negligible problem >>> >> not for this specific user group and the fix is already available. >> >> 4. there should be a documented evidence to the bug evaluation >>> process, based on approved SOP >>> >> I am not sure if I understand you here >> >> 5. the general public has no declared release date - no need to >>> rush as there is no commitment to fulfill >>> >> no but the project have committed to a release date and I believe >> the majority of the community support the new release. You have to >> set a date and have define what is important for this date. You can >> always do more and can fix more issues but that won't work very >> well. >> >> 6. "minor" bugs should also get attention and be targeted >>> >> definitely but not short in front of a release. And of course nobody >> prevent anybody from fixing such issues. We have a lot of them, many >> are probably not longer valid and can be closed, other are not easy >> to fix and so on. A good start would be of course to simply check >> older issues if they are still valid or not. >> >> 7. the judgment of introducing the sidebar with so many pending >>> bugs should be justified to demonstrate openness >>> >> as far as I know we haven't pending bugs here. Don't mix this up >> with improvement or feature requests. Maybe I don't understand you >> and you can explain it again >> >> 8. RTF is rarely used today - no reason for two appearances in the >>> list >>> >> RTF is as far as I known relevant for Ms interoperability in general >> and important for other MS filters as well. Even the pure format is >> not used often the functionality is important. If somebody knows more >> please correct me. >> >> Just some more background on the RTF filter: > The RTF format is used on copy-and-paste actions between OpenOffice > applications and other applications. > For example, issue 120023 is caused by a defect in the RTF filter. > > > Best regards, Oliver. > > 9. Are there no "critical" bugs in Math, Draw and Base? >>> >> probably yes and probably many other critical bugs in other areas >> that are not detected yet or not proposed as showstopper >> >> 10. Are there enough volunteers to treat these "release blockers" >>> on time? >>> >> we hope we can fix them all but volunteers are never enough ;-) >> >> If you think that other issue should be showstopper as well, please >> propose them on the dev list and we can discuss them. That's the way >> how we want to handle it >> >> Further discussion should take place on the dev list >> >> >> Juergen >> >> >> Thank you >>> >>> >>> >>> On Thu, Jun 20, 2013, at 18:09, Oliver-Rainer Wittmann wrote: >>> >>>> Hi, Any objections to mark these issues as release blocker? >>>> >>>> [1] >>>> https://issues.apache.org/ooo/**buglist.cgi?quicksearch=** >>>> 120250%20120443%20120513%**20120559%20121008%20121143%** >>>> 20121256%20121435%20121479%**20121751%20121925%20121968%** >>>> 20121977%20122163%20122300%**20121772&list_id=68303<https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303> >>>> >>>> >>>> >>>> >>>> Best regards, Oliver. > >> >>>> ------------------------------**------------------------------** >>>> --------- >>>> >>>> >>>> To unsubscribe, e-mail: >>>> qa-unsubscribe@openoffice.**apache.org<qa-unsubscr...@openoffice.apache.org> > >> For additional commands, e-mail: qa-h...@openoffice.apache.org >>>> >>>> >>> ------------------------------**------------------------------** >>> --------- >>> >>> >>> To unsubscribe, e-mail: >>> qa-unsubscribe@openoffice.**apache.org<qa-unsubscr...@openoffice.apache.org> > >> For additional commands, e-mail: qa-h...@openoffice.apache.org >>> >>> >> >> ------------------------------**------------------------------**--------- >> >> >> To unsubscribe, e-mail: >> dev-unsubscribe@openoffice.**apache.org<dev-unsubscr...@openoffice.apache.org> > >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > qa-unsubscribe@openoffice.**apache.org<qa-unsubscr...@openoffice.apache.org> > For additional commands, e-mail: qa-h...@openoffice.apache.org > >
