[webkit-qt] Conclusion (was RE: Proposal: Qt 4 removal from trunk, Qt 5 changes)

[Osztrogonac Csaba]

Hi,

Jocelyn Turcotte írta:
> My quick opinion on it is that we could:
> - Switch the official bots to Qt5 as soon as possible to aid the Qt5 beta

I don't understand what do you mean about "switch". We still have many Qt5 bots:
- Qt Linux 64-bit Release (Perf) == Qt5-WK1 builder and perf tester bot -  http://build.webkit.org
- Qt Linux 64-bit Release (WebKit2 Perf) == Qt5-WK2 builder and perf tester bot - http://build.webkit.org
- x86-32 Linux Qt Release - Qt5-WebKit1 == Qt5-WK1 builder, JSC/layout/API tester bot - http://build.webkit.sed.hu
- x86-64 Linux Qt Release WebKit2 (Amazon EC2) == Qt5-WK2 builder, JSC/layout/API tester bot - http://build.webkit.sed.hu
- x86-32 Linux Qt Release WebKit2 == Qt5-WK2 builder, JSC/layout/API tester bot - http://build.webkit.sed.hu
- ARMv7 Linux Qt5 Release (Build) == Qt5-WK2 builder
- Qt WK2 EWS == Qt5-WK2 Early Warning System bot - http://queues.webkit.org/

But we don't have buildbot for Windows. Because now QtWebKit isn't buildable on Windows at all.
(We are working on it, see the mail thread about it.) Until we don't have buildable QtWebKit
on Windows with Qt5, the Qt 4.8 Windows builder guarantees that we catch new build regressions
come from WebKit trunk. Maybe only a Qt5 Mac and a Qt5 debug bots are missing a little bit.

> - Branch Qt4 at the same time as Qt5 (two different branches would be better I guess)

I think it would be profitable for Qt4-QtWebKit and Qt5-QtWebKit release
team. In this case they don't have to duplicate cherry-picking most of
security fixes, bug fixes.

> - Remove the Qt4 code from trunk (that might be broken already since the bots won't be running) once we stabilized the Qt5 branch
Of course when we don't run Qt4 buildbots, the code might be broken. :)
The question is if/until when do we want to maintain Qt4 code paths.
This question should be answered by the project owners/maintainers.

I'm only the admin of most of the bots, so it's all the same for me which Qt
version runs on the bots. :)

I can say only some contra against removing Qt 4 support too early:
- Now automatic Qt5 update on the bots isn't solved yet. Because gitorious isn't
   so stable now. I'm working on hard to make the Qt5 build script support stable
   mirrors and adding a new "update-qt5-to-the-latest-pinned-qt5-hash" buildstep
   before compiling. I think it will be fixed in 1-2 weeks.
- Windows build doesn't work with Qt5 now. With dropping Qt 4 support,
   there won't be buildbot to catch new build regression on Windows.
- Mac, SH4, MIPS bots are out of my scope. I don't know anything
if they are ready or not to migrating to Qt5. Boston? Recife? Holger? :)

br,
Ossy


> On Wed, 6 Jun 2012 09:37:14 +0200
> ext Allan Sandfeld Jensen <kde at carewolf.com> wrote:
> 
>> On Wednesday 06 June 2012, simon.hausmann at nokia.com wrote:
>>> Hm, okay, maybe we can improve the timing :)
>>>
>>> What would be the advantage of waiting until Qt 5.0 is released? What would
>>> be different at that point?
>>>
>>>
>> By branching of the same version as Qt 5.0 it will hopefully benifit from the 
>> stabilization up to Qt 5.0, plus it means we can hopefully keep the QtWebKit 
>> for Qt 4.x version close to the branch used for Qt 5.0, which means we can 
>> possible merge similar patches, etc.
>>
>> From an communication POV it is also simpler to explain that this fork will 
>> provide the features available in QtWebKit for Qt 5.0 to Qt 4.x (except 
>> WebKit2 of course).
>>
>>
>> `Allan