On Wed, Sep 25, 2013 at 12:34 PM, janI <j...@apache.org> wrote: > On 25 September 2013 17:35, Shenfeng Liu <liush...@gmail.com> wrote: > >> 2013/9/25 Oliver-Rainer Wittmann <orwittm...@googlemail.com> >> >> > 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 >> > >> > 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. >> > >> > 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? >> > >> > >> > Best regards, Oliver. >> > >> >> IMO, if we have quick solution for 123345 and 123346, and the impact is >> limited, I'd rather to wait for 3~4 more days a RC4. And the testing and >> voting for RC3 can be inherited. For a quality release, ideally our target >> should be no regression. >> If it is difficult to give a save fix quickly and the issues are only about >> special samples, we can consider to defer them to next release. >> Just my $0.02. >> > > I agree with the above. > > I find it disturbing that, 4.0 was postponed due to QA issues, and we even > made a blog about it. 4.0.1 goes out despite a public rejection from QA. I > am sure some of the press will pick this up. >
I'm sure they will quote you, Jan, if you post inflammatory comments. That's what the press does. No doubt about that. But the real question is this: how does the community decide these questions? > To be consistent we should make a blog telling that we ignore QA just to > make a fast release. I know this will not (and should not happen), but I am > afraid we might be reading it in the press. > Say it a few more times and your prediction will surely come true. > I would like to, for the future, have a discussion of the QA role. Are QA > statements merely a polite advice to the release manager (status today), or > can we make a rule stating that we do NOT release if QA reject the > candidate. > The process on this is quite clear: "Votes on whether a package is ready to be released use majority approval -- i.e. at least three PMC members must vote affirmatively for release, and there must be more positive than negative votes. Releases may not be vetoed. Generally the community will cancel the release vote if anyone identifies serious problems, but in most cases the ultimate decision, lies with the individual serving as release manager. The specifics of the process may vary from project to project, but the 'minimum quorum of three +1 votes' rule is universal." See: http://www.apache.org/foundation/voting.html In this case three issues were identified late in the voting process. That is not a failure of the voting process. If you recall with 4.0.0 we also had late information and we set aside a RC even though it has a successful vote. Every defect report and every defect is unique and trying to paint them as equivalent is not a very good approach. Just because a bug is reported late does not make it a show stopper. IMHO the responsible thing is comment on the actual defects that were reported and make the argument, if you can, that any or all of them justify delaying the delivery of the more severe (IMHO) defects that are already fixed in 4.0.1 RC3. If you are concerned about quality than surely you should be concerned that these fixes are not yet in the hands of 4.0.0 users. Observant project members will recall seeing this same argument made before the release of every release we've ever had. You can always spend more time finding and fixing more bugs. It does not require a great open source project to not release but just to endlessly refine. The skill comes from *prioritizing* and knowing when it is time to ship. There is no one answer here. Sometimes it makes sense to delay. But sometimes is does not. The decision is a community decision, not a decision reserved for QA alone. And they way we make this decision is via a release vote. Regards, -Rob > rgds > jan I. > > >> >> - Shenfeng (Simon) >> >> >> >> > >> > >> > >> >> 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.**a**pache.org< >> http://apache.org> >> >>> <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-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
