[Releasing] https://bugreports.qt-project.org/browse/QTBUG-35143 :Scene graph threaded render loop deadlocks on X11

[Ziller Eike]

On Nov 28, 2013, at 8:37 AM, Ziller Eike <Eike.Ziller at digia.com> wrote:

> 
> On Nov 28, 2013, at 7:45 AM, Heikkinen Jani <Jani.Heikkinen at digia.com> wrote:
> 
>> Hi all,
>> 
>> Unfortunately we won't get this fixed early enough so that we would have packages today :( And no-one weren't against releasing RC1 without fixing this so we will release RC1 with current content. That's why there isn't any reason to postpone release to Friday. We will release RC1 today if nothing really serious found during these last hours before actual release
> 
> I think releasing packages without even any kind of workaround to the problem (and be it setting the environment variable within qt creator as a workaround), sends a very bad sign.

to clarify, with "without even any kind of workaround to the problem” I mean workaround that makes it work by default without users running into it in the first place

> “RC” is perceived as “we are almost there”, and releasing a package that *completely* fails to run on an *unknown* number of Linux environments, certainly doesn’t make a good impression.
> It is not unconditionally working on Ubuntu either btw. Quoting Gunnar from IRC:
> 
> <gusletta> it applies to all linux distros, but forcing the render loop to basic does work around the problem
> […]
> <gusletta> it requires a few preconditions, and it needs a non-sandybridge non-nouveau driver to trigger it beceause those are already safeguarded for other reasons, but it is fairly easy to get it to lock up
> […]
> <gusletta> different window managers will probably affect the severity as well as the root problem is that we're getting bad events from the platform plugin (which in turn originate from the windowing system)
> 
> We were advocating to not use sandybridge or nouveau driver in the past btw, since these had heavy problems (which have their own workarounds by now, but not till recently).
> 
> Br, Eike
> 
>> Br,
>> Jani
>> 
>>> -----Original Message-----
>>> From: Turunen Tuukka
>>> Sent: 28. marraskuuta 2013 0:19
>>> To: Ziller Eike; Knoll Lars
>>> Cc: Heikkinen Jani; releasing at qt-project.org
>>> Subject: Re: [Releasing] https://bugreports.qt-project.org/browse/QTBUG-
>>> 35143 :Scene graph threaded render loop deadlocks on X11
>>> 
>>> 
>>> On 27.11.2013 17.30, "Ziller Eike" <Eike.Ziller at digia.com> wrote:
>>> 
>>>> 
>>>> On Nov 27, 2013, at 3:59 PM, Knoll Lars <Lars.Knoll at digia.com> wrote:
>>>> 
>>>>> 
>>>>> 
>>>>> On 27/11/13 15:03, "Heikkinen Jani" <Jani.Heikkinen at digia.com> wrote:
>>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> This issue is P0 and so on blocking the RC1 at the moment. There is
>>>>>> already fix proposals available but those aren¹t passing the CI
>>>>>> 
>>>>>> https://codereview.qt-project.org/#change,72183 : This seems to be
>>>>>> real failure and fix needed before re-stage
>>>>>> https://codereview.qt-project.org/#change,72535 : Failure seems to be
>>>>>> unrelated to change and that¹s why re-staged
>>>>>> 
>>>>>> Because we don¹t have these through CI yet it means it will be
>>>>>> impossible to get packages with these fixes tomorrow morning. If we
>>> get
>>>>>> these through CI soon and after that qt5.git can be integrated without
>>>>>> problems it might be possible to get packages during tomorrow. But
>>> what
>>>>>> if we couldn¹t get these packages tomorrow? I recommend that we
>>> release
>>>>>> RC1 on Friday and fix issue on final.
>>>>>> 
>>>>> It would be very good to get the fixes in, but I don't believe we
>>>>> should delay the RC a lot further because of them. The hanging of the
>>>>> render loop can apparently be worked around by setting the
>>>>> QSG_RENDER_LOOP environment variable to basic.
>>>> 
>>>> 
>>>>> But then we'd somehow need to make sure it's being set in the packages
>>>>> for creator.
>>>> 
>>>> What side effects would that have? There must be some reason why that
>>>> isn¹t the default ;)
>>>> 
>>>> Also I have actually very bad feelings regarding releasing on a friday.
>>>> We had a policy not to do that, what has happened with that?
>>> 
>>> 
>>> Any production release should be done Tue - Thu, if at all possible. But
>>> for development release, like this RC, basically any day is good.
>>> 
>>> I really would like to have the RC out either tomorrow or Friday so that
>>> we would get some testing ongoing during the weekend already. It has been
>>> a while since the beta and pretty much all valid feedback on that has been
>>> received long ago. Having much less that two weeks between RC and Final
>>> most likely does not work as it takes some time to get the feedback - and
>>> making the final release the last week before holidays does not sound
>>> tempting at all.
>>> 
>>> So I would be inclined to say we have this bug in the known issues and get
>>> the RC out Thursday or Friday, unless there is something new that makes it
>>> impossible. Especially since the issue apparently does not happen in the
>>> reference configurations and can be worked around, I do not see this a P0
>>> / blocker for the RC.
>>> 
>>> Yours,
>>> 
>>> 		Tuukka
>>> 
>>> 
>>> 
>>> 
>> 
> 
> -- 
> Eike Ziller, Senior Software Engineer - Digia, Qt
> 
> Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
> 
> _______________________________________________
> Releasing mailing list
> Releasing at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B