Re: Triage for AOO 4.0.0 Release Blockers
Hi, On 22.06.2013 09:55, Oliver-Rainer Wittmann wrote: Hi, Am 20.06.2013 um 17:09 schrieb Oliver-Rainer Wittmann orwittm...@googlemail.com: Hi, On 06.06.2013 13:54, Yuzhen Fan wrote: Hi All, Here is the list of identified candidates[1]/[2] which are proposed to be 4.0.0 release blockers. Please indicate your selections for release blockers by giving 1 vote to 1 bug (the vote field is beside the importance field, in a bug form). We hope to get the vote score this week, any bugs you think most critical to you, please bring out and let's discuss. [1] https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=4.0.0_release_blocker%3Fsharer_id=249289list_id=64740 [2] Also attach the file for the list (AOO4.0.0_release_blocker_candidates.ods) Armin, Jürgen, Andre and myself reviewed in the last days the list of issues which had been requested for release blocker (release blocker flag = '?') and are not solved. We propose the following issues as release blockers [1]: - 120250 - 120443 (actually 121772 - 120443 is a dup. of this one) - 120513 - 120559 - 121008 - 121143 - 121256 - 121435 Has been fixed in the meanwhile. Thus, it can removed from the list. This statement is only meant for 121435 just to avoid unambigious interpretation ;-) Best regards, Oliver. Best regards, Oliver. - 121479 - 121751 - 121925 - 121968 - 121977 - 122163 - 122300 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%20121772list_id=68303 Best regards, Oliver. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
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. 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%20121772list_id=68303 Best regards, Oliver. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
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%20121772list_id=68303 Best regards, Oliver. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Thank you for this feedback. On Fri, Jun 21, 2013, at 9: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. 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%20121772list_id=68303 Best regards, Oliver. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
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 I don't understand the second part of the sentence. I have divided the bugs regarding the sidebar into three categories. For each category exists one meta issue: 1. Bugs that have to be fixed for the 4.0 release are covered by issue 121420 (https://issues.apache.org/ooo/show_bug.cgi?id=121420) At the moment there are no open bugs blocking it. 2. Bugs that should be addressed after the 4.0 release are marked as blockers of issue 122364 (https://issues.apache.org/ooo/show_bug.cgi?id=122364) These are bugs that don't have a big impact on the majority of users or would require a tremendous amount of work to fix them. There are six bugs in this category. 3. Requested enhancements form the third category described by issue 122257 (https://issues.apache.org/ooo/show_bug.cgi?id=122257). There are 18 feature requests or enhancements. As said above, only bugs in the first category will be fixed for the 4.0 release. At the moment there are no such open bugs. -Andre 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. 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%20121772list_id=68303 Best regards, Oliver. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional
Re: Triage for AOO 4.0.0 Release Blockers
My meaning is, respecting current users of OpenOffice who reported bugs and see those bugs not resolved while new features (sidebar) are being introduced. I think they deserve at least an explanation how introducing new features is more important from fixing bugs that bothers them (after all, they took the time to report them). On Fri, Jun 21, 2013, at 10:22, Andre Fischer wrote: 7. the judgment of introducing the sidebar with so many pending bugs should be justified to demonstrate openness I don't understand the second part of the sentence. I have divided the bugs regarding the sidebar into three categories. For each category exists one meta issue: 1. Bugs that have to be fixed for the 4.0 release are covered by issue 121420 (https://issues.apache.org/ooo/show_bug.cgi?id=121420) At the moment there are no open bugs blocking it. 2. Bugs that should be addressed after the 4.0 release are marked as blockers of issue 122364 (https://issues.apache.org/ooo/show_bug.cgi?id=122364) These are bugs that don't have a big impact on the majority of users or would require a tremendous amount of work to fix them. There are six bugs in this category. 3. Requested enhancements form the third category described by issue 122257 (https://issues.apache.org/ooo/show_bug.cgi?id=122257). There are 18 feature requests or enhancements. As said above, only bugs in the first category will be fixed for the 4.0 release. At the moment there are no such open bugs. -Andre - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
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
Re: Triage for AOO 4.0.0 Release Blockers
On 21.06.2013 12:39, Edwin Sharp wrote: My meaning is, respecting current users of OpenOffice who reported bugs and see those bugs not resolved while new features (sidebar) are being introduced. I think they deserve at least an explanation how introducing new features is more important from fixing bugs that bothers them (after all, they took the time to report them). That is an interesting view on things but one that I don't share. Some random thoughts on this: - Fixing a bug usually takes a lot more time and effort than reporting one. - There where a log of bugs fixed. More will be fixed in the coming weeks. - It is no a display of disrespect when a certain bug is not fixed. - There is no anonymous force of nature that fixes bugs in OpenOffice and just has to be pointed in the right direction. The work is done by individuals with a free will who can and do choose what they are working on. You and I can express wishes but ultimately we can not control the work of volunteers. - The sidebar is a feature for everybody not only for a small minority of users. Therefore it is an important improvement that benefits a lot of people, including those who report bugs that don't get fixed. - The assumption that introducing a new feature like the sidebar is more important than fixing bugs is wrong and a little offensive. We are doing both. Regards, Andre On Fri, Jun 21, 2013, at 10:22, Andre Fischer wrote: 7. the judgment of introducing the sidebar with so many pending bugs should be justified to demonstrate openness I don't understand the second part of the sentence. I have divided the bugs regarding the sidebar into three categories. For each category exists one meta issue: 1. Bugs that have to be fixed for the 4.0 release are covered by issue 121420 (https://issues.apache.org/ooo/show_bug.cgi?id=121420) At the moment there are no open bugs blocking it. 2. Bugs that should be addressed after the 4.0 release are marked as blockers of issue 122364 (https://issues.apache.org/ooo/show_bug.cgi?id=122364) These are bugs that don't have a big impact on the majority of users or would require a tremendous amount of work to fix them. There are six bugs in this category. 3. Requested enhancements form the third category described by issue 122257 (https://issues.apache.org/ooo/show_bug.cgi?id=122257). There are 18 feature requests or enhancements. As said above, only bugs in the first category will be fixed for the 4.0 release. At the moment there are no such open bugs. -Andre - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Dear Andre This is exactly the problem! When you grab a bug from the top and critical bugs continuously enter the list - The minor bugs at the bottom will never get attention. On Fri, Jun 21, 2013, at 14:24, Andre Fischer wrote: All good ideas. I would like to add another one. I am a developer. When I spend time on fixing bugs then I sometimes wish there where a big list of all open bugs that are sorted according to importance. I would go down the list and grab a bug from the top that lies in the area of my expertise (Impress, UI, Slideshow, Sidebar). Without such a list I have to prioritize bugs by myself. And if I do that then I use my own judgement of which bug is important and which is not. Regards, Andre - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Bug policy debate and so on.. Well, just sharing experience from as a past developper and notorious bug fighter. There is no other point in creating a database of bugs and not treating them, than to have an ultra-complicated list of known issues (so complex that users report are duplicated) and frustrated reporters (and testers). It is no a display of disrespect when a certain bug is not fixed. Yes until you have a list of open bugs, which generated itself a list of duplicates... What matters is the evolution ratio closed / confirmed by release (e.g. 3.4.1) and cumulated version (3.4.x). I would like to add another one. I am a developer. When I spend time on fixing bugs then I sometimes wish there where a big list of all open bugs that are sorted according to importance. I would go down the list and grab a bug from the top that lies in the area of my expertise (Impress, UI, Slideshow, Sidebar). Without such a list I have to prioritize bugs by myself. And if I do that then I use my own judgement of which bug is important and which is not. This further illustrate the fact that in order to handle these list, one has introduced techniques such as priority and vote for bug. My own experience shows, that all these are not good policy for bug treatment, it's a dispair. Bug should be assigned in groups regarding a feature with final objective in mind. What do I mean by feature. Take for instance in Calc, the pivot table function. All bug regarding pivot table should be treated together, or most of them. Why concentrating? Because: 1/ It takes time to fix a bug, because one needs to understand or re-understand the implementation. - Fixing a bug usually takes a lot more time and effort than reporting one. Also, often because test case scenario are not narrow enough - see my other post. 2/ By taking all bugs related to a piece of source code, each time you become more familliar and so more efficient. In a sense you proof reading it several times, you get leverage on bug handling. 3/ By reviewing several related bugs, you reduce the risk or regression, as you've been through it several times, each time with a deeper understanding. The other thing to note is that bug fixes are not risk-free. Studies have shown that 25% of defects in code are side effects of changes. FFmpeg is really a good example for regression, to a point I stopped reporting (first you have to convince it's a bug, then it lays pending to a wish to fix it and then you find older release which works...) 4/ Having fixed a bulk of related feature bugs, report the fix is implemented to all different reporters. They will(hopefully if done in a reasonable time, not like me who got a mail for a bug I posted 2 years ago...) test their bug and by doing so improve the total quality control and reduce regression risk. What do I mean by assigning by objective. Well, here is for me where the votes should take place, grouped by user, tester and developer (might have different interests). Suppose, pivot table code is considered as a mess by developpers and ought to be re-written by next release. There is no point in fixing pivot table bug now. Suppose users consider that priority should be assigned in this order 1. fix doc format issues 2. fix grammar check issues It has to be respected and if there is a critical bug in another field, well if it will wait. One should not vote for a bug, but rather for an expected behaviour. Phil 2013/6/21 Andre Fischer awf@gmail.com On 21.06.2013 13:42, Edwin Sharp wrote: Dear Andre This is exactly the problem! When you grab a bug from the top and critical bugs continuously enter the list - The minor bugs at the bottom will never get attention. You make that sound like it where a bad thing. A bug is critical because it affects man users and/or causes data loss (and one or the other additional property). Therefore it should be fixed before minor bugs are fixed. This is how it should work. If it does not then I see two reasons for it: - There is not one single sorted list of bugs. Everybody has his or her own idea of which bug is important and which isn't. - The way in which bugs are ordered is not good enough. This ordering is certainly not easy to define and it will be impossible to define it in a way that makes everybody happy. But if there where one central list of ordered bugs then we could at least try. And everybody could help to improve it. With such a list you have to rely on my judgement or that of other developers. -Andre On Fri, Jun 21, 2013, at 14:24, Andre Fischer wrote: All good ideas. I would like to add another one. I am a developer. When I spend time on fixing bugs then I sometimes wish there where a big list of all open bugs that are sorted according to importance. I would go down the list and grab a bug from the top that lies in the area of my expertise (Impress, UI, Slideshow, Sidebar). Without such a list I have to prioritize bugs by
Re: Triage for AOO 4.0.0 Release Blockers
On Fri, Jun 21, 2013 at 11:09 AM, Sub Phil phil40...@gmail.com wrote: Bug policy debate and so on.. Well, just sharing experience from as a past developper and notorious bug fighter. There is no other point in creating a database of bugs and not treating them, than to have an ultra-complicated list of known issues (so complex that users report are duplicated) and frustrated reporters (and testers). It is no a display of disrespect when a certain bug is not fixed. Yes until you have a list of open bugs, which generated itself a list of duplicates... What matters is the evolution ratio closed / confirmed by release (e.g. 3.4.1) and cumulated version (3.4.x). Metrics like this could be useful if we're measuring defects not defect reports. Unfortunately the duplicates, plus the how do I? and other non-defects that users enter , make this difficult to estimate. My impression is that close to half of the Bugzilla reports are invalid. We'd need to do a major clean up of Bugzilla before we even knew how many actual defects are there. I would like to add another one. I am a developer. When I spend time on fixing bugs then I sometimes wish there where a big list of all open bugs that are sorted according to importance. I would go down the list and grab a bug from the top that lies in the area of my expertise (Impress, UI, Slideshow, Sidebar). Without such a list I have to prioritize bugs by myself. And if I do that then I use my own judgement of which bug is important and which is not. To the extent that rated priority is a motivation to volunteers, this is true. But we have all sorts of volunteers. I think some of them have enough stress in their real lives that they don't want to take high priority issues and world rather work on lower priority ones, where there is less urgency. Also, much of this depends on where we are in the release. Once we have completed regression testing we want to avoid introducing additional risk. So it is no longer open season for fixing just any defect. We need to weigh the risks involved. In many cases, for less serious bugs, we fix them in a later release, so they can undergo a full test pass. This further illustrate the fact that in order to handle these list, one has introduced techniques such as priority and vote for bug. My own experience shows, that all these are not good policy for bug treatment, it's a dispair. Prioritization is not despair. It is just acknowledging that changing the code after testing has completed is risky, and that we should only make changes now where absolutely necessary. Despair is what users feel when we don't show such precautions and see a last minute fix introduce a serious bug that is not caught before release. Bug should be assigned in groups regarding a feature with final objective in mind. What do I mean by feature. Take for instance in Calc, the pivot table function. All bug regarding pivot table should be treated together, or most of them. Why concentrating? Because: 1/ It takes time to fix a bug, because one needs to understand or re-understand the implementation. - Fixing a bug usually takes a lot more time and effort than reporting one. Also, often because test case scenario are not narrow enough - see my other post. 2/ By taking all bugs related to a piece of source code, each time you become more familliar and so more efficient. In a sense you proof reading it several times, you get leverage on bug handling. 3/ By reviewing several related bugs, you reduce the risk or regression, as you've been through it several times, each time with a deeper understanding. This is a good practice to follow, before the main test pass completes. After than we intentionally aim to minimize the changes to the code. Otherwise we don't have a good sense of what the quality is we're release. Bugs are bad, but with testing we can at least have a degree of confidence that there are no defects above a certain severity level. If we make unrestrained changes after the test pass then our degree of confidence is reduced or eliminated. The other thing to note is that bug fixes are not risk-free. Studies have shown that 25% of defects in code are side effects of changes. FFmpeg is really a good example for regression, to a point I stopped reporting (first you have to convince it's a bug, then it lays pending to a wish to fix it and then you find older release which works...) I know it can be frustrating as a tester to see defects you reported go unfixed in a release. I've been there. 4/ Having fixed a bulk of related feature bugs, report the fix is implemented to all different reporters. They will(hopefully if done in a reasonable time, not like me who got a mail for a bug I posted 2 years ago...) test their bug and by doing so improve the total quality control and reduce regression risk. What do I mean by assigning by objective. Well, here is for me where the votes should
Re: Triage for AOO 4.0.0 Release Blockers
IMHO there are no bad ideas here. They are just mistimed ;-) It would be mad to change the bug policy now, but for the future it might have an impact. 2013/6/21 Rob Weir robw...@apache.org On Fri, Jun 21, 2013 at 11:09 AM, Sub Phil phil40...@gmail.com wrote: Bug policy debate and so on.. Well, just sharing experience from as a past developper and notorious bug fighter. There is no other point in creating a database of bugs and not treating them, than to have an ultra-complicated list of known issues (so complex that users report are duplicated) and frustrated reporters (and testers). It is no a display of disrespect when a certain bug is not fixed. Yes until you have a list of open bugs, which generated itself a list of duplicates... What matters is the evolution ratio closed / confirmed by release (e.g. 3.4.1) and cumulated version (3.4.x). Metrics like this could be useful if we're measuring defects not defect reports. Unfortunately the duplicates, plus the how do I? and other non-defects that users enter , make this difficult to estimate. My impression is that close to half of the Bugzilla reports are invalid. We'd need to do a major clean up of Bugzilla before we even knew how many actual defects are there. I would like to add another one. I am a developer. When I spend time on fixing bugs then I sometimes wish there where a big list of all open bugs that are sorted according to importance. I would go down the list and grab a bug from the top that lies in the area of my expertise (Impress, UI, Slideshow, Sidebar). Without such a list I have to prioritize bugs by myself. And if I do that then I use my own judgement of which bug is important and which is not. To the extent that rated priority is a motivation to volunteers, this is true. But we have all sorts of volunteers. I think some of them have enough stress in their real lives that they don't want to take high priority issues and world rather work on lower priority ones, where there is less urgency. Also, much of this depends on where we are in the release. Once we have completed regression testing we want to avoid introducing additional risk. So it is no longer open season for fixing just any defect. We need to weigh the risks involved. In many cases, for less serious bugs, we fix them in a later release, so they can undergo a full test pass. This further illustrate the fact that in order to handle these list, one has introduced techniques such as priority and vote for bug. My own experience shows, that all these are not good policy for bug treatment, it's a dispair. Prioritization is not despair. It is just acknowledging that changing the code after testing has completed is risky, and that we should only make changes now where absolutely necessary. Despair is what users feel when we don't show such precautions and see a last minute fix introduce a serious bug that is not caught before release. Bug should be assigned in groups regarding a feature with final objective in mind. What do I mean by feature. Take for instance in Calc, the pivot table function. All bug regarding pivot table should be treated together, or most of them. Why concentrating? Because: 1/ It takes time to fix a bug, because one needs to understand or re-understand the implementation. - Fixing a bug usually takes a lot more time and effort than reporting one. Also, often because test case scenario are not narrow enough - see my other post. 2/ By taking all bugs related to a piece of source code, each time you become more familliar and so more efficient. In a sense you proof reading it several times, you get leverage on bug handling. 3/ By reviewing several related bugs, you reduce the risk or regression, as you've been through it several times, each time with a deeper understanding. This is a good practice to follow, before the main test pass completes. After than we intentionally aim to minimize the changes to the code. Otherwise we don't have a good sense of what the quality is we're release. Bugs are bad, but with testing we can at least have a degree of confidence that there are no defects above a certain severity level. If we make unrestrained changes after the test pass then our degree of confidence is reduced or eliminated. The other thing to note is that bug fixes are not risk-free. Studies have shown that 25% of defects in code are side effects of changes. FFmpeg is really a good example for regression, to a point I stopped reporting (first you have to convince it's a bug, then it lays pending to a wish to fix it and then you find older release which works...) I know it can be frustrating as a tester to see defects you reported go unfixed in a release. I've been there. 4/ Having fixed a bulk of related feature bugs, report the fix is implemented to all different reporters. They
Re: Triage for AOO 4.0.0 Release Blockers
Hi, On 06.06.2013 13:54, Yuzhen Fan wrote: Hi All, Here is the list of identified candidates[1]/[2] which are proposed to be 4.0.0 release blockers. Please indicate your selections for release blockers by giving 1 vote to 1 bug (the vote field is beside the importance field, in a bug form). We hope to get the vote score this week, any bugs you think most critical to you, please bring out and let's discuss. [1] https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=4.0.0_release_blocker%3Fsharer_id=249289list_id=64740 [2] Also attach the file for the list (AOO4.0.0_release_blocker_candidates.ods) Armin, Jürgen, Andre and myself reviewed in the last days the list of issues which had been requested for release blocker (release blocker flag = '?') and are not solved. We propose the following issues as release blockers [1]: - 120250 - 120443 (actually 121772 - 120443 is a dup. of this one) - 120513 - 120559 - 121008 - 121143 - 121256 - 121435 - 121479 - 121751 - 121925 - 121968 - 121977 - 122163 - 122300 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%20121772list_id=68303 Best regards, Oliver. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Yes. please allow to share the following objections: 1. in general, bugs shouldn't be rated 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 3. with all the respect to Norwegian users, print dialog too wide is a negligible problem 4. there should be a documented evidence to the bug evaluation process, based on approved SOP 5. the general public has no declared release date - no need to rush as there is no commitment to fulfill 6. minor bugs should also get attention and be targeted 7. the judgment of introducing the sidebar with so many pending bugs should be justified to demonstrate openness 8. RTF is rarely used today - no reason for two appearances in the list 9. Are there no critical bugs in Math, Draw and Base? 10. Are there enough volunteers to treat these release blockers on time? 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%20121772list_id=68303 Best regards, Oliver. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
On Fri, Jun 7, 2013 at 10:34 AM, I. Park ipark...@gmail.com wrote: Hello Rob, O.k., I'm not too sure if your incorrectly marked CONFIRMED topic mentioned below has to do with Bugzilla, but I noticed on couple occasions that when filling out new bugs the CONFIRMED is set by default. I had to go back a few times and change it to UNCONFIRMED. That's fine. When a tester enters a new bug it probably should be marked CONFIRMED. That's because testers know what they are doing and would only enter a bug report for a bug that was real and reproducible. -Rob Just my two-cents. I. Park On Thu, Jun 6, 2013 at 8:33 PM, Rob Weir robw...@apache.org wrote: On Thu, Jun 6, 2013 at 8:47 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 6/6/13 1:54 PM, Yuzhen Fan wrote: Hi All, Here is the list of identified candidates[1]/[2] which are proposed to be 4.0.0 release blockers. Please indicate your selections for release blockers by giving 1 vote to 1 bug (the vote field is beside the importance field, in a bug form). We hope to get the vote score this week, any bugs you think most critical to you, please bring out and let's discuss. Please wait, I think we have not agreed on this approach. Voting in the issue is not really helpful. I believe many of these issues can be removed from list and are probably not valid at all. I prefer to discuss showstopper issues on the list as we did for AOO 3.4. With 3.4 we proposed each release blocker on the list, in its own thread, right? But it is not going the be much better if we start with 90 new threads. It looks like all the proposed release blockers are marked confirmed. A few of them pre-date AOO 3.4, but most are more recent. But with a further look I see some were incorrectly marked CONFIRMED. I think some volunteers when they first started set that field after trying to confirm a defect, without understanding that this state should only set if the confirmation test was successful. So we need to review the comments on each bug to see which ones are actually reproduced.I'll try to clean up a few tonight while I watch TV. Also, we probably need to prioritize. For example, a shallow crash (a crash in a common. top-level operation) is higher priority than a crash that only occurs with a specific malformed document. -Rob Juergen [1] https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=4.0.0_release_blocker%3Fsharer_id=249289list_id=64740 [2] Also attach the file for the list (AOO4.0.0_release_blocker_candidates.ods) Regards, Yu Zhen - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
On 6/6/13 2:13 PM, Edwin Sharp wrote: I can understand voting for a new logo. But voting for bugs? A bug is a bug and needs to be fixed. you are correct but I believe it is intended to get a priority list. We have long list of bugs and that can't be fixed all. We always get new bugs and have to decide o demand if they are critical or not to move a release. But in general bugs should be fixed all or should be marked as invalid or whatever applies. Juergen On Thu, Jun 6, 2013, at 14:54, Yuzhen Fan wrote: Hi All, Here is the list of identified candidates[1]/[2] which are proposed to be 4.0.0 release blockers. Please indicate your selections for release blockers by giving 1 vote to 1 bug (the vote field is beside the importance field, in a bug form). We hope to get the vote score this week, any bugs you think most critical to you, please bring out and let's discuss. [1] [1]https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=ru nnamedcmd=4.0.0_release_blocker%3Fsharer_id=249289list_id=64740 [2] Also attach the file for the list (AOO4.0.0_release_blocker_candidates.ods) Regards, Yu Zhen - To unsubscribe, e-mail: [2]qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: [3]qa-h...@openoffice.apache.org Email had 1 attachment: * AOO4.0.0_release_blocker_candidates.ods * 26k (application/vnd.oasis.opendocument.spreadsheet) References 1. https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=4.0.0_release_blocker%3Fsharer_id=249289list_id=64740 2. mailto:qa-unsubscr...@openoffice.apache.org 3. mailto:qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Yes. As long as we don't waste time implementing kindergarten user interfaces and worrying about compatibility to propriety file formats. On Thu, Jun 6, 2013, at 18:45, Peter Junge wrote: That implies all bugs will get fixed if their priority is above low? - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
On Thu, Jun 6, 2013 at 8:47 AM, Jürgen Schmidt jogischm...@gmail.com wrote: On 6/6/13 1:54 PM, Yuzhen Fan wrote: Hi All, Here is the list of identified candidates[1]/[2] which are proposed to be 4.0.0 release blockers. Please indicate your selections for release blockers by giving 1 vote to 1 bug (the vote field is beside the importance field, in a bug form). We hope to get the vote score this week, any bugs you think most critical to you, please bring out and let's discuss. Please wait, I think we have not agreed on this approach. Voting in the issue is not really helpful. I believe many of these issues can be removed from list and are probably not valid at all. I prefer to discuss showstopper issues on the list as we did for AOO 3.4. With 3.4 we proposed each release blocker on the list, in its own thread, right? But it is not going the be much better if we start with 90 new threads. It looks like all the proposed release blockers are marked confirmed. A few of them pre-date AOO 3.4, but most are more recent. But with a further look I see some were incorrectly marked CONFIRMED. I think some volunteers when they first started set that field after trying to confirm a defect, without understanding that this state should only set if the confirmation test was successful. So we need to review the comments on each bug to see which ones are actually reproduced.I'll try to clean up a few tonight while I watch TV. Also, we probably need to prioritize. For example, a shallow crash (a crash in a common. top-level operation) is higher priority than a crash that only occurs with a specific malformed document. -Rob Juergen [1] https://issues.apache.org/ooo/buglist.cgi?cmdtype=doremremaction=runnamedcmd=4.0.0_release_blocker%3Fsharer_id=249289list_id=64740 [2] Also attach the file for the list (AOO4.0.0_release_blocker_candidates.ods) Regards, Yu Zhen - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
