Hi
The patch below should fix it (there are arguably other perhaps better
ways to tackle the debugger dependency etc.).
With that patch, the linux shared make build compiles and links all
targets for me.
--Craig
diff --git a/chrome/chrome.gyp b/chrome/chrome.gyp
index 3fa1905..c0caeb6 100755
On Fri, Sep 25, 2009 at 10:21 AM, Jeremy Orlow jor...@chromium.org wrote:
On Fri, Sep 25, 2009 at 10:01 AM, Amanda Walker ama...@chromium.orgwrote:
On Tue, Sep 22, 2009 at 9:06 PM, Dimitri Glazkov dglaz...@google.comwrote:
This all means that we have to be a bit more diligent. We shouldn't
HI,
I want to explore Chromium's auto-testing mechanism, include: auto-
test, auto collect performance data. Can you provide me some document
about it? thanks!
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives,
Hi,
I tried to build chromium with toolkit_views=1 but got error when
executing following commands:
$ export GYP_DEFINES=toolkit_views=1
$ gclient runhooks --force
it complained: src/third_party/cros/cros_api.gyp not found. There is no cros
directory in my src/third_party, where can I get it?
On Mon, Oct 12, 2009 at 7:44 AM, Nicolas Sylvain nsylv...@chromium.org wrote:
On Sun, Oct 11, 2009 at 11:33 AM, Jeremy Orlow jor...@chromium.org wrote:
Is there documentation anywhere for all the parameters you can feed into
the buildbot webpage? If not, a cheat sheet would be really helpful.
The webkit api won't help if chromium folks (especially when you change v8
bindings) don't *run the layout tests *which is what happened yesterday and
causes quite a few of our worst problems while gardening.
If you're changing the v8 bindings, you're doing it to fix a problem in
chromium, so you
On Tue, Oct 13, 2009 at 8:09 AM, David Levin le...@google.com wrote:
The webkit api won't help if chromium folks (especially when you change v8
bindings) don't run the layout tests which is what happened yesterday and
causes quite a few of our worst problems while gardening.
I agree this is
On Tue, Oct 13, 2009 at 8:21 AM, Adam Barth aba...@chromium.org wrote:
On Tue, Oct 13, 2009 at 8:09 AM, David Levin le...@google.com wrote:
The webkit api won't help if chromium folks (especially when you change
v8
bindings) don't run the layout tests which is what happened yesterday and
On Tue, Oct 13, 2009 at 9:26 AM, Darin Fisher da...@chromium.org wrote:
On Tue, Oct 13, 2009 at 8:21 AM, Adam Barth aba...@chromium.org wrote:
On Tue, Oct 13, 2009 at 8:09 AM, David Levin le...@google.com wrote:
The webkit api won't help if chromium folks (especially when you change
v8
I think we need to change something. I am not sure what -- I have
ideas, but -- I would appreciate some collective thinking on this.
PROBLEM: We accumulate more test failures via WebKit rolls than we fix
with our LTTF effort. This ain't right.
ANALYSIS:
Ok, WebKit gardening is hard. So is
When I'm sheriffing, the vast majority of issues I see are flaky tests in
general rather than clear bustage from WebKit updates. Even if a particular
update causes flakiness, it can be hard to determine and fix.
In that sense, the highest priority IMO would be to eliminate flakiness,
which would
I don't think it's realistic to expect the gardener, or any one person, to
be able to fix an arbitrary broken layout test in a reasonable period of
time. That's certainly true for new tests, but even for regressions I often
can't even tell for sure whether our results are correct, much less what
Let's not conflate the two. There are flakes, and there are clearly,
consistently failing tests, arriving in chunks every day via WebKit
rolls.
:DG
On Tue, Oct 13, 2009 at 10:36 AM, Peter Kasting pkast...@google.com wrote:
When I'm sheriffing, the vast majority of issues I see are flaky tests
On Tue, Oct 13, 2009 at 10:43 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:
Let's not conflate the two. There are flakes, and there are clearly,
consistently failing tests, arriving in chunks every day via WebKit
rolls.
OK, I'm just saying that my observations are that the obvious,
I've been thinking quite a bit about this - I agree with Dmitri that the
current Sisyphean approach is unsustainable.
I don't think the right path is to ask the sheriffs to do the cleanup
themselves - for example, a webkit roll that breaks workers in some obscure
way is almost certainly beyond the
On Tue, Oct 13, 2009 at 10:45 AM, Peter Kasting pkast...@google.com wrote:
On Tue, Oct 13, 2009 at 10:43 AM, Dimitri Glazkov
dglaz...@chromium.orgwrote:
Let's not conflate the two. There are flakes, and there are clearly,
consistently failing tests, arriving in chunks every day via WebKit
A better solution would be to have the sheriff (or someone from LTTF)
assign the bugs to specific people
So how do you figure out who to assign it to?
with a general rule that such bugs must be fixed within two days (make
these bugs the top priority over other tasks).
Over security bugs?
Over
On Tue, Oct 13, 2009 at 11:17 AM, Nicolas Sylvain nsylv...@chromium.orgwrote:
It's because the sheriff don't notice the new failing tests, because most
of the time the gardener does a good job of updating the list at the same
time as the merge, so the tree stays mostly green.
See
On Tue, Oct 13, 2009 at 10:31 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
I think we need to change something. I am not sure what -- I have
ideas, but -- I would appreciate some collective thinking on this.
PROBLEM: We accumulate more test failures via WebKit rolls than we fix
with our
I agree with Dimitri that we're fighting a losing battle here.
In my last stint as gardener, I did informally what I proposed formally last
time: I spent basically 1 full day just triaging failures from my 2 days
gardening. Not fixing, but just running tests locally, analyzing, grouping,
We could rerun any unexpected fail/crash/timeout tests. If they pass the
second time around, then the tree turns orange instead of red. This has come
up many times, but we've never agreed on whether it's a good idea.
Pros:
-Easier to distinguish between flakiness and new failures
-Tree will be
We did this on my last project to deal with flaky test infrastructure. It
worked well in that test failures were pretty much guaranteed to be real (we
ran tests 3 times and only reported failure if a test failed all 3 times),
but it did definitely make us stop caring about flaky tests.
On Tue, Oct 13, 2009 at 1:00 PM, Julie Parent jpar...@chromium.org wrote:
We did this on my last project to deal with flaky test infrastructure. It
worked well in that test failures were pretty much guaranteed to be real (we
ran tests 3 times and only reported failure if a test failed all 3
I like the idea of ownership of groups of layout tests. Maybe these
directory owners could be more like the finders? An owner shouldn't
have to necessarily fix everything in a group/directory, but they should be
responsible for triaging and getting meaningful bugs filled for them, to
keep things
Hi all,
Someone from Mozilla is talking about their proposed new security
spec, CSP, today at Stanford.
I'm planning to go; was anyone else from MTV aware of this and hoping
to go? I can send out a summary of the talk afterwards if there's
interest.
https://wiki.mozilla.org/Security/CSP/Spec
On Tue, Oct 13, 2009 at 1:31 PM, Dirk Pranke dpra...@chromium.org wrote:
I have not heard of any discussion of this spec or if we plan to
implement it. Anyone have any thoughts?
We've mentioned implementing it in the past and Linus has been favorable. I
filed
On Tue, Oct 13, 2009 at 10:31 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
* [ your idea goes here ]
I'm probably going to get things thrown at me, but ...
I don't think the idea of a webkit sheriff really works. By definition
the webkit sheriff is pulling in code that they don't know how
On Tue, Oct 13, 2009 at 1:36 PM, Aaron Boodman a...@chromium.org wrote:
I'm probably going to get things thrown at me, but ...
Balls, I just checked with Dimitri and we already do my proposal.
Ignore.
- a
--~--~-~--~~~---~--~~
Chromium Developers mailing list:
On Tue, Oct 13, 2009 at 1:35 PM, Peter Kasting pkast...@google.com wrote:
On Tue, Oct 13, 2009 at 1:31 PM, Dirk Pranke dpra...@chromium.org wrote:
I have not heard of any discussion of this spec or if we plan to
implement it. Anyone have any thoughts?
We've mentioned implementing it in the
Based on the feedback, it sounds like we need to take the approach
with LTTF team adding more resources on cleaning up the bottom of the
test_expectations file (i.e. stuff recently added by the gardeners).
It is still the gardener's responsibility to take care of the
rebaselines, right? What
This might only apply to the media layout tests, but I'll give the heads up
anyway...
We found flakiness even when using load if the test is explicitly trying to
test for stalled/progress/abort events before the load is completed:
On Tue, Oct 13, 2009 at 3:50 PM, Andrew Scherkus scher...@chromium.orgwrote:
What's happening is loadstart fires and the video reloads which should
cause an abort event. For some reason load will occasionally fire after
loadstart, ending the test.
I know we can patch the test, but I've been
Both of these patches don't really have an obvious reviewer, but
they're pretty simple.
https://bugs.webkit.org/show_bug.cgi?id=30319
https://bugs.webkit.org/show_bug.cgi?id=30320
The latter one will require an epic amount of rebaselining, which I
have volunteered to do. If anyone has
I think ownership might actually help with flakiness.
Today, in order to distinguish flakiness from real bugs, the gardener needs
to have intimate knowledge of the relevant part of the code base and its
history. That is beyond the capabilities of the average webkit gardener.
Now, imagine a world
Be sheriff that day :)
Real advice:
Once you have webkit patch R+'ed and chrome rebaselines ready, let the
gardener know. Once the gardener is caught up, they can set commit-queue
flag on your change, so it gets committed at a time when they are ready to
deal with it and your follow up change
On Tue, Oct 13, 2009 at 3:46 PM, Dimitri Glazkov dglaz...@chromium.orgwrote:
Based on the feedback, it sounds like we need to take the approach
with LTTF team adding more resources on cleaning up the bottom of the
test_expectations file (i.e. stuff recently added by the gardeners).
It is
I glanced at the other one. there were a few issues with it:
1. It does more than it says. It changes how the horizontal lines are drawn
without explanation (nothing in the changelog and the bug only mentions the
other direction).
2. It uses a lot of magic numbers and the same ones repeatedly. It
3. It is unclear if there are any layout tests which cover this change.
I don't think layout tests can or should cover that change, except for pixel
tests, which will just need to be rebaselined.
--~--~-~--~~~---~--~~
Chromium Developers mailing list:
In r28924, I made a change to the new tab tests so it the data in the
history database would be recent. Because of this, the test now shows
8 most recently visited thumbnails when it was previously showing the
2 stock thumbnails. This causes a slight regression in the new tab
cold times, but
In my implementation for PlainTextController (see
http://codereview.chromium.org/243032) for the test shell I have run into
some issues for which I'm not sure what's the best way to address them.
Thusly I wanted to ask around if someone could give me some pointers:
.) The implementation of
Ownership is a great concept. I started out planning LTTF as
ownership-based. Unfortunately, the types of failures are scattered
far and wide across the directories, some clustered, some not. After a
few initial passes, I walked away thinking that it's not as simple as
drawing the lines and
If there are areas that nobody knows anything about, that's a lack that's
hobbling us. Suppose we take the entire list of directories, slap it into a
doc, and assign at least one owner to everything. For the areas that don't
yet have anyone knowledgeable, we take volunteers to *become*
42 matches
Mail list logo
