Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
Hi there,
On Tue, Apr 24, 2012 at 11:48 PM, Edward O'Connor eocon...@apple.com wrote:
Eric Seidel wrote:
Assuming I'm understanding Kalle correctly, it seems this could
already be accomplished with @media resolution?
http://www.w3.org/TR/css3-mediaqueries/#resolution
@media screen and (min-resolution: 264dpi) { … }
Which according to:
http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density
Would match both the new iPad and the iPhone 4.
As far as the resolution media query is concerned, the resolution of the
new iPad and the iPhone 4 (and anything else with a device-pixel-ratio
of 2) is exactly 192dpi.
This is because the CSS 'dpi' unit is defined to mean dots device pixels
per *CSS inch*, and CSS inches are hardcoded to be 96 CSS pixels.
This means that—without real physical units—the resolution media query
is always redundnant with device-pixel-ratio, which a) we already
implement, and b) is easier to explain to authors than explaining why
both the new iPad and the iPhone 4 are 192 dpi.
So the original iPhone has a dpi of 163, but it reported a CSS dpi of
96? meaning that in screen width it had around 3,3 CSS inches where as
the physical inches are more close to 1.96.
Why is this? Because the original iPhone reported an unchanged dpi of
96 even though it was in reality 163 and now everyone are depending on
that?
Kenneth
--
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone +45 4093 0598 / E-mail kenneth at webkit.org
http://codeposts.blogspot.com ﹆﹆﹆
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Feature Request: Dynamic Application Cache
Mozilla Firefox supports dynamic adding of resources into the application cache for offline use with the function: window.applicationCache.mozAdd(URI String) https://developer.mozilla.org/en/nsIDOMOfflineResourceList This is great for persistent storage of assets via javascipt. Instead of predefining those assets in the manifest file one can use javascript to cache the needed assets. Is there something similar planed? Like window.applicationCache.webkitAdd(URI String) ? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
On Wed, Apr 25, 2012 at 3:22 AM, Kenneth Rohde Christiansen kenneth.christian...@gmail.com wrote: So the original iPhone has a dpi of 163, but it reported a CSS dpi of 96? meaning that in screen width it had around 3,3 CSS inches where as the physical inches are more close to 1.96. Why is this? Because the original iPhone reported an unchanged dpi of 96 even though it was in reality 163 and now everyone are depending on that? CSS defines one inch = 96px, because doing otherwise broke content (even pre-iOS content). http://www.w3.org/TR/css3-values/#absolute-lengths ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Deprecating features guideline wiki
Hi WebKittens, following the talk about Deprecating (web-facing) features and vendor prefixing [1], we decided to create a guideline covering new deprecations or un-prefixing [2]. The rationale is that this will avoid a lot of the mistakes that we have made in the previous deprecations and that wisdom could help newcomers understand the pain points. The current page is a draft compiled from the meeting notes so any discussions or editions are welcome! Thanks, Julien [1] http://trac.webkit.org/wiki/Deprecating%20features%20and%20vendor%20prefixes [2] https://trac.webkit.org/wiki/DeprecatingFeatures ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
Assuming I'm understanding Kalle correctly, it seems this could already be accomplished with @media resolution? http://www.w3.org/TR/css3-mediaqueries/#resolution Not to be too cute about it, but CSS dpi is _always_ 96 CSS pixels per CSS inch. What this means onscreen is (almost) completely up to the user-agent. This is (potentially) why the resolution media query is defined (via the very link above) to only work for bitmap media types, not screen. Dealing with hardware that has a screen dpi much higher than what CSS prescribes for a device at its viewing distance (viewing distance matters: http://www.w3.org/TR/css3-values/#reference-pixel ) is a hard problem, and is one that is being discussed at length on the previously-mentioned threads and elsewhere. The iPhone seems to handle it by introducing a third type of pixels between hardware and CSS (a device/density-independent-pixel, or dip) that allows them to pretend that even the new iPhone has only 320px of width in portrait. BlackBerry has done other things at various times, currently taking advantage of dpi scaling (a little of which you can see in BlackBerry::WebKit::WebPagePrivate::recomputeVirtualViewportFromViewportArguments ). Android and Chrome-for-Android also have congruent practices, even exposing some of it to authors using target-densitydpi. Using HTML attributes and CSS properties to offload the effort of supporting multiple densities to the author from the user-agent might be the best way to solve this problem. I'm not as conversant in all the points as I feel I'd need to be to render a full opinion, but my uneducated opinion is that this sounds kinda hackish. Regardless, this indeed seems like it should be discussed by the standards bodies, not webkit-dev. Style, Chris H-C - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
Thanks Chris, I'll go bring it up on the relevant w3.org lists (I'm guessing I'll start on public-HTML-comments) and see where that takes me, after refining my idea a bit to use more conventional naming, and to hopefully account for other scales than 2x in an elegant manner. I just wanted to make sure no one here told me don't bother, we've got superior solution x in the works, or due to y, that's not gonna fly! Surely, 2x images can be implemented in a sane and efficient manner for web developers. -Tom On Apr 25, 2012, at 10:23 AM, Chris Hutten-Czapski chut...@rim.com wrote: Assuming I'm understanding Kalle correctly, it seems this could already be accomplished with @media resolution? http://www.w3.org/TR/css3-mediaqueries/#resolution Not to be too cute about it, but CSS dpi is _always_ 96 CSS pixels per CSS inch. What this means onscreen is (almost) completely up to the user-agent. This is (potentially) why the resolution media query is defined (via the very link above) to only work for bitmap media types, not screen. Dealing with hardware that has a screen dpi much higher than what CSS prescribes for a device at its viewing distance (viewing distance matters: http://www.w3.org/TR/css3-values/#reference-pixel ) is a hard problem, and is one that is being discussed at length on the previously-mentioned threads and elsewhere. The iPhone seems to handle it by introducing a third type of pixels between hardware and CSS (a device/density-independent-pixel, or dip) that allows them to pretend that even the new iPhone has only 320px of width in portrait. BlackBerry has done other things at various times, currently taking advantage of dpi scaling (a little of which you can see in BlackBerry::WebKit::WebPagePrivate::recomputeVirtualViewportFromViewportArguments ). Android and Chrome-for-Android also have congruent practices, even exposing some of it to authors using target-densitydpi. Using HTML attributes and CSS properties to offload the effort of supporting multiple densities to the author from the user-agent might be the best way to solve this problem. I'm not as conversant in all the points as I feel I'd need to be to render a full opinion, but my uneducated opinion is that this sounds kinda hackish. Regardless, this indeed seems like it should be discussed by the standards bodies, not webkit-dev. Style, Chris H-C - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] A plug for the Watch List
Are you an expert on FOO? Does your port need to know if BAR changes? Are you sick and tired of those insert company name here people breaking your favorite BAZ!?!? Add yourself to the watchlist: http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/watchlist Especially if you're a good reviewer for a specific file. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] A plug for the Watch List
As explained here: http://trac.webkit.org/wiki/WatchList The style-bot applies the watchlist regexps when it checks a patch, and will CC you at that time. On Wed, Apr 25, 2012 at 11:26 AM, Eric Seidel e...@webkit.org wrote: Are you an expert on FOO? Does your port need to know if BAR changes? Are you sick and tired of those insert company name here people breaking your favorite BAZ!?!? Add yourself to the watchlist: http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/config/watchlist Especially if you're a good reviewer for a specific file. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Bot watching and Apple bots
Hi everyone, A while back, Apple's WebKit teams instituted a bot watching rotation to try to get the bots for our ports to get and stay green. We've managed to consistently stay around low single digits of failures, but the green doesn't seem to stick. We think some folks in the community may have stopped paying attention to bots for Apple ports since they were poorly maintained for some time. We'd appreciate it if folks would pay attention to our core test and build bots when landing. Currently, our focus is on getting the following bots green. Once they are working well, we may expand to more: * Lion Intel Debug Build - http://build.webkit.org/builders/Lion%20Intel%20Debug%20%28Build%29 * Lion Intel Release Build - http://build.webkit.org/builders/Lion%20Intel%20Release%20%28Build%29 * Lion Intel Debug Tests - http://build.webkit.org/builders/Lion%20Intel%20Debug%20%28Tests%29 * Lion Intel Debug (WebKit2) Tests - http://build.webkit.org/builders/Lion%20Intel%20Debug%20%28WebKit2%20Tests%29 * Lion Intel Release Tests - http://build.webkit.org/builders/Lion%20Intel%20Release%20%28Tests%29 * Lion Intel Release (WebKit2) - Tests http://build.webkit.org/builders/Lion%20Intel%20Release%20%28WebKit2%20Tests%29 We'll also be posting the bot watchers on duty at any given time here: http://trac.webkit.org/wiki/Apple_Bot_Watchers You should feel free to contact them if you're experiencing problems or have caused a regression. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Double-Resolution (Retina) Images - Re: -webkit-image-set
On Wednesday 25 April 2012, Chris Hutten-Czapski wrote: Assuming I'm understanding Kalle correctly, it seems this could already be accomplished with @media resolution? http://www.w3.org/TR/css3-mediaqueries/#resolution Not to be too cute about it, but CSS dpi is _always_ 96 CSS pixels per CSS inch. Well always now, historically it has been different. Anyway to continue your description CSS pixels have usually been 1-1 with device pixels on the desktop, except for printing where CSS pixels were recalculated to a number of device pixels. In the printing sense there is there is nothing new in high DPI devices, the new devices are just the first interactive devices that end up using the printing tricks of large CSS pixels. This means we already have CSS and media query support for high DPI devices, but there are just only two meaningful DPIs on interactive devices: 96 or 192 (with 288 dpi reserved for future bling). Best regards `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Process for importing third party tests
On Mon, Apr 23, 2012 at 4:13 PM, Jacob Goldstein jac...@adobe.com wrote:
At the recent WebKit Contributors Meeting, a process was drafted for
importing third party tests into WebKit.
I created a wiki page that captures the process that we came up with here:
http://trac.webkit.org/wiki/ImportingThirdPartyTests
We'd like to get more input from the community on all aspects of this
process.
Please review and lets discuss further.
Hi Jacob,
I've only had a chance to glance over the document thus, but thanks
for writing it up!
Two initial comments:
1a. Import entire test suite(s) from W3C repository: pixel tests, ref tests,
manual tests, JS tests
You should probably change Import to download or something more
descriptive here, since the whole process is an import :)
1b. Run suite locally in WebKit directory
* Ref Tests
* Pass - good, submit it
* Fail - create a testName-expected-failure.txt file
We don't currently generate an -expected-failure.txt for reftests;
there's no concept of a baseline for a reftest at all.
Put differently, assuming the normal WebKit model of the baseline is
what we currently produce, we don't actually have a way of capturing
what do we current produce for a reference test.
I am also more than a little leery of mixing -expected.{txt,png}
results with -expected.html results; I feel like it would be very
confusing, and it would lose many of the advantages of reftests, since
we'd presumably have to update the reference every time as often as we
update pixel tests. [We could create a fake reftest that just
contained the 800x600 pixel dump, but I'm not sure if that's better or
not].
ii. DRT / Pixel tests
* Expectations: create render tree dumps for each test and use that output
as the new test expectation
* Potential regressions will be identified by changes to this output
* Proposal (open to discussion) - stop the production of .PNGs for these
imported tests
* PROS
* Avoid the increase to the overall size of the repository caused by
all the new PNGs
* Regressions will likely be caught by the render tree dumps
* Avoid maintenance of all associated PNGs
* CONS
* Regressions may be missed without the use of .PNGs
* May make test results harder to interpret
I'm not particularly a fan of this. I think each port should follow
its own convention for pixel tests or no. i.e., if Chromium normally
runs pixel tests, it should run all of these tests as pixel tests; if
Gtk doesn't, than they should just check the render trees here as
well.
Also, I was under the impression that (a) the W3C is mostly focused on
ref tests going forward and (b) we had agreed in that discussion that
we wouldn't import non-ref tests? Did something change in a discussion
after that session?
iii. JavaScript tests
* Pass - good, submit it (along with new expected.txt file - W3C does not
use an expected.txt file for JS tests)
* Fail - Add to test_expectations file to avoid failures
* Over time, individual can clean up failing JS tests
If they don't have expected.txt files, how is failure determined?
Why would we want to add failures to test_expectations.txt here but
not for pixel tests or reftests? If anything, these text-only tests
are *more* amenable to checking in the what we do now, even if it's
wrong expectation.
So, it seems like we have three different kinds of tests that you are
suggesting we treat three different ways. You can probably guess that
I don't like that :).
iv. Manual tests
* Submit in their current form
* Over time, convert to ref tests to be submitted back to W3C
I don't know what submit in their current form means ... doesn't
submitting have to do with exporting tests (i.e., importing into the
w3c repos), and we're talking about importing tests?
Are Manual tests somehow different from the other non-ref tests?
1. How should W3C tests that fail in WebKit be handled?
a. Failures should be checked in. Details in General Import Process above.
We discussed this in the session, but I don't see this in the notes; I
would really like for us to move to model in our repo where it's
possible to look at the filename for the baselines and determine
whether the baseline is believed to be correct, incorrect, or unknown,
in addition to capturing what we currently do (these are independent
axes).
This might be a separate discussion -- and of course there are
complications that arise with this -- but I would like to establish it
before we go to far down the import path ... in particular, I think it
will be difficult to convince the chromium devs to move fully off
their current model of checked in files are correct; if we currently
do something different, we suppress that.
2. Should a set frequency be used for importing tests?
a. No, frequency is up to the people who want to do this task.
I'm fine w/ this
3. Can the approval process for previously reviewed W3C tests be streamlined?
Re: [webkit-dev] Bot watching and Apple bots
Hi- This has been on my mind lately too, so I'm happy that you brought it up. I have a couple of questions: Would it be possible to make mac's ews warn about test failures in the same way that chromium-ews does? That's been super helpful for keeping Chromium green. Also, when you say pay attention, what level of involvement should we expect for one committer making the bots go red on a port that they are not primarily working on? Should we expect test expectation rebaselining? Patch reverting? Adding = FAIL test expectations and filing a bug? A friendly ping in irc? An apology and cupcakes? I'm just looking for some clarification on what the community expectations are with respect to paying attention to the bots of other ports. Regards, -enne El día 25 de abril de 2012 13:58, Maciej Stachowiak m...@apple.com escribió: Hi everyone, A while back, Apple's WebKit teams instituted a bot watching rotation to try to get the bots for our ports to get and stay green. We've managed to consistently stay around low single digits of failures, but the green doesn't seem to stick. We think some folks in the community may have stopped paying attention to bots for Apple ports since they were poorly maintained for some time. We'd appreciate it if folks would pay attention to our core test and build bots when landing. Currently, our focus is on getting the following bots green. Once they are working well, we may expand to more: * Lion Intel Debug Build - http://build.webkit.org/builders/Lion%20Intel%20Debug%20%28Build%29 * Lion Intel Release Build - http://build.webkit.org/builders/Lion%20Intel%20Release%20%28Build%29 * Lion Intel Debug Tests - http://build.webkit.org/builders/Lion%20Intel%20Debug%20%28Tests%29 * Lion Intel Debug (WebKit2) Tests - http://build.webkit.org/builders/Lion%20Intel%20Debug%20%28WebKit2%20Tests%29 * Lion Intel Release Tests - http://build.webkit.org/builders/Lion%20Intel%20Release%20%28Tests%29 * Lion Intel Release (WebKit2) - Tests http://build.webkit.org/builders/Lion%20Intel%20Release%20%28WebKit2%20Tests%29 We'll also be posting the bot watchers on duty at any given time here: http://trac.webkit.org/wiki/Apple_Bot_Watchers You should feel free to contact them if you're experiencing problems or have caused a regression. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bot watching and Apple bots
On Wed, Apr 25, 2012 at 2:34 PM, Adrienne Walker e...@google.com wrote: Also, when you say pay attention, what level of involvement should we expect for one committer making the bots go red on a port that they are not primarily working on? Should we expect test expectation rebaselining? Patch reverting? Adding = FAIL test expectations and filing a bug? A friendly ping in irc? An apology and cupcakes? FWIW, all contributors are expected NOT to regress ANY bots, and should put reasonable efforts into fixing build test failures after landing their patches. i.e. if any build bot fails due to someone's patch, they're expected to fix it. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bot watching and Apple bots
On Wed, Apr 25, 2012 at 2:40 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Apr 25, 2012 at 2:34 PM, Adrienne Walker e...@google.com wrote: Also, when you say pay attention, what level of involvement should we expect for one committer making the bots go red on a port that they are not primarily working on? Should we expect test expectation rebaselining? Patch reverting? Adding = FAIL test expectations and filing a bug? A friendly ping in irc? An apology and cupcakes? FWIW, all contributors are expected NOT to regress ANY bots, and should put reasonable efforts into fixing build test failures after landing their patches. i.e. if any build bot fails due to someone's patch, they're expected to fix it. Given that some people often land changes that break baselines on every bot, and that we clearly don't expect the patch submitter to fix every bot in this situation, how do you square that with what you just wrote? What's your definition of reasonable efforts? We did discuss this a fair amount at the committers meeting - see http://trac.webkit.org/wiki/April%202012%20Keeping%20the%20bots%20green . Given that some bots have very long cycle times, and that it's not yet practical to ensure every bot is green for your change prior to landing (we don't have full bot coverage in EWS nor a way to manage updating broken baselines), I don't think such a blanket statement is realistic. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bot watching and Apple bots
On Wed, Apr 25, 2012 at 2:51 PM, Dirk Pranke dpra...@chromium.org wrote: Given that some people often land changes that break baselines on every bot, and that we clearly don't expect the patch submitter to fix every bot in this situation, how do you square that with what you just wrote? What's your definition of reasonable efforts? We did discuss this a fair amount at the committers meeting - see http://trac.webkit.org/wiki/April%202012%20Keeping%20the%20bots%20green . Given that some bots have very long cycle times, and that it's not yet practical to ensure every bot is green for your change prior to landing (we don't have full bot coverage in EWS nor a way to manage updating broken baselines), I don't think such a blanket statement is realistic. However, that's the current policy as stated on: http://www.webkit.org/coding/contributing.html I'm all ears if we to change this behavior because I too think it doesn't reflect the current state of the world. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bot watching and Apple bots
Good to know. I had stopped paying attention to many of the Apple bots for the reason you mention. It would be really helpful if someone could make the webkit-patch tooling works correctly for the non-Chromium bots. Specifically, webkit-patch rebaseline-test and webkit-patch garden-o-matic. They are 99% of the way towards working for non-Chromium bots and just need a handful of small fixes. I've outlined what the necessary work at https://bugs.webkit.org/show_bug.cgi?id=82719. I'd be happy to walk someone through any of this. Ojan On Wed, Apr 25, 2012 at 1:58 PM, Maciej Stachowiak m...@apple.com wrote: Hi everyone, A while back, Apple's WebKit teams instituted a bot watching rotation to try to get the bots for our ports to get and stay green. We've managed to consistently stay around low single digits of failures, but the green doesn't seem to stick. We think some folks in the community may have stopped paying attention to bots for Apple ports since they were poorly maintained for some time. We'd appreciate it if folks would pay attention to our core test and build bots when landing. Currently, our focus is on getting the following bots green. Once they are working well, we may expand to more: * Lion Intel Debug Build - http://build.webkit.org/builders/Lion%20Intel%20Debug%20%28Build%29 * Lion Intel Release Build - http://build.webkit.org/builders/Lion%20Intel%20Release%20%28Build%29 * Lion Intel Debug Tests - http://build.webkit.org/builders/Lion%20Intel%20Debug%20%28Tests%29 * Lion Intel Debug (WebKit2) Tests - http://build.webkit.org/builders/Lion%20Intel%20Debug%20%28WebKit2%20Tests%29 * Lion Intel Release Tests - http://build.webkit.org/builders/Lion%20Intel%20Release%20%28Tests%29 * Lion Intel Release (WebKit2) - Tests http://build.webkit.org/builders/Lion%20Intel%20Release%20%28WebKit2%20Tests%29 We'll also be posting the bot watchers on duty at any given time here: http://trac.webkit.org/wiki/Apple_Bot_Watchers You should feel free to contact them if you're experiencing problems or have caused a regression. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bot watching and Apple bots
On Wed, Apr 25, 2012 at 3:50 PM, Ojan Vafai o...@chromium.org wrote: Good to know. I had stopped paying attention to many of the Apple bots for the reason you mention. It would be really helpful if someone could make the webkit-patch tooling works correctly for the non-Chromium bots. Specifically, webkit-patch rebaseline-test and webkit-patch garden-o-matic. They are 99% of the way towards working for non-Chromium bots and just need a handful of small fixes. I've outlined what the necessary work at https://bugs.webkit.org/show_bug.cgi?id=82719. I'd be happy to walk someone through any of this. Much of this was discussed in the keeping the bots green session, and we've gradually been filing bugs for some of these enhancements as well. See in particular: https://bugs.webkit.org/show_bug.cgi?id=84642 https://bugs.webkit.org/show_bug.cgi?id=84643 -- Dirk Ojan On Wed, Apr 25, 2012 at 1:58 PM, Maciej Stachowiak m...@apple.com wrote: Hi everyone, A while back, Apple's WebKit teams instituted a bot watching rotation to try to get the bots for our ports to get and stay green. We've managed to consistently stay around low single digits of failures, but the green doesn't seem to stick. We think some folks in the community may have stopped paying attention to bots for Apple ports since they were poorly maintained for some time. We'd appreciate it if folks would pay attention to our core test and build bots when landing. Currently, our focus is on getting the following bots green. Once they are working well, we may expand to more: * Lion Intel Debug Build - http://build.webkit.org/builders/Lion%20Intel%20Debug%20%28Build%29 * Lion Intel Release Build - http://build.webkit.org/builders/Lion%20Intel%20Release%20%28Build%29 * Lion Intel Debug Tests - http://build.webkit.org/builders/Lion%20Intel%20Debug%20%28Tests%29 * Lion Intel Debug (WebKit2) Tests - http://build.webkit.org/builders/Lion%20Intel%20Debug%20%28WebKit2%20Tests%29 * Lion Intel Release Tests - http://build.webkit.org/builders/Lion%20Intel%20Release%20%28Tests%29 * Lion Intel Release (WebKit2) - Tests http://build.webkit.org/builders/Lion%20Intel%20Release%20%28WebKit2%20Tests%29 We'll also be posting the bot watchers on duty at any given time here: http://trac.webkit.org/wiki/Apple_Bot_Watchers You should feel free to contact them if you're experiencing problems or have caused a regression. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
