WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED INVALID
70236
[Qt][WK2][meta] Fix failing API tests
https://bugs.webkit.org/show_bug.cgi?id=70236
Summary
[Qt][WK2][meta] Fix failing API tests
Csaba Osztrogonác
Reported
2011-10-17 07:27:13 PDT
It is a meta bug for fixing failing API tests.
Attachments
Patch
(1.49 KB, patch)
2011-10-17 08:21 PDT
,
Alexis Menard (darktears)
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Alexis Menard (darktears)
Comment 1
2011-10-17 08:21:51 PDT
Created
attachment 111267
[details]
Patch
WebKit Review Bot
Comment 2
2011-10-17 08:26:16 PDT
Attachment 111267
[details]
did not pass style-queue: Failed to run "['Tools/Scripts/update-webkit', '--chromium']" exit_code: 2 Updating OpenSource Current branch master is up to date. Updating chromium port dependencies using gclient... Error: Can't switch the checkout to
http://v8.googlecode.com/svn/branches/3.6@9637
; UUID don't match and there is local changes in /mnt/git/webkit-style-queue/Source/WebKit/chromium/v8. Delete the directory and try again. Re-trying 'depot_tools/gclient sync' Error: Can't switch the checkout to
http://v8.googlecode.com/svn/branches/3.6@9637
; UUID don't match and there is local changes in /mnt/git/webkit-style-queue/Source/WebKit/chromium/v8. Delete the directory and try again. Re-trying 'depot_tools/gclient sync' Error: Can't switch the checkout to
http://v8.googlecode.com/svn/branches/3.6@9637
; UUID don't match and there is local changes in /mnt/git/webkit-style-queue/Source/WebKit/chromium/v8. Delete the directory and try again. Error: 'depot_tools/gclient sync' failed 3 tries and returned 256 at Tools/Scripts/update-webkit-chromium line 107. Re-trying 'depot_tools/gclient sync' No such file or directory at Tools/Scripts/update-webkit line 104. If any of these errors are false positives, please file a bug against check-webkit-style.
Csaba Osztrogonác
Comment 3
2011-10-17 08:28:00 PDT
Comment on
attachment 111267
[details]
Patch Clearing flags on attachment: 111267 Committed
r97623
: <
http://trac.webkit.org/changeset/97623
>
Csaba Osztrogonác
Comment 4
2011-10-17 08:28:07 PDT
All reviewed patches have been landed. Closing bug.
Csaba Osztrogonác
Comment 5
2011-10-17 08:28:49 PDT
.
Csaba Osztrogonác
Comment 6
2011-10-26 09:54:55 PDT
There are too many failing API tests for long time, so API tests aren't ready for making the bot red if a test fails. From now a failing API test doesn't make the WK2 bot red, but its build step is orange.
Alexis Menard (darktears)
Comment 7
2011-10-26 10:20:21 PDT
(In reply to
comment #6
)
> There are too many failing API tests for long time, so API tests aren't ready for making the bot red if a test fails. From now a failing API test doesn't make the WK2 bot red, but its build step is orange.
NOOOOO please.... It's a real issue. Almost all the QtWebKit community is in dev days so we don't have time to look at it *right now*. But we will. Let's not go back to the past and let it broken. Any API breakage is as important as LayoutTests breakage. By any chance did you catch the faulty revision or the import of Qt5 that it broke? I recall they were properly green last week.
Csaba Osztrogonác
Comment 8
2011-11-01 13:08:30 PDT
(In reply to
comment #7
)
> (In reply to
comment #6
) > > There are too many failing API tests for long time, so API tests aren't ready for making the bot red if a test fails. From now a failing API test doesn't make the WK2 bot red, but its build step is orange. > > NOOOOO please.... > > It's a real issue. Almost all the QtWebKit community is in dev days so we don't have time to look at it *right now*. But we will. Let's not go back to the past and let it broken. Any API breakage is as important as LayoutTests breakage. > > By any chance did you catch the faulty revision or the import of Qt5 that it broke? I recall they were properly green last week.
There are 10 failing API tests now, I filed bug reports for all fails which block this bug. I don't think if always red bot is a good idea. Always red bot _can't_ get regressions and _can't_ send email if there is a new regression. We can catch new regressions easily if the bot is green almost always. In this case the green/red change means a possible new regression. I can't fix failing API tests myself, but API maintainer can.
Alexis Menard (darktears)
Comment 9
2011-11-01 13:58:40 PDT
(In reply to
comment #8
)
> (In reply to
comment #7
) > > (In reply to
comment #6
) > > > There are too many failing API tests for long time, so API tests aren't ready for making the bot red if a test fails. From now a failing API test doesn't make the WK2 bot red, but its build step is orange. > > > > NOOOOO please.... > > > > It's a real issue. Almost all the QtWebKit community is in dev days so we don't have time to look at it *right now*. But we will. Let's not go back to the past and let it broken. Any API breakage is as important as LayoutTests breakage. > > > > By any chance did you catch the faulty revision or the import of Qt5 that it broke? I recall they were properly green last week. > > There are 10 failing API tests now, I filed bug reports for all fails which block this bug. I don't think if always red bot is a good idea. Always red bot _can't_ get regressions and _can't_ send email if there is a new regression. We can catch new regressions easily if the bot is green almost always. In this case the green/red change means a possible new regression. I can't fix failing API tests myself, but API maintainer can.
But szeged build bots doesn't send email/add comments on bugs even if you are the first guilty revision and I think that's the problem. Of course I do see why it doesn't do it because our bots there are not that stable or not meant to be used by other contributors. But would it be possible that they comment on bugs that matters for QtWebKit like the ones with [Qt] because today people don't care about API tests because they don't get warn on their original bug id. At least the WK2 could do so that would force people to care about them. It seems that except FAIL! : qmltests::DesktopWebViewNavigationPolicyForUrl::test_ignorePolicy() window not shown they seems to be easily fixable. The latter seems to be a race triggered in V8 with a recent change. Hopefully we can get that fixed in the next Qt update.
Jesus Sanchez-Palencia
Comment 10
2011-11-11 21:23:14 PST
Alexis, all the API tests are currently passing, right?!
Csaba Osztrogonác
Comment 11
2011-11-17 08:00:31 PST
The answer was yes, but now we have 2 new fails:
https://bugs.webkit.org/show_bug.cgi?id=72612
Csaba Osztrogonác
Comment 12
2011-11-17 08:12:30 PST
(In reply to
comment #9
)
> But szeged build bots doesn't send email/add comments on bugs even if you are the first guilty revision and I think that's the problem. Of course I do see why it doesn't do it because our bots there are not that stable or not meant to be used by other contributors. But would it be possible that they comment on bugs that matters for QtWebKit like the ones with [Qt] because today people don't care about API tests because they don't get warn on their original bug id. At least the WK2 could do so that would force people to care about them.
I remember that sheriffbot commented bugs regularly if somebody caused a regression. But it was disabled, because folks didn't want to get SPAM. Buildbot on its own can't send e-mails if a commit increases the number of failing layout or API tests. Buildbot can send e-mail when its color changes from green to red. (or from all red revision) Of course it is possible to implement a sophisticated script which polls buildbot page regularly, parse its output, find who break which layout or API tests and send e-mail if the bug title has [Qt] prefix, etc. Is there any volunteer for it?
Alexis Menard (darktears)
Comment 13
2011-11-22 06:19:24 PST
(In reply to
comment #12
)
> (In reply to
comment #9
) > > But szeged build bots doesn't send email/add comments on bugs even if you are the first guilty revision and I think that's the problem. Of course I do see why it doesn't do it because our bots there are not that stable or not meant to be used by other contributors. But would it be possible that they comment on bugs that matters for QtWebKit like the ones with [Qt] because today people don't care about API tests because they don't get warn on their original bug id. At least the WK2 could do so that would force people to care about them. > > I remember that sheriffbot commented bugs regularly if somebody caused a regression. But it was disabled, because folks didn't want to get SPAM. > Buildbot on its own can't send e-mails if a commit increases the number of > failing layout or API tests. Buildbot can send e-mail when its color changes > from green to red. (or from all red revision) > > Of course it is possible to implement a sophisticated script which polls buildbot page regularly, parse its output, find who break which layout or API tests and send e-mail if the bug title has [Qt] prefix, etc. Is there any volunteer for it?
All green now.
Jocelyn Turcotte
Comment 14
2014-02-03 03:19:04 PST
=== Bulk closing of Qt bugs === If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary. If you believe that this is still an important QtWebKit bug, please fill a new report at
https://bugreports.qt-project.org
and add a link to this issue. See
http://qt-project.org/wiki/ReportingBugsInQt
for additional guidelines.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug