[Releasing] [Development] New installers available

[Knoll Lars]

On 18.06.13 16:01, "Stephen Kelly" <stephen.kelly at kdab.com> wrote:

>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.

That wasn't the point. What I meant above is that this should have been
discussed on the ML or on IRC with a public resolution on whether this
blocks or not. 

That hasn't happened which is IMO the bigger problem, not that the patch
will only be in the RC2 or final.

>> 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)?

This was my personal opinion. Again, we should have had a discussion about
it.
> 
>
>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?

I actually missed that mail unfortunately and only saw it today.
>
>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.

I'm pretty sure the intention wasn't to make your life difficult.
>
>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.

IMO this should really be fixed for the final.

What I meant above is that we should currently rather get the RC out,
because we need the feedback in time before everybody leaves on vacation.
We had the problem last summer and not getting the release out before the
summer break delayed 5.0 significantly.
>
>> 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?

Again, see above. It should have been discussed. But at some point we
simply need to get something out, simply because it it will help us more
then waiting further.

The main problem is that getting this in would have required another
submodule update (containing also many other patches), and we've seen
before that this can easily lead to more then a day in delays.
>
>What are the particular issues that prevented releasing the RC two weeks
>ago? 
>What is in-scope for legitimate quality-concerns, in your view?

I wish there was a simple answer to that. But there isn't and it'll always
be somewhat subjective as to how important a certain bug fix is.

Cheers,
Lars