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%20121772&list_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
