We can live in one of two worlds:
1) LayoutTests that concern themselves with specific network/loading
concerns need to use unique URLs to refer to static data; or
2) DRT clears JS-visible state between tests.
The pros/cons seem clear to me:
Pro#1: loading/caching code is coincidentally
There are lot of things remaining in the process across tests runs
What things remain in the process across test runs that are visible to
DRT/JS?
As I've said before in this thread, it seems axiomatic to me that tests can
only be reasoned about if they run in a pristine environment. This is
This thread stalled out because although there seemed to be majority
agreement that hermetic/repeatable tests are a good thing, there was a
requirement that all ports be updated to the new behavior at the same time,
and I'm only competent to do the chromium DRT (see
On Fri, Oct 26, 2012 at 1:44 AM, Antti Koivisto koivi...@iki.fi wrote:
Cache has subtle interactions with other things being tested
(-flakiness). More explicit cache tests would be nice but we can't hope
the replicate all the accidental testing we now get. We are going to lose a
large chunk
On Fri, Oct 26, 2012 at 11:17 AM, Ryosuke Niwa rn...@webkit.org wrote:
I agree this is a good change but it appears that we should add more
cache/loader tests before changing DRT's behavior given that there are
active contributors who rely on the current DRT behaviors to detect
regressions.
Should we add random sleeps to DRT? It'll certainly help find some
regressions (and even security bugs).
Of course the down-side is that it makes tests non-repeatable and difficult
to reason about.
I'm baffled by your priorities and don't know how to continue this
conversation productively.
On Fri, Oct 26, 2012 at 2:11 PM, Ryosuke Niwa rn...@webkit.org wrote:
Is there any reason we can’t wait for another couple of weeks or months
until we add more loader cache tests before making the behavior change?
There is no time pressure here other than a desire to avoid this falling
Bugzilla sends a notification email when one is add to the CC list of a bug.
IWBN if that email would include the state of the bug so far.
My experience with a few weeks' worth of being on a watchlist is that the
resulting email threads tend to miss the most important information of the
speak up before then.
Cheers,
-a
On Sun, Mar 11, 2012 at 3:02 AM, Hajime Morrita morr...@chromium.orgwrote:
(From the right address again...)
On Sun, Mar 11, 2012 at 9:34 AM, Alp Toker a...@nuanti.com wrote:
On 09/03/2012 03:52, Ami Fischman wrote:
Hi webkittens,
The over-all question
Responding to several emails below.
Adam wrote:
I'm not sure I understand your proposal fully. Specifically, how would
these macros work for, say, the Chromium, Apple-Mac, and Apple-Win ports,
which export overlapping, but not identical, sets of symbols?
I do not have a proposal to unify
?
--
morrita
On Mon, Mar 12, 2012 at 9:16 AM, Ami Fischman fisch...@chromium.org
wrote:
Responding to several emails below.
Adam wrote:
I'm not sure I understand your proposal fully. Specifically, how would
these macros work for, say, the Chromium, Apple-Mac, and Apple-Win
ports,
which
Thanks for your reply, Morrita!
For ports on approach C, it doesn't matter which WebCore/JSC API is
used from WebKit API layer because they are built in the same library.
If you mean that nothing in WebCore/JSC needs to be annotated as exported
then I don't think that's right, because
12 matches
Mail list logo
