2013/9/26 Rob Weir <[email protected]> > On Wed, Sep 25, 2013 at 8:55 AM, Oliver-Rainer Wittmann > <[email protected]> wrote: > > Hi, > > > > resending as my "reply to list" goes only to [email protected] > > > > > > 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? >
I confirmed that the 2 defects are also in 4.0. Then I agree that they are not 4.0.1 ship blocker. - Shenfeng (Simon) > > > 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 <[email protected]> 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< > [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] > >
