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 files
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 wrote:
> As everyone may know, current webkit style (at least for most source code
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 wrote:
> I don't feel like this question was ever answered.
>
> Folk
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
webkit.org/showdependencytree.cgi?id=33296&hide_resolved=1
-eric
On Thu, Jan 7, 2010 at 4:24 PM, Eric Seidel 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
Oliver Hunt mentioned this evening that he found the
webkit.org/pending-review page confusing because it lists both
commit-queue? patches and review? patches. I agreed.
I filed https://bugs.webkit.org/show_bug.cgi?id=33656 to track
updating /pending-review to more modern review URL and made some
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 wrote:
> WebSocket Server failing
WebSocket Server failing to start on Tiger Bot?
http://build.webkit.org/builders/Tiger%20Intel%20Release/builds/7654/steps/layout-test/logs/stdio
This started happening after the master-restart this afternoon. I
don't see any related changes around that time.
Can someone whack the bot over the
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 wrote
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
http://lists.webkit
On Fri, Jan 8, 2010 at 12:14 PM, Alexey Proskuryakov 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 not
> fixed su
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 s
On Fri, Jan 8, 2010 at 7:37 AM, Alexey Proskuryakov 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 affecting
The Chromium developers, notably Nicolas Sylvain added /console.
Mark Rowe is our kind BuildBot admin who updated our copy to the
latest BuildBot version including this new feature. I was not
involved. :)
On Fri, Jan 8, 2010 at 2:21 AM, Tor Arne Vestbø
wrote:
> Eric Seidel wrote:
>>
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
di
last 12 hours. :(
-eric
On Thu, Jan 7, 2010 at 4:21 PM, Eric Seidel 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 anoth
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
http://lists.webkit.org/m
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=33296&hide_resolved=1
which is about teaching webkit-patch and the commit-queue to block
commits on more bots than it does now. Right now
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 :
> Hi,
>
> Kim and I have been looking into DOM/JavaScript touch event support (see
> https://bugs.webkit.org/show_bug.c
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 wrote:
> On Mon, Dec 21, 2009 at 12:20 PM,
Thank you!
On Wed, Jan 6, 2010 at 2:37 PM, Simon Fraser wrote:
> He's around, and he just fixed this.
>
> Simon
>
> On Jan 6, 2010, at 2:22 PM, Eric Seidel wrote:
>
>> Not sure who I contact, I think Mark is on vacation.
>>
>> http://build.webkit
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
webkit
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 wrote:
> I see a lot of code that calls the sam
gt; 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
Mon, Jan 4, 2010 at 1:02 PM, Eric Seidel 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
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 yo
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:
https://bugs.webkit.org/show
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
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 should be
> called. The
a number of issues, though, 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 Tu
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 Seidel wrote:
>
>> I'm happy to move the commit-queue to use an SVN checkout instead if
>> that
although I don't know what that threshold is off
> the top of my head.
>
> I've also seen git think that a new header file (whose license text is larger
> than the header code itself) is actually a copy of another similarly short
> header file when doing large merges.
&g
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 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 using git fo
and update our tools as necessary. :)
On Mon, Dec 21, 2009 at 1:46 AM, Holger Freyther 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.
>>
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:
https://bugs.web
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 wrote:
> For predictable failures like these, Darin Adler says the best thing to do is
> "land the expected failure as an expected result, and use a bug to
On Mon, Dec 14, 2009 at 9:58 AM, Eric Seidel wrote:
> The tree is still in flames this morning. :( I've started filing bugs
> about the various failures. (I don't think it's in flames for the
> same reason as yesterday.)
>
> https://bugs.webkit.org/show_bug.cgi
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
:/
-eri
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 Zi
isted in robots.txt (
http://www.sitemaps.org/protocol.php#submit_robots), 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 wrote:
>
>>
>&
gical 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 wrote:
>
> On 2009-11-30, at 22:36, Eric Seidel wrote:
>
> It's bothered me for a while that I can&#x
It's bothered me for a while that I can't just type "trac webkit
Document.cpp" into Google and have it give me a trac link to our
Document.cpp page.
http://trac.webkit.org/browser/trunk/WebCore/dom/Document.cpp
I checked http://trac.macosforge.org/robots.txt tonight and low and behold
we disallow
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
__
Wow. I have to admit I was skeptical. It's way too early to tell, but I
*really* like the pass messages which make my job as a reviewer much easer:
https://bugs.webkit.org/show_bug.cgi?id=31985#c3
Thank you very much for putting this together Adam!
-eric
On Mon, Nov 30, 2009 at 4:03 PM, Adam B
will be gone.
If your patch is still waiting in the queue (7 of the 14 pending have
been processed already), you can check on it here:
http://webkit-commit-queue.appspot.com/
-eric
On Tue, Nov 17, 2009 at 3:58 PM, Eric Seidel wrote:
> Update:
>
> The queue is still down. I tried turn
/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 wrote:
> I've turned off the commit-queue until we can find a soluti
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 Monday
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 wrote:
> As of 17:20 on 11/12/09 our bots and the Commit Queue started crashing
> l
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 crashing
On Thu, Nov 12, 2009 at 3:51 PM, Eric Seidel 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
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 wrote:
>
> On 2009-11-12, at 14:43, Adam Barth wrote:
>
>> On Thu, Nov 12,
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 wrote:
> Would one of you mind filing a bug and CCing fishd
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 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 worthwhile distin
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 br
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 pr
Yes.
https://bugs.webkit.org/show_bug.cgi?id=27980#c44
On Thu, Oct 29, 2009 at 12:13 PM, Yong Li 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 reason of doing thi
On Thu, Oct 22, 2009 at 12:20 PM, Yong Li 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
> always implemented in
http://webkit.org/coding/contributing.html
http://trac.webkit.org/wiki/SuccessfulPortHowTo
Are two (possibly incomplete) resources.
On Thu, Oct 22, 2009 at 8:56 AM, Gregory Casamento
wrote:
> Hello all,
>
> I am currently working on a port of WebKit to GNUstep. I plan on
> having tons of quest
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, E
On Sun, Oct 18, 2009 at 11:34 PM, Adam Barth 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 would if you type
I do not understand your message.
Please file bugs (http://webkit.org/quality/reporting.html) about the
issues you've discovered for WebKit Qt. Ideally with examples.
-eric
On Tue, Oct 13, 2009 at 12:16 PM, Patrick Roland Gansterer
wrote:
>> But the damageRect is the whole frame size in
>> htt
ready.
>
> I 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 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ø
wrote:
> Hey,
>
> Could not find
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
wrote:
>> SVG was designed to support this, it's just not been tur
Now from the right email address...
-- Forwarded message --
From: Eric Seidel
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
Cc: Maciej Stachowiak , webkit-dev
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.
x27;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 w
ct 5, 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 lis
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
flag
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-
Sounds like you want XBL. :)
On Mon, Sep 28, 2009 at 8:27 PM, Chris Frost 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 some interpreter to t
My apologies. Please disregard, this is the wrong list for nominations.
On Mon, Sep 28, 2009 at 5:53 PM, Eric Seidel 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.
>
> ht
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 hackers
On Fri, Sep 25, 2009 at 2:42 PM, Maciej Stachowiak wrote:
> I like Dave Levin's idea that the first action should be to instrument the
> tests so we can find out why they intermittently fail. Especially if the
> failure is reproducible on the bots but not on developer systems.
I like this idea to
On Fri, Sep 25, 2009 at 1:59 PM, Darin Adler wrote:
> For tests that give intermittent and inconsistent results, the best we can
> currently do is to skip the test. I think it would make sense to instead
> allow multiple expected results. I gather that one of the tools used in the
> Chromium proje
bugs.webkit.org/show_bug.cgi?id=29322
:)
Thanks for your time!
-eric
On Thu, Sep 24, 2009 at 1:40 PM, Eric Seidel wrote:
> I think the question is most interesting in the abstract as a question
> of general policy about flakey tests. I think handling the
> circumstances of each bug is best le
hasTagName is better as it does the correct thing wrt case and namespaces.
I think that AtomicString has an:
operator ==(const AtomicString&, char*)
but if it doesn't then you're transparently creating an
AtomicString/String with your use of "mfrac".
Also "mfrac" being a manually typed constant c
n Wed, Sep 23, 2009 at 11:23 PM, Maciej Stachowiak wrote:
>
> On Sep 23, 2009, at 11:09 PM, Eric Seidel wrote:
>
> Alexey and I have been discussing if WebKit should add flakey tests to
> Skipped lists:
> https://bugs.webkit.org/show_bug.cgi?id=29322
>
> Alexey asked tha
Alexey and I have been discussing if WebKit should add flakey tests to
Skipped lists:
https://bugs.webkit.org/show_bug.cgi?id=29322
Alexey asked that I bring the discussion to a larger audience.
Pros:
- Buildbots stay green.
- Red bots/tests means your change caused an error.
Cons:
- Skipped tes
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 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 wrote:
>>
>> I've always hated the indentation in header
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.name&type0-0-0=equals&value0-0-0=review%3F
-eric
___
webkit-dev mailing l
r all unit
> 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 wrote:
>>
>> In case you're wondering why your commit-queue+'d patch has not landed
>> yet...
>>
>> http://w
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
_
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 wrote:
> Hi WebKit folks,
>
> With great helps from Eric and Darin, I'm working on moving js only
> layout tests from "resources" to "script-tests" di
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:
http://trac.webkit.org/browser/t
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 wrote:
> Perhaps... any suggestions?-Darin
>
>
> On Wed, Sep 9, 2009 at 8:45 AM, Adam Barth wrote:
>
>> Maybe it's worth distinguishing these settings with
Sorry for the delays with the commit-queue this weekend.
I checked it this morning to find it spinning with 4 queued patches due to
https://bugs.webkit.org/show_bug.cgi?id=28605. Fixed now.
The commit-queue is still wrongly rejecting some patches due to
flakey/crashy media tests.
https://bugs.webk
Please file a bug:http://webkit.org/quality/reporting.html
Ideally one which shows how our behavior differs from other browsers with a
nice clear test case.
-eric
On Sun, Sep 6, 2009 at 10:30 PM, 白石俊平 wrote:
> Hi
>
> I tried to use the JSON.stringify() for Date object on Safari4 and
> WebKit n
3:16 PM, Darin Fisher wrote:
> 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 qu
Agreed. It's the submitters responsibility to make it clear that they don't
want their patch committed immediately after review. Current assumption is
that all committers don't want their patches committed after review, but all
non-committers do.
-eric
On Fri, Sep 4, 2009 at 7:12 PM, David Levin
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).
-er
>
>
> 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 real
Just your friendly reminder that the review-queue is out of control again.
We're @ 54 (was 84 on Monday):
https://bugs.webkit.org/buglist.cgi?field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=review%3F
If a reviewers could each take a stab at r-'ing (or r+'ing!) a few patches
today we'd be ba
It seems we have a leak bot again! Thanks to all who made that possible!
There seem to be a bunch of leaks though. They all seem CFNetwork related:
http://build.webkit.org/results/SnowLeopard%20Intel%20Leaks/r47923%20(318)/
I'm not sure if that's because we're leaking in WebCore and it's just
s
On Thu, Aug 27, 2009 at 11:55 AM, Peter Kasting 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 do
> _any_ clean
This is not the appropriate list.
webkit-help is what you want.
On Wed, Aug 26, 2009 at 9:12 PM, Conrad Taylor 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 advance,
>
> -C
I didn't realize there were 2 competing WINCE ports??
On Wed, Aug 26, 2009 at 10:00 PM, Adam Barth 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 09:17:28 PDT
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 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 any general guid
This list is about development of the WebKit rendering engine. This is not
a relevant question.
If you want to hack on WebKit in some future career, no reason to not just
start now: http://webkit.org/coding/contributing.html
We don't care if you have a masters or not. Then again, nor do most
em
Yes, there are bugs, like all software. Your flippant response seems
inappropriate.
On Mon, Aug 17, 2009 at 11:41 AM, Mark Rowe wrote:
>
> On 2009-08-17, at 11:36, Eric Seidel wrote:
>
> If you're currently using "svn commit" or "git svn dcommit" to co
If you're currently using "svn commit" or "git svn dcommit" to commit your
patches, please consider using "bugzilla-tool land-diff" instead.
Why?
1. bugzilla-tool updates (and optionally closes) the bug for you when
you're done.
2. bugzilla-tool makes a nice commit entry automatically for you (
701 - 800 of 926 matches
Mail list logo
