after first access, so the order in which
they're accessed can change what code path is used to create them and
expose bugs like this where PASS messages turn into FAILs because the
binding was not created with the right global object pointer.
On Wed, Feb 24, 2010 at 3:50 PM, Eric Seidel e
On Tue, Feb 23, 2010 at 2:19 PM, Darin Adler da...@apple.com wrote:
But in practice pixel results are often ignored entirely. I think that
reftest-style tests if done right could be a great addition.
Pixel tests are run for every build by chromium, and regressions
tracked there. :)
Also,
Welcome to WebKit!
I have a few questions (and I assume others are curious to the answers as well):
- Who maintains this port? (Samsung I assume.)
- Is this an active port? (Are there plans for the EFL contributors to
work upstream?)
- Does the EFL port have a DumpRenderTree implementation?
Chromium's faster, multi-threaded, python-based testing harness landed
in svn.webkit.org about a week ago.
On my 4 core work machine it runs all the tests in 5 minutes vs. 8
minutes with run-webkit-tests. On Dirk's 16 core machine it runs all
the tests in 2minutes.
HUGE thanks to Dirk Pranke
ASSERTION FAILED: malloc_size(p)
(/Volumes/Big/WebKit-BuildSlave/leopard-intel-debug/build/WebKitBuild/Debug/JavaScriptCore.framework/PrivateHeaders/ValueCheck.h:52
static void WTF::ValueCheckP*::checkConsistency(const P*) [with P =
WebCore::AtomicStringImpl])
:16 PM, Eric Seidel e...@webkit.org wrote:
ASSERTION FAILED: malloc_size(p)
(/Volumes/Big/WebKit-BuildSlave/leopard-intel-debug/build/WebKitBuild/Debug/JavaScriptCore.framework/PrivateHeaders/ValueCheck.h:52
static void WTF::ValueCheckP*::checkConsistency(const P*) [with P =
WebCore
I don't know if LaunchServices maintains this information, but if it
does, you can reset the launch services database via:
/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister
-eric
On Wed, Feb 10, 2010 at 6:35 PM, Dirk Pranke
In an effort to clean out the list of to-be-committed patches
(http://webkit.org/pending-commit) I wrote a small command for
webkit-patch to clear r+ flags on obsolete attachments and ran it this
afternoon. My apologies to those of you who received a bunch of bug
mail as a result.
I tried for a
Historically build.webkit.org would email people when their changes
broke the tree. This was disabled some time ago.
I would very much like to see it re-enabled. Could someone point me
as to how that would happen (I'm happy to code up a patch), or flip
the magical switch themselves?
-eric
Definitely a bug.
Some of these are on file, some are not:
http://webkit.org/quality/reporting.html
-eric
On Tue, Feb 2, 2010 at 8:17 AM, Leif Arne Storset lstor...@opera.com wrote:
Hello,
While doing some SVG-related work over here I discovered that WebKit's
rendering of SVG in img tags
We hit over 100 again today. :( I just went through the whole queue
again and we're back to 80, but many of them I can't review myself.
Any help is most appreciated.
-eric
On Tue, Jan 26, 2010 at 3:10 PM, Eric Seidel e...@webkit.org wrote:
https://bugs.webkit.org/buglist.cgi?field0-0-0
If you're wondering why your cq+'d patch hasn't landed, it's because
we're behind again. 21 patches in the queue. Again, mostly due to
the tree being red for an extended period this weekend (and today).
The queue should catch up over night.
-eric
On Wed, Jan 27, 2010 at 1:31 PM, Eric Seidel e
The tree was torched again this evening. :( The builders got way way
way behind. I cleared the slow ones just now. I expect them to roll
green and the commit-bot to start landing while we sleep. :)
-eric
On Tue, Jan 26, 2010 at 5:55 PM, Eric Seidel e...@webkit.org wrote:
Sorry, the commit
The commit queue caught up over night, and is operating normally
again. (aka if build.webkit.org is green, then your patch should be
landed within 15 minutes of setting cq+)
Thanks for your patience.
-eric
On Wed, Jan 27, 2010 at 3:12 AM, Eric Seidel e...@webkit.org wrote:
The tree
Soon after that I wrote bugzilla-tool (now called webkit-patch). Adam
Barth and I learned that webkit-patch made it easy to just save
patches to bugs, using post and apply-attachment. That was easier
than bothering with branches in many cases (at least branches
containing ChangeLogs).
It's even
https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.nametype0-0-0=equalsvalue0-0-0=review%3F
There are 30 bugs fewer than when I started an epic review-them-all
two hours ago, but we still need more help!
71 patches up for review. Please knock a few off the list. An r-
with comments is
Sorry, the commit-queue got behind today (currently 19 patches in the
queue) due to the bots being red much of the day and whole bunch of
reviewing. :)
http://build.webkit.org/console
It should catch up over night.
Thanks for your patience.
-eric
___
It seems one way to more-quickly solve these sorts of fires would be
to turn back on the buildbot blame mails. We used to have them years
ago, and somewhere along the line they got turned off.
I looked briefly at how to make the changes to:
I filed a bug about turning back on blame-mails:
https://bugs.webkit.org/show_bug.cgi?id=34075
Further discussion specific to the mails can be held there.
On Mon, Jan 25, 2010 at 12:50 AM, Eric Seidel e...@webkit.org wrote:
It seems one way to more-quickly solve these sorts of fires would
Looking at the old page, it is not an accurate source of chronology
information. :) However such is easy to gather from svn/git.
I wrote a script a while ago which shows you the latest commit by
everyone, but it would be about 2 lines of code change to make it show
you the first commit instead:
I support not inventing a new style and making the global python style
(PEP8) WebKit's official python style (it's been our defacto style for
a while).
We need to update the coding-style.html page to note this.
On Fri, Jan 22, 2010 at 12:33 PM, Adam Barth aba...@webkit.org wrote:
If you don't
.
This situation is interesting because BREW and BREW MP shares most of the
API. I should change the official port name to BREW MP.
[2] DumpRenderTree
We are actively working on DumpRenderTree, but it is not ready yet. We
plan to open it next month.
On Fri, Jan 15, 2010 at 10:26 AM, Eric
I'm learning to email.
On Fri, Jan 22, 2010 at 5:03 PM, Eric Seidel esei...@google.com wrote:
https://bugs.webkit.org/show_bug.cgi?id=33948 also broke leopard.
On Fri, Jan 22, 2010 at 4:34 PM, Maciej Stachowiak m...@apple.com wrote:
Ever since this change:
http://trac.webkit.org/changeset
We also have webkitpy/autoinstall.py which knows how to download
modules on-demand. This is useful in the case that you're using code
with an incompatible license.
see webkitpy/__init__.py for an example of how we pull in mechanize
(which is a HUGE module, with a compatible license for most
that can be flaky :) I'll install
simplejson into WebKitTools/simplejson as part of the patch and we can
clean it up once things are stable.
-- Dirk
On Thu, Jan 21, 2010 at 2:45 PM, Eric Seidel e...@webkit.org wrote:
Be aware, there are a couple known issues with our current autoinstall
setup
No, we leave out the default: That allows compilers to warn when
cases are missing.
Any time you see a default: in a WebCore switch, it's sub-optimal in my opinion.
-eric
On Wed, Jan 20, 2010 at 2:19 PM, Yong Li yong.li.web...@gmail.com wrote:
As everyone may know, current webkit style (at
/showdependencytree.cgi?id=33296hide_resolved=1
-eric
On Thu, Jan 7, 2010 at 4:24 PM, Eric Seidel e...@webkit.org wrote:
Oh, btw, you should see green all the way across, always.
I'm currently chasing down the tests which are making some of the bots
less reliable.
The leaves of
https://bugs.webkit.org
I don't feel like this question was ever answered.
Folks seem to be moving forward with setting up infrastructure for a
real port (which is good), but at least this question still remains.
Also, does the BREW port already have a DumpRenderTree implementation?
When should we expect such?
-eric
Most of the BREW patches look fine. I'm happy to review them once
there is consensus on the list that WebKit is ready and willing to
accept a BREW port.
-eric
On Thu, Jan 14, 2010 at 5:26 PM, Eric Seidel e...@webkit.org wrote:
I don't feel like this question was ever answered.
Folks seem
Looks like it fixed itself:
http://build.webkit.org/results/Tiger%20Intel%20Release/r53114%20(7655)/results.html
Now just needs new results after http://trac.webkit.org/changeset/53114
Sorry for the noise.
-eric
On Mon, Jan 11, 2010 at 8:42 PM, Eric Seidel e...@webkit.org wrote:
WebSocket
I've reduced #3 down to the 7 tests which seem required to make it fail:
https://bugs.webkit.org/show_bug.cgi?id=33372
Given that currently it requires 7 tests to make it fail, it seems we
should continue to skip this one for now.
-eric
On Sat, Jan 9, 2010 at 10:45 AM, Alexey Proskuryakov
https://bugs.webkit.org/show_bug.cgi?id=33443
If someone who has access to the bot could kick it. The revisions it
started failing in do not look related to the failures.
-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
On Fri, Jan 8, 2010 at 7:37 AM, Alexey Proskuryakov a...@webkit.org wrote:
* platform/mac/Skipped: Add http/tests/uri/escaped-entity.html to
Skipped list since it affects later tests.
I think that having this particular test enabled is much more important than
having the patch it was
Two things which could very quickly resolve this issue is if these
commands fail on their respective platforms or not:
run-webkit-tests --skipped=ignore
platform/mac/editing/input/devanagari-ligature.html
run-webkit-testsw --skipped=ignore
platform/mac/svg/W3C-SVG-1.1/filters-conv-01-f.svg
I
On Fri, Jan 8, 2010 at 12:14 PM, Alexey Proskuryakov a...@webkit.org wrote:
It's not clear where the bug is though. If there is an uninitialized memory
read in a later test, then earlier tests that randomly affect it can be
perfectly correct. The fact that on other platforms the problem was
I think the git svn diff one is a good fix. Such coudl start out as a
wrapper like the svn-create-patch we use for SVN. We could even just
teach svn-create-patch how to do the right thing for git. :)
-eric
On Wed, Dec 23, 2009 at 4:34 AM, Evan Martin e...@chromium.org wrote:
On Mon, Dec 21,
I think David Kilzer may be your best bet for getting feedback on
things like this. Or at least he would know who to point you to get
feedback.
-eric
2009/12/9 Simon Hausmann hausm...@kde.org:
Hi,
Kim and I have been looking into DOM/JavaScript touch event support (see
I went through again last night and recorded all known flakey tests as bugs.
I related them all to this bug:
https://bugs.webkit.org/showdependencytree.cgi?id=33296hide_resolved=1
which is about teaching webkit-patch and the commit-queue to block
commits on more bots than it does now. Right now
http://build.webkit.org/console
Will let you know.
The tree has been very red today, and even redder yesterday. I'm
working on yet another bot to help with this...
-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
. :(
-eric
On Thu, Jan 7, 2010 at 4:21 PM, Eric Seidel e...@webkit.org wrote:
http://build.webkit.org/console
Will let you know.
The tree has been very red today, and even redder yesterday. I'm
working on yet another bot to help with this...
-eric
I'm totally in favor of adding test_expectations.txt like
functionality to webkit (and we'll get it for free when Dirk finishes
up-streaming run_webkit_tests.py)
But the troubles with the pixel tests in the past were more to do with
text metrics changing between OS releases, and individual font
If those are the only two times, then it is fewer lines of code to
not use a local variable. In many cases it makes sense (to me) to use
a local variable, but not in the example you provided.
-eric
On Wed, Jan 6, 2010 at 10:46 AM, Chris Fleizach cfleiz...@apple.com wrote:
I see a lot of code
Not sure who I contact, I think Mark is on vacation.
http://build.webkit.org/builders/SnowLeopard%20Intel%20Leaks
http://build.webkit.org/builders/SnowLeopard%20Intel%20Leaks/builds/3237/steps/compile-webkit/logs/stdio
___
webkit-dev mailing list
My understanding is that RenderObject::isRenderMathMLBlock() is the
right approach, yes. Although if MathML base renderer (like
RenderBoxModelObject or RenderSVGModelObject), then an
isMathMLModelObject() would be even better. Then you only add one
method to RenderObject and the rest can go on
wrote:
On Mon, Jan 4, 2010 at 1:02 PM, Eric Seidel e...@webkit.org wrote:
My understanding is that RenderObject::isRenderMathMLBlock() is the
right approach, yes. Although if MathML base renderer (like
RenderBoxModelObject or RenderSVGModelObject), then an
isMathMLModelObject() would be even
forgot.
Better late than never I suppose?)
A couple weeks ago, Eric Seidel gave a tech talk to a live studio audience
of Googlers on the guts of webkit. Although there are a few bits that only
apply to Chromium, the vast majority of it is simply about WebKit, and thus
I thought it might
My 2¢: I like the name test-webkit-python. Or unittest-python, or
unittest-webkit-python.
On Mon, Dec 28, 2009 at 9:14 PM, Chris Jerdonek
chris.jerdo...@gmail.com wrote:
Last night on IRC there was a brief discussion of the test scripts:
how they should be divided in the future and what they
At time of writing, we have 50 bugs waiting in
http://webkit.org/pending-commit. :(
If you happen to be the responsible committer for a bug in the
pending-commit list, you may have just received an automated bug
message from e...@webkit.org. For more information see:
Done. The commit-queue is now using an SVN checkout of Git.
-eric
On Tue, Dec 22, 2009 at 10:01 PM, Maciej Stachowiak m...@apple.com wrote:
On Dec 21, 2009, at 12:22 PM, Eric Seidel wrote:
I'm happy to move the commit-queue to use an SVN checkout instead if
that would be a desired change
, not the least of which would be much
slower operation.
Dave
On Tue, December 22, 2009 8:29:09 PM, Eric Seidel wrote:
Done. The commit-queue is now using an SVN checkout of Git.
-eric
On Tue, Dec 22, 2009 at 10:01 PM, Maciej Stachowiak wrote:
On Dec 21, 2009, at 12:22 PM, Eric
our tools as necessary. :)
On Mon, Dec 21, 2009 at 1:46 AM, Holger Freyther ze...@selfish.org wrote:
On Monday 21 December 2009 08:25:31 Eric Seidel wrote:
The style-bot warns for style errors in all code in the webkit tree,
but I'm not sure if that's correct.
Are there sections of gtk/qt
If such git magic exists, it would be possible to teach svn-apply to use it.
-eric
On Mon, Dec 21, 2009 at 12:05 PM, Darin Adler da...@apple.com wrote:
On Dec 21, 2009, at 8:31 AM, Pavel Feldman wrote:
Sorry about that - it was git's decision.
It that’s the case, then please consider not
) is actually a copy of another similarly short
header file when doing large merges.
Again, you should use svn if you want to ensure file history.
Dave
On Mon, December 21, 2009 10:19:03 AM, Eric Seidel wrote:
If such git magic exists, it would be possible to teach svn-apply to use it.
-eric
The style-bot warns for style errors in all code in the webkit tree,
but I'm not sure if that's correct.
Are there sections of gtk/qt/whatever code which should be in a different style?
Sometimes these warnings are ignored. Sometimes they produce strange
reactions like this one:
For anyone else who went digging for the link:
http://trac.webkit.org/changeset/52125 :)
-eric
On Mon, Dec 14, 2009 at 6:42 PM, Adam Roben aro...@apple.com wrote:
For predictable failures like these, Darin Adler says the best thing to do is
land the expected failure as an expected result, and
I don't see a patch on the bug, but I look forward to seeing it when
it's posted.
I'm surprised that having switch-able JS engines would bubble up on
the list of things to do above things like passing the layout tests:
http://trac.webkit.org/browser/trunk/LayoutTests/platform/gtk/Skipped
:/
Looked at the bots again this morning and filed:
https://bugs.webkit.org/show_bug.cgi?id=32339 about a media test which
still seems to be failing on SL
https://bugs.webkit.org/show_bug.cgi?id=32340 about the Windows
fast/js/method-check.html crash.
-eric
On Tue, Dec 8, 2009 at 1:24 PM, Nikolas
Curious if we've ever tossed around the idea of setting up an lxr for
webkit?
Maybe the functionality of being able to click on a function name and have
it jump to the definition already exists somewhere on the web for WebKit and
I just am not aware of it.
-eric
LXR stuff in the works at Mac OS Forge (mentioned in the other
thread) will be the solution.
Thanks for your quick response.
-eric
On Tue, Dec 1, 2009 at 1:41 AM, Mark Rowe mr...@apple.com wrote:
On 2009-11-30, at 22:36, Eric Seidel wrote:
It's bothered me for a while that I can't just type
), but maybe there is one
tucked away somewhere, but I'm pretty clueless on the whole hosting a
website thing. :)
Thanks again.
-eric
On Tue, Dec 1, 2009 at 1:41 AM, Mark Rowe mr...@apple.com wrote:
On 2009-11-30, at 22:36, Eric Seidel wrote:
It's bothered me for a while that I can't just
/show_bug.cgi?id=30835 (which is likely the
same root cause as https://bugs.webkit.org/show_bug.cgi?id=31461).
I'll post again when the queue is back on.
-eric
On Fri, Nov 13, 2009 at 6:32 PM, Eric Seidel e...@webkit.org wrote:
I've turned off the commit-queue until we can find a solution to
https
As of 17:20 on 11/12/09 our bots and the Commit Queue started crashing
like mad men.
The Commit Queue has crashed 11 times since 11/12, after not having
crashed in over 2 weeks. :)
There seems to have been some regression relating to JSC objects.
I've filed bugs, split by which test is
Since these all look like the same bug, I'm just going to make:
https://bugs.webkit.org/show_bug.cgi?id=31461
be the master bug, and dupe the rest to it.
On Fri, Nov 13, 2009 at 1:08 PM, Eric Seidel e...@webkit.org wrote:
As of 17:20 on 11/12/09 our bots and the Commit Queue started crashing
I've turned off the commit-queue until we can find a solution to
https://bugs.webkit.org/show_bug.cgi?id=31461.
The commit-queue was rejecting more than half the patches queued in it
due to that bug, rendering it useless.
I'll post to webkit-dev once the queue is turned on again (hopefully
Agreed. Running every r=? patch through such a build-service is
insecure. However if Adam wishes to run it on his own hardware, I
certainly have no objections to such. :)
-eric
On Thu, Nov 12, 2009 at 2:49 PM, Mark Rowe mr...@apple.com wrote:
On 2009-11-12, at 14:43, Adam Barth wrote:
On
On Thu, Nov 12, 2009 at 3:51 PM, Eric Seidel esei...@google.com wrote:
I think Ojan is used to Chromium's world where there is a layout-test
rebaseling tool which knows how to suck expected results off of the
chromium try-bots, including new pixel test results. So he (and
others) are used
Personally I think it makes more sense as a plugin. Are there any
InkML files in existence? Would one want to view them in a web
browser? If one wanted to view them in a web browser, it seems an XSL
sheet which transformed the InkML into SVG/XHTML would be the easiest
way to display them in a
Would one of you mind filing a bug and CCing fishd and dglazkov?
-eric
On Tue, Nov 10, 2009 at 12:02 PM, Adam Barth aba...@webkit.org wrote:
That sounds like a bug to me. Historically the chromium port hasn't
had a strong distinction between WebKit and WebCore/platform, but I
think it's a
I expect that these are less design choices, and more historical
artifacts to the WebKit layer (formerly part of the glue layer) being
part of src.chromium.org until yesterday! :)
-eric
On Wed, Nov 11, 2009 at 10:35 AM, Eric Seidel e...@webkit.org wrote:
Would one of you mind filing a bug
The Closure Compiler was just released by Google:
http://googlecode.blogspot.com/2009/11/introducing-closure-tools.html
Most exciting for WebKit is we have a new JS pretty-printer:
http://closure-compiler.appspot.com/home
Dump piles of awful JS in there, and click whitespace only and
pretty
Yes.
https://bugs.webkit.org/show_bug.cgi?id=27980#c44
On Thu, Oct 29, 2009 at 12:13 PM, Yong Li yong.li.web...@gmail.com wrote:
I just noticed the following code:
#else
#define DEFINE_STATIC_LOCAL(type, name, arguments) \
static type name = *new type arguments
#endif
Is there any
On Thu, Oct 22, 2009 at 12:20 PM, Yong Li yong...@torchmobile.com wrote:
ChromeClient and other clients defined in webkit are using a lot of WebCore
objects. So it seems impossible to provide a ChromeClient from another
binary other than webkit itself. In other words, ChromeClient is almost
On Sun, Oct 18, 2009 at 11:34 PM, Adam Barth aba...@webkit.org wrote:
2) If you see a patch on the list that's ready to land (almost all of
them), you can mark it commit-queue+ to have the commit bot land it.
When you do this, please be sure to watch the tree for regressions,
just like you
We're back down to 25 after Yong's epic cq+ing this morning. The
queue had a record 13 patch backlog for a while. Thank you Yong for
cleaning the pending-commit list!
Still 25 to go. All of which require manual attention from committers.
-eric
On Mon, Oct 19, 2009 at 11:52 AM, Eric Seidel e
I really like the indented style that some folks have started using:
#if foo
#define BAR BAZ
#else
#define BAR BARF
#endif
I think we should standardize on something and add it to the style guides.
-eric
On Thu, Oct 15, 2009 at 10:30 AM, Tor Arne Vestbø
tor.arne.ves...@nokia.com wrote:
agree. I don't find any issues with the current, unindented style. I just
think that ifdefs that span more than 10 lines or so should always put the
condition on the #endif as a comment.
On Oct 15, 2009, at 8:12 AM, Eric Seidel wrote:
I really like the indented style that some folks have
Set a breakpoint in:
void ChromeClientQt::repaint(const IntRect windowRect, bool
contentChanged, bool, bool)
And see if you're getting the correct rects in and out.
-eric
On Thu, Oct 8, 2009 at 4:47 PM, Patrick Roland Gansterer
par...@paroga.com wrote:
SVG was designed to support this, it's
SVG was designed to support this, it's just not been turned on yet.
It would be one little patch and a lot of little patches afterwards to
fix things that break. :)
You'd just add a checks in RenderSVGContainer and RenderPath to see if
the dirty rect intersected the repaintRectInLocalCoordinates.
Now from the right email address...
-- Forwarded message --
From: Eric Seidel esei...@google.com
Date: Thu, Oct 8, 2009 at 1:02 AM
Subject: Re: [webkit-dev] Point 3 of the WebKit Style Guidelines
(indenting code inside namespaces in headers)
To: David Levin le...@google.com
Cc
. Let's disable it.
Geoff
On Oct 5, 2009, at 12:53 PM, Maciej Stachowiak wrote:
On Oct 5, 2009, at 12:23 PM, Eric Seidel wrote:
It seems that the requestee field is a source of confusion for new
contributers. Especially so when the new contributor comes from another
project where
It seems that the requestee field is a source of confusion for new
contributers. Especially so when the new contributor comes from another
project where the requestee field may be required (Google, and mozilla I'm
told).
I would like us to consider disabling the requestee field for the review
, 2009, at 12:23 PM, Eric Seidel wrote:
I would like us to consider disabling the requestee field for the review
flag.
Yes, I think we should do it.
-- Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org
I agree with Darin. I don't think that this is a good example of
where skipping would be useful.
I think more you're identifying that there is a test hierarchy problem
here. Chromium really wants to base its tests off of some base win
implementation, and then win-apple, win-chromium, win-cairo
Sounds like you want XBL. :)
On Mon, Sep 28, 2009 at 8:27 PM, Chris Frost chrisfros...@gmail.com wrote:
Hello All,
I am thinking about creating some custom HTML tags to abstract the process
of creating graphical widgets such as clock and calendar. To make it work, I
would imagine I need
Xiaomei's up to 12 patches. I'm confident she understands and will
follow WebKit process. I'd like to nominate here for commit bit.
http://trac.webkit.org/search?q=Xiaomei
Her patches have been reviewed by Darin Adler, Mitz, Simon and myself.
Always nice to have more RTL-enabled WebKit
My apologies. Please disregard, this is the wrong list for nominations.
On Mon, Sep 28, 2009 at 5:53 PM, Eric Seidel e...@webkit.org wrote:
Xiaomei's up to 12 patches. I'm confident she understands and will
follow WebKit process. I'd like to nominate here for commit bit.
http
I'm fine either way. Will check-webkit-style need an update? I think it might.
On Tue, Sep 22, 2009 at 1:23 PM, Sam Weinig sam.wei...@gmail.com wrote:
I also think this change is the right way to go. r=me.
On Tue, Sep 22, 2009 at 1:20 PM, Brady Eidson beid...@apple.com wrote:
I've always
We have a record 98 bugs in the review queue this morning. Please
take a peak at the queue today if you can find time. :)
https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.nametype0-0-0=equalsvalue0-0-0=review%3F
-eric
___
webkit-dev mailing
In case you're wondering why your commit-queue+'d patch has not landed yet...
http://webkit-commit-queue.appspot.com/
will now tell you. It needs work, but it's better than nothing.
The code will soon be in SVN and patches are most welcome:
https://bugs.webkit.org/show_bug.cgi?id=29307
-eric
tests to be green, or just some subsets of the Mac unit tests, or what?
-atw
On Fri, Sep 18, 2009 at 2:47 PM, Eric Seidel e...@webkit.org wrote:
In case you're wondering why your commit-queue+'d patch has not landed
yet...
http://webkit-commit-queue.appspot.com/
will now tell you. It needs
Looks fine. Thank you for giving warning so that people are aware of
this large change.
-eric
On Wed, Sep 16, 2009 at 6:17 PM, Shinichiro Hamaji ham...@chromium.org wrote:
Hi WebKit folks,
With great helps from Eric and Darin, I'm working on moving js only
layout tests from resources to
I was not aware bugzilla was sending such emails. That's unfortunate.
Certainly it can be changed. It used to just close bugs which only
had one patch, but the multi-patch/single-patch code paths were
unified a while back. The code in question can be found here:
experimental would be one option. We used to have build-webkit
--svg-experimental iirc.
-eric
On Wed, Sep 9, 2009 at 9:47 AM, Darin Fisher da...@chromium.org wrote:
Perhaps... any suggestions?-Darin
On Wed, Sep 9, 2009 at 8:45 AM, Adam Barth aba...@webkit.org wrote:
Maybe it's worth
:
That's why I started this thread. The process may be a bit unfamiliar to
somepatch contributors (especially new ones), and so I wanted reviewers to
be in
the know that changes to ChromiumBridge.h should not be committed using
the commit queue.
-Darin
On Sat, Sep 5, 2009 at 1:45 AM, Eric
It's a warning spit out from the compiler, diff, and other unix tools.
http://stackoverflow.com/questions/72271/no-newline-at-end-of-file-compiler-warning
is one explanation as to why gcc might output that warning (which turns into
an error due to the mac build treaing all warnings as errors).
Honestly, I was probably a bit aggressive in r-ing your patches.
Hopefully you won't take that personally. My hope was to get the ball
rolling again because the work on the WINCE port seemed to have
stalled out. Having a bunch of r? patches languishing in the review
queue isn't really
I didn't realize there were 2 competing WINCE ports??
On Wed, Aug 26, 2009 at 10:00 PM, Adam Barth aba...@webkit.org wrote:
In trying to help out with the review queue, I noticed this comment:
https://bugs.webkit.org/show_bug.cgi?id=28095#c16
[[
Comment #16 From George Staikos 2009-08-26
This is not the appropriate list.
webkit-help is what you want.
On Wed, Aug 26, 2009 at 9:12 PM, Conrad Taylor conra...@gmail.com wrote:
Hey ALL, I was wondering, is there list of known issues with CSS 2.1/3
support under webkit? Is there a test suite that I can run against WebKit?
Thanks in
On Thu, Aug 27, 2009 at 11:55 AM, Peter Kasting pkast...@google.com wrote:
Maintaining a cultural attitude that is widely positive towards cleanup
makes people feel less reticent about cleaning up, and taking ownership of,
code; frowning on certain types of cleanup makes people less likely to
No massive apologies required, but this is the wrong place.
webkit-help is what you want.
-eric
On Tue, Aug 25, 2009 at 1:58 PM, Dan d...@dancryer.com wrote:
Hi list,
Massive apologies in advance for this being both the wrong place to ask,
and a very vague question... but, does anyone have
601 - 700 of 807 matches
Mail list logo
