[Development] New installers available
loaden at gmail.com
Tue Jun 18 16:21:55 CEST 2013
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
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 <stephen.kelly at kdab.com>
> 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,
> should we just forego that entirely? Not asking would probably help get an
> 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?
> that what you intend to ensure happens in the future (ensuring that there
> 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
> You say that completely non-working cmake files is not a blocker for the
> 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
> 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
> the lib directory, which happened recently. Unfortunately, it seems that
> buildsystem changes are very common very late into the release cycle. You
> to want to ensure that I have no time to check whether such changes break
> cmake files entirely.
> What is your position on whether completely broken cmake files block the
> final release? Consider that such problems are always fixed very quickly
> discovered. The only delay with the patch I linked to was due to the CI
> > It's
> > something we can put into the known issues section on the wiki. And IMO
> > 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'
> one extra day to take a patch noted as important, after a list of such
> was requested?
> What are the particular issues that prevented releasing the RC two weeks
> What is in-scope for legitimate quality-concerns, in your view?
> Stephen Kelly <stephen.kelly at kdab.com> | 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
> Development at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development