Re: [webkit-dev] Proposal: Make Ninja the default build-system for build-webkit --chromium
On Tue, Jan 22, 2013 at 2:22 AM, Nico Weber tha...@chromium.org wrote: On Sat, Jan 12, 2013 at 9:49 PM, Nico Weber tha...@chromium.org wrote: On Tue, Dec 11, 2012 at 3:43 PM, Eric Seidel e...@webkit.org wrote: Nevermind. After further discussion with Nico, this can't work yet. Ninja is currently configured to use a non-webkitty out build directory, which is undoubtably going to confus some scripts/bots. We'll try this again at a later time. Apologies for the noise. If you build WebKit/chromium on Linux (i.e. Chromium/Linux and Chromium/Android), you're now using ninja. The Chromium Linux Release and Chromium Android Release build bots seem to be working fine. Admire the exciting build output: http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/65467/steps/compile-webkit/logs/stdio Let us know if anything is not working for you. (If you must use make, you can pass --no-ninja to update-webkit, and build-webkit will use make again. If you do this, please let me know why.) Chromium/Mac webkit builds now uses ninja by default too. The bot's build output is now a little more concise: http://build.webkit.org/builders/Chromium%20Mac%20Release/builds/53889/steps/compile-webkit/logs/stdio On my laptop, full builds are 10% faster and empty builds (the minimum time you need to wait for a build) are 30x as fast. If you still need xcodebuild, you can pass --no-ninja to update-webkit. Please let us know if and why you do this. Nico ps: Switching Chromium/Windows is blocked on http://crbug.com/169945, so it probably won't happen soon. …and windows is now done, too. Thanks to dpranke for helping with this! ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Best practices for landing new/changed layout test expectations?
On Tue, Feb 26, 2013 at 1:55 AM, Tom Hudson tomhud...@google.com wrote: On Mon, Feb 25, 2013 at 10:34 PM, Ryosuke Niwa rn...@webkit.org wrote: It should be fairly straight forward to create a tool that analyzes files changed in each commit and deduce which tests' expected results have been changed. The tool can then fetch results from each port' bot for those tests and automatically land them. It can then comment on the bug automatically about these rebaseline commits. There is no need to add remove entries from TestExpectation files. I think it's implied in other messages in the thread, but just to be explicit: this automated rebaseline commit feels like exactly the wrong thing to do. How can you rebaseline a test without SOME manual inspection? I know that mass layout rebaselines may not have every pixel checked, but there's tooling to help with that. Changes that are benign in one port may not be benign in other ports. Automatically landing changes to other ports' baselines risks corrupting our test data. I hate to repeat myself every time this conversation comes up but here it is: historically, only Chromium port used expected results as correct results and non-Chromium ports used expected results files to store the current state of the world including expected failures although this may have changed a little since non-Chromium ports started using TestExpectations instead of Skipped files. There is a significant danger in adding test expectations as opposed to committing expected failures because tests with Failure or ImageOnlyFailure expectation can regress further in any minute. I've encountered several severe regressions that would have caught if relevant tests had not been marked Failure or ImageOnlyFailure (in some cases needing rebaselines) for some minor rendering issues in the past. So no, it's not exactly the wrong thing to do. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] big .asc file for 1.10.2
Why is the .asc file for webkit.org/releases/webkitgtk-1.10.2.tar.xz so big? ... webkitgtk-1.10.2.tar.xz 12-Dec-2012 18:01 8.2M webkitgtk-1.10.2.tar.xz.asc 12-Dec-2012 18:01 8.2M ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] big .asc file for 1.10.2
On Tue, Feb 26, 2013 at 8:43 AM, jepusgf...@snkmail.com wrote: Why is the .asc file for webkit.org/releases/webkitgtk-1.10.2.tar.xz so big? ... webkitgtk-1.10.2.tar.xz 12-Dec-2012 18:01 8.2M webkitgtk-1.10.2.tar.xz.asc 12-Dec-2012 18:01 8.2M Thanks for reporting this. It should be fixed now. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Possibilities to use border css property on image map...
On Feb 25, 2013, at 11:26 PM, Arunprasad Rajkumar ararunpra...@gmail.com
wrote:
So I tried using :focus { border:5px solid red; }. But it is not working in
WebKit based browsers. But border property works well for all other
elements(a,div,span,p,..) but not with area.
Thanks fore the bug report. However, mail to this mailing list is not the
correct way to report a bug.
The right way to do that is to use http://bugs.webkit.org to file a bug report.
Please do that.
Other information about how to correctly keep in touch with the people working
on WebKit is on the contact page at http://www.webkit.org/contact.html with
information about the mailing lists and more.
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Best practices for landing new/changed layout test expectations?
On Tue, Feb 26, 2013 at 12:47 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Feb 26, 2013 at 2:11 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 26, 2013 at 1:55 AM, Tom Hudson tomhud...@google.com wrote: On Mon, Feb 25, 2013 at 10:34 PM, Ryosuke Niwa rn...@webkit.org wrote: It should be fairly straight forward to create a tool that analyzes files changed in each commit and deduce which tests' expected results have been changed. The tool can then fetch results from each port' bot for those tests and automatically land them. It can then comment on the bug automatically about these rebaseline commits. There is no need to add remove entries from TestExpectation files. Wait, what? For some reason neither I nor the mailing list archives got your initial message, nor Silvia or Tom's responses, nor your responses (at least as of the time of me writing this), so I feel like I've missed a radical shift in this thread, and maybe I missed some of the context. https://lists.webkit.org/pipermail/webkit-dev/2013-February/023967.html You're proposing that we automatically land updated baselines without review and then somehow update bugs, have people go back and look at the updated bugs to see if the baseline changes represent actual regressions or just expected changes? Right. Given that the commit already contains information as to which tests have been rebaselined, a script should be able to fetch new baselines for those affected tests on each platform and land them or upload as patches as needed. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Best practices for landing new/changed layout test expectations?
Hi, Ryosuke Niwa írta: (snip) I don't like the idea that now I have to either use this tool or manually read through TestExpectations to find tests that need rebaseline. It's also annoying if we had all contributors add new lines to TestExpectations because those changes will almost always conflict when applying patches. In general, I don't like any solution that requires modifying TestExpectations files a lot. It's unneeded svn churn. It should be fairly straight forward to create a tool that analyzes files changed in each commit and deduce which tests' expected results have been changed. The tool can then fetch results from each port' bot for those tests and automatically land them. It can then comment on the bug automatically about these rebaseline commits. There is no need to add remove entries from TestExpectation files. I like your idea about the new tool with some little improvement. In my mind I see an improved EWS which analyzes the uploaded patch, determine which expected files are touched (assuming that the author updated the expected files at least on one platform). And then the EWS can run only these tests on its own platform and upload the result to bugzilla. It is much more cheaper than run all tests on all patches. That's why only Chromium and Apple Mac EWS run test ... And to tell the truth the waiting time is huge sometimes. This run tests on demand only can be a good compromise for ports don't have 8x8 cores EWS machine. I'm a little bit sceptic about automatical rebase commits. I prefer only uploading the new results to the bugzilla. And then the author and/or the port maintainer/gardener can review if the new results are correct or not. And then they can integrate the new baselines with the original patch (with a tool, of course) and land as one commit. (Or try one more round on EWS if the results are too old.) But unfortunately sometimes/regularly folks review and commit faster than style checker bot run. :) In this case we might need one more tool to check the bots automatically and help the gardeners work to be able rebase in one patch instead of separated patches for each port. br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Best practices for landing new/changed layout test expectations?
On Tue, Feb 26, 2013 at 1:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 26, 2013 at 12:47 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Feb 26, 2013 at 2:11 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 26, 2013 at 1:55 AM, Tom Hudson tomhud...@google.com wrote: On Mon, Feb 25, 2013 at 10:34 PM, Ryosuke Niwa rn...@webkit.org wrote: It should be fairly straight forward to create a tool that analyzes files changed in each commit and deduce which tests' expected results have been changed. The tool can then fetch results from each port' bot for those tests and automatically land them. It can then comment on the bug automatically about these rebaseline commits. There is no need to add remove entries from TestExpectation files. Wait, what? For some reason neither I nor the mailing list archives got your initial message, nor Silvia or Tom's responses, nor your responses (at least as of the time of me writing this), so I feel like I've missed a radical shift in this thread, and maybe I missed some of the context. https://lists.webkit.org/pipermail/webkit-dev/2013-February/023967.html This link doesn't point to any of those messages, but perhaps it's not that important. You're proposing that we automatically land updated baselines without review and then somehow update bugs, have people go back and look at the updated bugs to see if the baseline changes represent actual regressions or just expected changes? Right. Given that the commit already contains information as to which tests have been rebaselined, a script should be able to fetch new baselines for those affected tests on each platform and land them or upload as patches as needed. It's possible that we could fetch and cluster new baselines based on what changed in the initial commit. I would be concerned that there could be a fair amount of noise in either direction (tests that changed on the initial platform didn't on others, and others did), and you'd also have to figure out how to cluster changes since most builds on the bots contain multiple changes. But, you could probably use some of garden-o-matic's results to help here. That said, I'm not sure this workflow would actually improve things much over garden-o-matic. I am quite a bit more reluctant to automatically land any such changes; it seems like it would be hard if not impossible to tell (programmatically) whether a baseline changed as expected or if it represented a regression. If we were to work on new tooling, I would be much more in favor of pushing this up to an EWS-time step like Ossy suggests. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Possibilities to use border css property on image map...
Hi Darin,
Thanks for your response. I will file a bug. Just wanted to ensure whether
it is a real bug or not. From next time can I post it to webkit-help to
ensure the bug?
I filed in webkit bugzilla. https://bugs.webkit.org/show_bug.cgi?id=110940
Kind Regards,
Arun
On 26 February 2013 22:30, Darin Adler da...@apple.com wrote:
On Feb 25, 2013, at 11:26 PM, Arunprasad Rajkumar ararunpra...@gmail.com
wrote:
So I tried using :focus { border:5px solid red; }. But it is not working
in WebKit based browsers. But border property works well for all other
elements(a,div,span,p,..) but not with area.
Thanks fore the bug report. However, mail to this mailing list is not the
correct way to report a bug.
The right way to do that is to use http://bugs.webkit.org to file a bug
report. Please do that.
Other information about how to correctly keep in touch with the people
working on WebKit is on the contact page at
http://www.webkit.org/contact.html with information about the mailing
lists and more.
-- Darin
--
*Arunprasad Rajkumar*
http://in.linkedin.com/in/ararunprasad
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
