I totally support Stephen point! you are not alone! BTW, It's seems I discovered the problem, and say the `lib/Qt*.dll` can be safety delete. It will broken CMake build just in recently. but seems nobody care. I don't know how to search in the list, so pls just ignored what I say.
anyway, it's done. and we have to move on. 2013/6/18 Stephen Kelly <[email protected]> > On Tuesday, June 18, 2013 13:16:42 you wrote: > > Hi Stephen, > > > > I think there should have been an answer on the list to the concern. > > Yes. There's no point in posing such questions if the answers are ignored. > > Do you think it's important to ask for a list of important patches at all, > or > should we just forego that entirely? Not asking would probably help get an > RC > out sooner. > > > But having said that I don't think this should have blocked the RC. > > Is that the kind of claim that should be debated on a case-by-case basis? > Is > that what you intend to ensure happens in the future (ensuring that there > is > time for such discussion, and that the discussion happens)? > > Or do you want to be more clear on what is and is not a release blocking > issue? Is it always just your call? Then why ask for a list of important > patches? > > You say that completely non-working cmake files is not a blocker for the > RC. > Qt 5.0.0 was also released (to the surprise of many and to my embarassment, > despite raising it as an issue) with broken cmake files. Now the 5.1.0 RC1 > is > released with cmake files embarassingly completely non-working on Windows. > > The brokenness was not discovered by CI because the build tree is so very > different from the install tree. This relates to the removal of the dlls > from > the lib directory, which happened recently. Unfortunately, it seems that > buildsystem changes are very common very late into the release cycle. You > seem > to want to ensure that I have no time to check whether such changes break > the > cmake files entirely. > > What is your position on whether completely broken cmake files block the > 5.1.0 > final release? Consider that such problems are always fixed very quickly > when > discovered. The only delay with the patch I linked to was due to the CI > system. > > > It's > > something we can put into the known issues section on the wiki. And IMO > it > > was really important to finally get the RC out. > > That's a very obvious position for you to take. > > What causes you to consider 'release as soon as possible, no matter what' > over > one extra day to take a patch noted as important, after a list of such > patches > was requested? > > What are the particular issues that prevented releasing the RC two weeks > ago? > What is in-scope for legitimate quality-concerns, in your view? > > Thanks, > > -- > Stephen Kelly <[email protected]> | Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 > KDAB - Qt Experts - Platform-Independent Software Solutions > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development > > -- Best Regards Yuchen
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
