[webkit-qt] Qt Mountain Lion Release bot turning off (was: QtWebKit trunk development after 5.0 release - questions)
zeno at webkit.org
Wed Mar 20 02:56:13 PDT 2013
Thanks a lot for maintaining the buildbot until now!
I do have a Qt WK2 Mountain Lion buildbot running for a while already.
It is currently connected to http://build.webkit.sed.hu/ and is mainly
compiling and running some WebGL pixel tests.
Maybe we could move that one over to build.webkit.org to replace your
If you have a few minutes, maybe we could look into that next week?
On Tue, Mar 19, 2013 at 7:59 PM, Rafael Brandao
<rafael.lobo at openbossa.org>wrote:
> Hello QtWebKittens,
> We will turn off the Qt Mountain Lion Release buildbot soon, since INdT is
> now focused
> on other projects and we don't have the man power needed to properly
> maintain the bot.
> I'm planning to do this over the next week. It should be easy to
> reactivate it, so I hope someone else
> can keep up with this effort.
> On Mon, Feb 11, 2013 at 2:32 PM, "Árvai, Zoltán" <zarvai at inf.u-szeged.hu>wrote:
>> Hi QtWebKit hackers,
>> we started upgrading QtWebKit buildbots and EWS bots
>> today to Ubuntu 12.04 LTS + GStreamer 1.0 + Qt 5.0.1 .
>> Using GStreamer 1.0 will be mandatory soon, see this mail for details:
>> (You can easily install GStreamer 1.0 on Ubuntu 12.04 - see
>> https://trac.webkit.org/wiki/**QtWebKitGardening<https://trac.webkit.org/wiki/QtWebKitGardening>for details)
>> It is a high time to review which bots we still need, which bots we
>> don't need anymore. Or do we need new bots with different configuration?
>> Currently we have the following bots:
>> - Qt Linux Release - 32 bit WK1 only build + layout tests + API tests
>> - Qt Linux Release minimal - 32 bit WK1 only build
>> (good for catching broken ifdef guards)
>> - Qt Windows 32-bit Release - WK1/WK2 build
>> (MS Win Server 2008 R2, MS Visual Studio 2010 Express)
>> performance bots:
>> - Qt Linux 64-bit Release (Perf) - WK1 only build and perf tests
>> - Qt Linux 64-bit Release (WebKit2 Perf) - WK2 build and perf tests
>> The performance results are collected by perf-o-matic server -
>> http://webkit-perf.appspot.com , but this tool is not user friendly
>> to catch performance regressions, because you have to select tests
>> one by one and check them manually. Nowadays they collect performance
>> results, but in these circumstances we need someone who actively checks
>> them. Do we want to appoint someone, or reuse these resources for more
>> important tasks?
>> offline bots:
>> - Qt Linux ARMv7 Release - It is offline, because we have a same
>> bot on build.webkit.sed.hu to build ARM binaries for the tester bot.
>> - Qt Windows 32-bit Debug - We used it when cross compiling on Linux was
>> possible with MinGW (with Qt 4.8). But now the Windows build works
>> with MSVC on native Windows and we don't have more Windows hardware.
>> These bots were not used for a long time. We suggest to
>> delete them completely from build.webkit.org waterfall.
>> What do you think about it?
>> bots maintained by the community:
>> - Qt Linux MIPS32R2 LE Release
>> - Qt Linux SH4 Release
>> - Qt Mountain Lion Release - maintained by INdT
>> (Is INdT still intereseted in QtWebKit on Mac?)
>> - x86-64 Linux Qt Release - 64 bit WK1 only build + layout/API tests
>> - x86-64 Linux Qt Debug - 64 bit WK1 only build + layout/API tests
>> - x86-64 Linux Qt Release WebKit2 (Amazon EC2) -
>> 64 bit build + WK2 layout/API tests
>> - x86-64 Linux Qt Release WebKit2 (Pixel Tests)
>> 64 bit build + WK2 UI process side pixel tests
>> - x86-32 Linux Qt Release WebKit2
>> 32 bit build + WK2 layout/API tests
>> - x86-64 Mountain Lion Qt Release(WebGL Tester)(maintained by zalbisser)
>> 64 bit build + fast/canvas/webgl WK2 tests + API tests
>> - x86-32 Linux Qt Release NRWT
>> 32 bit WK1 only builder + layout tests with 4 parallel threads
>> (It is an experimental bot, because parallel testing is very flakey,
>> on Qt, see https://bugs.webkit.org/show_**bug.cgi?id=77730<https://bugs.webkit.org/show_bug.cgi?id=77730>and
>> https://bugs.webkit.org/show_**bug.cgi?id=106218<https://bugs.webkit.org/show_bug.cgi?id=106218>for details.)
>> - ARMv7 Linux Qt5 Release (Build) - WK1 only build for ARM traditional
>> platform (ARM instruction set, not Thumb2)
>> - ARMv7 Linux Qt5 Release (Test) - JSC+layout tests on a Panda board
>> - x86-32 Linux Qt Debug - 32 bit WK1 only build + layout/API tests
>> Bots for QtWebKit 2.3 (used by carewolf)
>> - QtWebKit2.3-branch x86-32 Linux Release
>> - QtWebKit2.3-staging-branch x86-32 Linux Release
>> How long do you need to run these bots? After we upgrade the OS to
>> Ubuntu 12.04 they might not work properly anymore. To take notice
>> of coming 2.3 relase we might be able to migrate them to a virtual
>> machine has same environment as the actual one. (Debian Squeeze, Qt 4.8)
>> We hope we will finish the upgrade this week, you can see the
>> status here: https://trac.webkit.org/wiki/**QtWebKitBuildBots<https://trac.webkit.org/wiki/QtWebKitBuildBots>
>> On behalf of Szeged team,
>> Ádám Kallai (kadam) and Zoltán Árvai (azbest_hu)
>> On 01/21/2013 05:02 PM, Osztrogonac Csaba wrote:
>>> Hi All,
>>> Qt 5.0 was released a month ago. And I have two major questions
>>> about the future of the QtWebKit trunk (svn.webkit.org) development.
>>> Question no 1:
>>> There is a plan about migration from GStreamer 0.1 to 1.0:
>>> [webkit-dev] PSA: Migration plan to GStreamer 1.x
>>> ( https://bugs.webkit.org/show_**bug.cgi?id=106085<https://bugs.webkit.org/show_bug.cgi?id=106085>)
>>> Now we have Debian Squeeze, Ubuntu 11.10 and 12.04 buildbots too, but
>>> installing GStreamer 1.0 to Debian Squeeze and Ubuntu 11.10 is a little
>>> bit complex. It is possible, but installing a meta package from a PPA
>>> on Ubuntu 12.04 is much more simpler.
>>> That's why I propose switching QtWebKit buildbots to Ubuntu 12.04 (LTS)
>>> and dropping trunk buildbot support for older distros. (Or should we
>>> upgrade to non-LTS, but newer Ubuntu 12.10? I haven't tested it yet.)
>>> Any opinions/objections?
>>> Question no 2:
>>> Which Qt version / revision should we use for WebKit trunk?
>>> We always use build-qt5.sh script to build Qt for WebKit trunk to reduce
>>> source incompatible changes and make it simple to have same environment
>>> to reproduce bugs, etc. ( https://github.com/ossy-**szeged/qt5-tools<https://github.com/ossy-szeged/qt5-tools>)
>>> But now we are pinned on a very old, pre Qt 5.0 revision:
>>> 8d77ff1ef2422259dd6baed5cae981**5260e5bee2 (Tue Dec 4 11:54:27 2012
>>> I think it's time to update Qt on the bots/developers machines.
>>> So the question is which Qt revision should we update to?
>>> - Qt 5.0.0 release version? (I tested it on Linux, and works fine)
>>> - Or trunk qt5.git? (I haven't tested it yet.)
>>> And then should we do regular weekly/mothly update again?
>>> Or should we do updates on demand only?
>>> webkit-qt mailing list
>>> webkit-qt at lists.webkit.org
>> webkit-qt mailing list
>> webkit-qt at lists.webkit.org
> Rafael Brandao @ INdT
> webkit-qt mailing list
> webkit-qt at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-qt