On Thu, Jun 20, 2013 at 2:01 PM, Edwin Sharp <[email protected]> wrote: > 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 >
We have a debate like this before every release. There are items worth considering: 1. All software has bugs. 2. The more you test the more bugs you find. (Every class of testers finds a new class of bugs) 3. The time needed to fix all bugs in OpenOffice is measured in years, not weeks. 4. AOO 4.0 contains fixes to many, many bugs already, including fixes for serious bugs from AOO 3.4.1 and earlier. So there is no one perfect answer. Spending more time to fix bugs in AOO 4.0 does two things: 1. Improves the quality of AOO 4.0, which is good for future AOO 4.0 users. 2. Delays the delivery of the existing bug fixes and new features, which is bad for AOO 3.4 users (around 50 million of them) So it is important to watch out for quality and the satisfaction of our users. But we should also consider the 3.4 users, who are patiently waiting for bug fixes that have already been made. (Some might say that the solution here is to have a 3.4.2 release, etc. But that doesn't change anything. You still have the tension between those who want to fix more bugs (there are always more) and those who want to release the fixes we already have). Since we are weighing the value of potential new bug fixes against the value of already made bug fixes, some sort of bug prioritization is reasonable, I think. 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 to other areas of the code, including bug fixes. So once we have completed the regression test passes we need to be very selective about what bugs we fixed and the potential impact of the fix. Changing code after regression is risky, since we have no full test pass left to find any new bugs introduced. It is likely we have a 4.1 (or even 4.0.1) release later this year. If we want to focus on bug fixing there then that could be possible, but we'd want to do that *before* a regression test pass, so we can ensure that no new bugs are introduced. I agree with you that we are not date-driven. Quality is what matters. But quality in the abstract is not the focus. It is the quality that end-users actually have on their machines, their actual experience. And the quality they experience does not change until we actually release a new version. Regards, -Rob > > > 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: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
