On Wed, Sep 25, 2013 at 8:55 AM, Oliver-Rainer Wittmann <orwittm...@googlemail.com> wrote: > Hi, > > resending as my "reply to list" goes only to qa@o.a.o > > > On 25.09.2013 12:17, Yuzhen Fan wrote: >> >> -1: >> >> I vote -1 for RC3 because of these 3 issues, the first two are function >> regressions from 3.4.1 and 4.0.0, the last one is for bad user experience >> on Redhat 64bit installation. >> >> Bug 123345 - [Regression]Docx embedded table display incorrectly >> Bug 123346 - [Regression]the bullet display incorrectly when open docx >> file >> in AOO >> Bug 123348 - Cannot integrate AOO 4.0.0 in desktop menu in Redhat6.4 64bit >> > > I can confirm that 123345 and 123346 are regressions which had been > introduced in AOO 4.0.0 >
So these are not new defects in 4.0.1? > On the one hand I agree that regressions introduced in the latest release > should be fixed in the next release. > On the other hand we are already quite far in our planned AOO 4.0.1 release > schedule and AOO401rc3 contains a lot of important bug fixes and > improvements regarding our supported languages. Thus, I strongly vote for > releasing AOO401rc3 as AOO 4.0.1 under these circumstances. > From my point of view 123345 and 123346 should be release blocker for our > next release. > It is important that we understand the different role of a minor x.y.1 release. When we have a major release, like 4.0.0, we're making tons of code changes, adding new features, and potentially (and very likely actually) introducing many regressions. So the QA effort for a major release has many aims: -- test new features -- verify new fixes -- identify the regressions introduced in the code We can never test 100% of a product. Maybe computer-based proofs of correctness have been done in some chip designs, but generally complete coverage is never possible. So we focus on the most-commonly used features of the product, across a large matrix of platforms and applications. The goal, if you think about it is: to increase the confidence that we are *not* releasing a product that has a bug in it that will make it unusable for our users. We can never guarantee this. We can only increase our confidence in this. At whatever finite point we stop our testing it is always possible that the next test would have found a killer defect. So the challenge in designing a test plan is to identify what tests can be performed in a reasonable finite test pass (or passes) that will reduce the chances of a killer defect still being in the code. I think Yuzhen did a great job at designing the test plans for the releases. The quality approach in a minor maintenance release like 4.0.1 is different. We don't make tons of code changes. In fact we are very restrictive. We only fixed showstopper bugs that were proposed on the mailing list, discussed and approved by the Release Manager. The goal is have no new regressions introduced. The goal is to fix targeted bugs, and get those fixes out to users quickly. If we didn't think that speed of release was an important thing here then we would all be working on 4.1.0, not 4.0.1. So the fact that we are working on 4.0.1 at all shows that there is some urgency to get bug fixes released. In any case, if new bugs are found in 4.0.1 testing, I don't think it matters whether they were found in RC1, RC2, RC3, during the vote or the day after the vote. It doesn't matter who discovered the bug or when they discovered it. The question is: How severe is the defect? Is it a showstopper? Is it something we hold back 4.0.1 for? Or something less severe that we put in 4.1.0? > Regarding issue 123348: > As far as I know this issue is not new and already known. I think a > workaround exist. Thus, for me this is not a release blocker. > > Yu Zhen, do you think you can change your mind regarding your vote? > I don't think we should ask anyone to change their votes. A release is approved by majority vote. It does not need to be unanimous. We should not be afraid to have a dissenting vote. But I do hope we can develop a shared view of the true value of QA and its role in the project. It is not just the defects found and reported. The true value is that the tests were completed and that *nothing worse than these three bugs was found*. That is the information we needed to know. That is what gives us increased confidence that 4.0.1 is ready to release. It also helps ensure that 4.1.0 (or even 4.0.2, if needed) will be even better. Regards, -Rob > > Best regards, Oliver. > > >> >> Regards, >> Yu Zhen >> >> >> On Wed, Sep 25, 2013 at 4:07 PM, Herbert Duerr <h...@apache.org> wrote: >> >>> this is a call for vote on releasing the RC3 release candidate as >>>> >>>> Apache OpenOffice 4.0.1. This will be an important update release for >>>> Apache OpenOffice 4.0 to fix some serious regressions and to introduce >>>> some new languages (Basque, Khmer, Lithuaian, Polish, Serbian Cyrillic, >>>> Swedish, Turkish, Vietnamese and Chinese Traditional). It is a further >>>> key milestone to continue the success of OpenOffice. >>>> [...] >>>> >>>> The RC is based on the release branch AOO401, revision 1524958! >>>> >>>> Please vote on releasing this package as Apache OpenOffice 4.0.1. >>>> [...] >>>> >>>> [ ] +1 Release this package as Apache OpenOffice 4.0.1 >>>> [ ] 0 Don't care >>>> [ ] -1 Do not release this package because... >>>> >>> >>> +1 : release AOO401rc3 (a.k.a. r1524958) as Apache OpenOffice 4.0.1 >>> >>> Herbert >>> >>> >>> >>> ------------------------------**------------------------------**--------- >>> 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: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
