As we venture on the path toward a better integration with WebKit, the
tree is undergoing some incremental changes.
The goal of these changes is to move the state of the
/trunk/deps/third_party/WebKit directory as close to that of a vendor
branch as possible, with the minimal impact on the ongoin
Dear All,
I am about to commit the first batch of the unforking changes. You can
see the changes here:
http://codereview.chromium.org/6243
Please take a look at the list of files affected and, if you've worked
on these files ( (the diffs will conveniently highlight your doing),
make a mental no
ead/thread/ea75f31c763b4457
:DG<
On Fri, Oct 3, 2008 at 11:45 AM, Dimitri Glazkov <[EMAIL PROTECTED]> wrote:
> Dear All,
>
> I am about to commit the first batch of the unforking changes. You can
> see the changes here:
>
> http://codereview.chromium.org/6243
>
> Pleas
-chromium-reviews
+chromium-dev
I am testing a simplistic setup with using svn properties to track
WebKit versions, and it seems to work pretty well and avoids having to
do the extra scrub/commit steps. I am writing this up, will post soon.
:DG<
On Fri, Oct 3, 2008 at 2:00 PM, Darin Fisher <[EM
This is now a README in third_party/WebKit:
http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/README
:DG<
On Fri, Oct 3, 2008 at 11:37 AM, Dimitri Glazkov <[EMAIL PROTECTED]> wrote:
> As we venture on the path toward a better integration with WebKit, the
> tre
To me, it looks like the case where we could create an abstraction,
similar to what I did with ExceptionContext, which encapsulates
ExecState* and ArgList* on JSC side and provides a way to pass
strings/line numbers for V8.
So, at this point I would merge Console.cpp into one two-chunked file
(op
Unbelievable ... chromium-dev just ate it.
:DG<
-- Forwarded message --
From: Dimitri Glazkov <[EMAIL PROTECTED]>
Date: Tue, Nov 4, 2008 at 4:02 PM
Subject: Re: [chromium-dev] started next webkit merge (to r38097)
To: chromium-dev@googlegroups.com
The Win mer
Dear Chromiumazoids,
The merge we started on Tuesday has landed this morning. There were no
regressions (so far), trees are green, birds are chirping, spring is
in the air. We're now [EMAIL PROTECTED]
:DG<
--~--~-~--~~~---~--~~
You received this message because y
Pam++!
:DG<
On Thu, Nov 13, 2008 at 6:02 PM, Darin Fisher <[EMAIL PROTECTED]> wrote:
> Thanks for cleaning this up, Pam!!!
>
> On Thu, Nov 13, 2008 at 4:57 PM, Pam Greene <[EMAIL PROTECTED]> wrote:
>>
>> Today I got our custom (platform-specific) layout test results mostly
>> straightened out. (
Should be fixed now. It was a few files losing a build target after
the move and include path needed adjustment in test_shell_tests proj.
:DG<
On Sun, Dec 21, 2008 at 10:43 PM, Pam Greene wrote:
>
> I broke the Mac build with the last WebKit merge: it looks like I did
> not get all the header s
http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/
These haven't been yet upstreamed. We just started by moving them into
our vendor branch.
:DG<
On Tue, Dec 23, 2008 at 1:31 PM, Adam Barth wrote:
>
> I'm confused. I need to fix a bug in ImageSource
wait
> for them to appear upstream?
>
> Adam
>
>
> On Tue, Dec 23, 2008 at 1:35 PM, Dimitri Glazkov wrote:
>>
>> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/
>>
>> These haven't been yet upstreamed. W
he set of files and diffs
> that have yet to be upstreamed.
> -Darin
>
> On Tue, Dec 23, 2008 at 2:51 PM, Adam Barth wrote:
>>
>> I see. Can I make changes to them in third_party, or should I wait
>> for them to appear upstream?
>>
>> Adam
Dear People of Chromium,
I've been thinking about the process of making changes to WebKit code
in a logical and consistent fashion (note, that doesn't necessarily
preclude "sane").
Until we've switched to the integration model, we are still in a
vendor branch state and thus the process of tweaki
http://sites.google.com/a/chromium.org/dev/developers/webkit-changes
:DG<
On Fri, Jan 9, 2009 at 11:15 AM, Dimitri Glazkov wrote:
> Dear People of Chromium,
>
> I've been thinking about the process of making changes to WebKit code
> in a logical and consistent fashion
Generally +1, except I just imagined the situation where the merger
collides with the fixer. So maybe no overlapping, just do the merge
every other day?
:DG<
On Thu, Jan 15, 2009 at 1:31 PM, Brett Wilson wrote:
>
> On Thu, Jan 15, 2009 at 1:20 PM, Pam Greene wrote:
>> When fixing layout tests
This is veering wildly off-topic, but I think the key to solving merge
regressions is in moving to an integration model. With the integration
model, we can integrate one WebKit changeset at a time, and clearly
identify the regressions. This would go a long way in identifying the
cause and addressi
Hi All,
Because the latest merge brought down a change to CSSNames.in
(http://trac.webkit.org/changeset/40939), all those of us building on
Windows will need to clobber: delete your build directory and start
with a clean build.
:DG<
--~--~-~--~~~---~--~~
Chromium
This week I will be:
* doing merges.
* making Linux folks suffer by incessantly modifying v8_custom and
v8_proxy while upstreaming V8 files.
:DG<
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email op
Hi All,
Because the latest merge introduces a change to
third_party/WebKit/WebCore/css/html4.css, which is only picked up by
DerivedSources.make, making that change actually appear in your build
requires a clobber.
:DG<
--~--~-~--~~~---~--~~
Chromium Developers m
As it turns out, the clobber applies to Mac and possibly Linux builds.
Basically, clobber all.
:DG<
On Wed, Feb 18, 2009 at 3:11 PM, Dimitri Glazkov wrote:
> Hi All,
>
> Because the latest merge introduces a change to
> third_party/WebKit/WebCore/css/html4.css, which is on
I actually didn't mean to start this conversation. Is there still time
to run away and hide? :)
On a (slightly) more serious note, I agree with your assessment and I
thought at first that there was some work being done on that.
:DG<
On Fri, Feb 20, 2009 at 12:25 PM, Ojan Vafai wrote:
> -chromi
Mark rocks! Send him your money.
:DG<
On Sun, Mar 1, 2009 at 5:39 PM, Ben Goodger (Google) wrote:
>
> Awesome! Thanks for getting this together, Mark. Do you have any idea
> what the ETA for Linux and Windows is?
>
> -Ben
>
> On Sun, Mar 1, 2009 at 4:32 PM, Mark Mentovai wrote:
>>
>> The GYP-b
If you don't do the merges, you can stop reading now -- though you
might ask yourself why you're not doing the merges. They are so much
fun.
In the next few days (hopefully not weeks), I am making changes to
InspectorController in an effort to unfork it. This is the good news.
The bad news is tha
Team,
We have many brains working the layout test puzzle. And that's a good
thing. We've got this Rubik's cube nearly all finished. However, it
somewhat pains me seeing lots of engineers spending countless hours
trying to fix the SVG tests. Perhaps we shouldn't be doing that? I
mean, based on my
My merge tracker still uses it. I can rewrite to switch over to DEPS,
though it may not be tomorrow :)
:DG<
On Mon, Mar 23, 2009 at 5:46 PM, Ojan Vafai wrote:
> I think this file is basically useless at this point. All the information in
> it is encoding in src/DEPS (it now has a webkit_revisio
Please don't kill it just yet. Let me switch the Merge Tracker to use
DEPS and then we can kill it.
:DG<
On Mon, Mar 23, 2009 at 10:03 PM, Eric Seidel wrote:
> Kill it (or I can, as part of the merge tomorrow)... so long as the merge
> instructions are up to date.
>
> On Mon, Mar 23, 2009 at 5:
Testing the fix ...
:DG<
On Tue, Apr 28, 2009 at 8:36 PM, Bradley Nelson wrote:
> Looking into a fix, this may be a missing dependency from v8_snapshot on
> js2c.
> It would non-deterministically pass with incredibuild.
> -BradN
>
> On Tue, Apr 28, 2009 at 8:32 PM, Feng Qian wrote:
>>
>> libra
It looks like the missing dependency did the trick: both clobber of
Chromium builder and clean local build work now. Can haz open tree?
:DG<
On Tue, Apr 28, 2009 at 9:04 PM, Dimitri Glazkov wrote:
> Testing the fix ...
>
> :DG<
>
> On Tue, Apr 28, 2009 at 8:36 PM,
I think it's a great idea and the only drawback I can see is the WTF
dependency and the security implications, which shouldn't be anything
we couldn't overcome.
The biggest challenges IMHO would be:
1) clearly identifying what backend and frontend mean and where the
separation occurs. I worry (p
There's a change to DOMWindow.idl, which pretty much always warrants a
clobber on Win builds. I just clobbered WebKit builder, let's see what
happens.
:DG<
On Wed, Apr 29, 2009 at 4:11 PM, Jeremy Moskovich wrote:
> Hi,
> Today's WebKit merge (42932:42994 -
> http://trac.webkit.org/changeset?new
Once again, I've checked in an IDL change. And as you may remember, we
don't track this dependency very well in Windows build. Thus, please
clobber your local build after syncing :)
:DG<
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegr
We are very, very close to total unforking. In order to facilitate the
completion of this process, please refrain from landing any changes in
trunk/deps/third_party/WebKit. This holds true even if your patch is
already approved upstream. So, to put it simply:
NO MOAR THIRD_PARTY/WEBKIT COMMEETS.
Not yet. There's a small bunch of people still landing unforkages.
:DG<
On Fri, May 1, 2009 at 8:40 AM, Marc-Antoine Ruel wrote:
> svn lock?
>
> On Fri, May 1, 2009 at 11:35 AM, Dimitri Glazkov
> wrote:
>>
>> We are very, very close to total unfor
Team,
As part of the global WebKit unforking, I will be rolling out shortly
the change to ResourceResponse.h that we put in a while back:
http://codereview.chromium.org/29007
We have now completed the investigation and there's no need for this
fork anymore.
As a result, you will see a memory/s
Hello all,
This is kind of a momentous occasion. For the first time -- ever, our
WebKit Canary bot (the one that pulls directly from WebKit upstream)
has built successfully and was able to run tests:
http://build.chromium.org/buildbot/waterfall.fyi/builders/Webkit%20(webkit.org)/builds/2937
Wha
f those files are in the WebKit repository yet,
> but just want to double check.
>
> On Fri, May 1, 2009 at 8:35 AM, Dimitri Glazkov
> wrote:
>>
>> We are very, very close to total unforking. In order to facilitate the
>> completion of this process, please refrain from l
Stee-ven! Stee-ven! Stee-ven!
:DG<
On Fri, May 8, 2009 at 9:36 AM, Bradley Nelson wrote:
> Congrats steven! Excellent work!
> -bradn
>
> On May 8, 2009 8:51 AM, "Darin Fisher" wrote:
>
> FYI, here's the patch I applied to enable /MP:
> Index: common.gypi
> =
Hello all,
As Darin indicated earlier, we can no longer do WebKit merges. This is
indeed sad news for all of us, because merges were such an
exhilarating thing to do. They were practically these continuous wild
parties that often went on way beyond the allotted time. We will
remember them forever
There's a few things in the way that prevent this from happening now
(like LayoutTests being in a different directory in our checkout), but
yes, this is the plan. I too want to develop in one tree! :)
http://crbug.com/12040
:DG<
On Fri, May 15, 2009 at 12:24 AM, Adam Barth wrote:
>
> Being abl
/me raises hand sheepishly. Whatcha need? :)
:DG<
On Wed, Jun 3, 2009 at 5:37 PM, Adam Barth wrote:
>
> Who's a good contact for V8DOMMap? It's probably going to need some
> surgery to support isolated user scripts, and I want to make sure I'm
> not screwing it up.
>
> Thanks,
> Adam
>
> >
>
The problem is with enabling TR1 and its interaction with the xmath.h
header, which is inclusion in MathExtras.h. xmath.h defines _F0 macro,
which is used as a param in xrefwrap. The temporary solution is to
remove xmath.h include from MathExtras.h
:DG<
On Thu, Jun 4, 2009 at 10:04 AM, Mike Bels
Team,
Now that we're unforked, we want to concentrate on eliminating layout
test failures. Through the magic of the WebKit merge, we've
accumulated quite a few. Today, we expect around 400 failures, which
is not a good number by any stretch.
As one of the ways to help determine the source of the
A good place to start would be to look at existing *Constructor.cpp
files in WebCore/bindings/v8 and see how they are hooked in (like
Image constructor). Also, you have dimich and levin in close proximity
you who have added a V8 constructor or two in the past (I think).
;DG<
On Mon, Jun 15, 2009
But I'm still getting "TypeError: Illegal constructor" when I try to
> call the audio constructor. Is there another hook I'm missing?
>
>
> On Jun 16, 11:47 am, Dimitri Glazkov wrote:
>> A good place to start would be to look at existing *Constructor.cpp
>>
pp... I have no idea
> what I'm still missing.
>
> On Jun 18, 8:38 pm, Dimitri Glazkov wrote:
>> You're almost there. You also need to make sure to register it in
>> v8_proxy.cpp (look for Image as a pattern to follow).
>>
>> BTW, with gyp, dependencies in
I think this is a really good idea, something Maciej has been doing
for us in bugs.webkit.org:
Anytime you create a WebKit bug that's specific to Chromium port,
please add [Chromium] prefix to the bug title.
:DG<
--~--~-~--~~~---~--~~
Chromium Developers mailing
Can we put this in a bug for easier trackage?
:DG<
On Mon, Jun 22, 2009 at 5:58 AM, Evan Martin wrote:
>
> While we're wishing, I'll add that verifying this should be added to
> the presubmit script (if you touched any layout tests).
>
> On Mon, Jun 22, 2009 at 3:20 AM, Dean McNamee wrote:
>>
>>
Amen.
I am working on it :) First step -- teach our code generator to
understand IDL in the same way JSC does.
:DG<
On Mon, Jun 22, 2009 at 12:02 PM, Aaron Boodman wrote:
>
> One thing I'd really like to see is a reduction in the amount of
> custom bindings code. I am terrified by the number of
Yes, we're working feverishly (is that a good word for this? :) to
make this situation a bit less hard.
However, in the meantime, the process could go like this:
1) Make sure the canary had a green run. This would really help the
WebKit gardener to know which revision to roll up to.
2) Land you
Based on our experiences from the past few weeks of rolling, I updated
the WebKit Integration documentation:
http://sites.google.com/a/chromium.org/dev/developers/how-tos/webkit-merge-1
They key takeaways are:
1) roll often, in small increments
2) pay attention to actual changes you're rolling
I don't see anything wrong with publishing design docs on webkit-dev.
Just don't proselytize :)
:DG<
On Mon, Jun 29, 2009 at 11:40 AM, Jeremy Orlow wrote:
> On Mon, Jun 29, 2009 at 11:07 AM, David Levin wrote:
>>
>> It seems like if you are doing a significant change to an existing area or
>> a
Mike, I apologize -- I meant to send out an email about this. Yes, for
some reason Mac (of all things!) requires a clobber after landing
V8Proxy switch-over. No other platforms should be affected, but if you
see V8 compile errors, clobber is the answer.
:DG<
On Tue, Jun 30, 2009 at 6:09 AM, Mike
As of r19910 (and with --enable-remote-fonts flag), we now fully pass
the acid3 test. Thanks to brettw for his patience and to pkasting for
guilting me into fixing this "the right way".
:DG<
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@goog
Chromiumites, who would be a good person to answer his question?
:DG<
On Fri, Jul 3, 2009 at 1:47 AM, tvk wrote:
>
> Hi,
>
> To fix issue #4576 how to get the page size? Fixing where would be
> considered as the best?
>
> Below I elaborate the issue.
>
> In WebCore, HTML Select element is render
Apply this locally, if you want to get rid of them:
diff --git a/WebCore/bindings/scripts/IDLParser.pm
b/WebCore/bindings/scripts/IDLParser.pm
index c4cb041..0a6832f 100644
--- a/WebCore/bindings/scripts/IDLParser.pm
+++ b/WebCore/bindings/scripts/IDLParser.pm
@@ -75,7 +75,7 @@ sub Parse
pr
gt;
> Mark
>
> Ben Laurie wrote:
>>
>> On Mon, Jul 6, 2009 at 3:43 PM, Dimitri Glazkov wrote:
>>>
>>> Apply this locally, if you want to get rid of them:
>>>
>>> diff --git a/WebCore/bindings/scripts/IDLParser.pm
>>> b/WebCore/bin
http://codereview.chromium.org/155089
:DG<
On Mon, Jul 6, 2009 at 8:33 AM, Mark Mentovai wrote:
> I can help you out this afternoon if necessary.
>
> Dimitri Glazkov wrote:
>> I agree -- if weren't such a Python n00b I'd already have a patch. I
>> am lo
Right. Victor is just switching the tests to reside where they needed
to be, not dealing with test results. Test results is somewhat of a
longer story and we're not tackling this yet.
:DG<
On Fri, Jul 10, 2009 at 12:07 PM, Victor Wang wrote:
>
>
> On Fri, Jul 10, 2009 at 11:11 AM, Ryosuke Niwa
bump.
On Wed, Feb 25, 2009 at 2:27 PM, Mark Mentovai wrote:
>
> Over the past month, some of us have been working on a
> not-so-well-kept secret project to create a "build system system."
> Our goal is to have something Generate Your Projects (GYP) in a
> variety of formats, all from the same sou
Dear All,
Just a few hours ago, I switched over webkit.gyp to pull the list of
WebCore and JavaScriptCore files from upstream-living
WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi,
respectively.
This change should alleviate a lot of pain for WebKit gardeners and
those landing two-si
Are you volunteering? ;)
http://spreadsheets.google.com/ccc?key=piGkUUMLW-PNUzuhTCzm4NQ
:DG<
On Thu, Jul 16, 2009 at 9:43 AM, Jeremy Orlow wrote:
> Maybe those should be moved out of the source tree (into deps) so that they
> can be excluded?
>
> On Thu, Jul 16, 2009 at 9:23 AM, Victor Wang wr
On Sun, Aug 2, 2009 at 8:17 PM, nakro wrote:
>
> This is mostly related to problems people have in the help forum
>
> 1- you fork a process for npapi plugins, but many people report that
> if they have a bookmark folder with loads
> of flash content, they get an 'Aw Snap' or the lucky ones get OUt
Thanks for checking on this! I made the changes.
:DG<
On Wed, Jul 29, 2009 at 3:30 PM, Evan R. Murphy wrote:
>
> Thanks to all who worked on this, and congratulations on the success.
> Can somebody with the permissions please update How Chromium Displays
> Web Pages [1] to reflect these changes?
On Colloquy (+ Growl), I set the toast with my name mentioned to never
expire. So it's always there unless I "X" it out.
:DG<
On Wed, Aug 5, 2009 at 7:25 PM, Dirk Pranke wrote:
>
> I would love to enable that feature ... anyone know how to do that for
> Adium on the Mac (IRC support is new in th
Ojan is working on the tool for the layout tests. First bits are
already checked in.
:DG<
On Wed, Aug 5, 2009 at 10:10 PM, Eric Seidel wrote:
> Do we have a list of flakey tests? I feel like we used to have one...
>
> On Wed, Aug 5, 2009 at 9:44 PM, Peter Kasting wrote:
>>
>> THIS MAIL APPLIES
This is more of a WebKit-land question, rather than Chromium-land
question. And yes, it's basically a rule on WebKit-land -- always
include config.h.
You may want to raise the idea of a presubmit check on webkit-dev.
:DG<
On Fri, Aug 7, 2009 at 5:48 AM, Ben Laurie wrote:
>
> I just got bitten b
Somebody please run with this! :)
:DG<
On Fri, Aug 7, 2009 at 8:45 PM, Darin Fisher wrote:
> On Fri, Aug 7, 2009 at 8:39 PM, Ojan Vafai wrote:
>>
>> On Fri, Aug 7, 2009 at 8:45 PM, Jeremy Orlow wrote:
>>>
>>> Has anyone ever looked into printing out stack traces when layout tests
>>> crash? O
>> 2. The show stopper for any implementation of this feature is that the
>> machines running the layout tests don't have the pdbs for test_shell. Since
>> the binary is built on another machine, it was too slow to copy the pdbs
>> from one machine to another. If you guys think it's important, and
The culprit here was the change to the CodeGeneratorV8.pm. It looks
like we should somehow trigger clobber of of rule_binding.py when that
happens.
:DG<
On Mon, Aug 10, 2009 at 11:24 PM, Jeremy Orlow wrote:
> They were both WebKit deps rolls. The latter one was caused by an .idl file
> that cha
I thought this is something I should mention here:
This change: http://src.chromium.org/viewvc/chrome?view=rev&revision=23244
reduced the number of crashes on Mac from 13-15 with high degree of
flakiness to a very consistent 2.
pkasting, this is your man.
:DG<
--~--~-~--~~-
If you don't commit to WebKit, you can stop reading now.
I am looking for someone to own a fairly large-sized task: bringing up
WebKit-side build of our port to life. The bug for it is here:
https://bugs.webkit.org/show_bug.cgi?id=28396
The big picture is here:
https://trac.webkit.org/wiki/Chr
On Sat, Aug 22, 2009 at 9:51 PM, Jeremy Orlow wrote:
> It might be worth going through all the LayoutTest bugs and double check
> they're split up into individual root causes (or something approximating
> that). I'll try to make time to do a scan in the next week or so, but it'd
> be great if any
I understand the resistance to implement yet another bit of process
and effort around layout tests. I really do. However, I found some
merit in Dirk's idea -- it allows us to clearly see the impact of a
regression.
Sadly, I can't come up with a specific example at the moment, but let
me pull one
Great work, dude. Seriously good stuff. I'll be digging through this tomorrow.
Now, how do I change the theme on this thing? ;P
:DG<
On Mon, Aug 24, 2009 at 6:42 PM, Ojan Vafai wrote:
> A first version of the layout test flakiness dashboard is up.
> http://src.chromium.org/viewvc/chrome/trunk/s
I've had this issue before and found that if I used svn rebase it
would sometimes fix it. So I am thinking perhaps instead of git pull,
you could attempt doing git fetch first and then git merge? This would
do the same thing, except not in atomic op.
:DG<
On Thu, Aug 27, 2009 at 10:49 AM, Nico W
It's like "Tales from the crypt", but less fun and actually scary.
I just found out that we wall-papered over about 80-100 tests in
fast/repaint dir. I will be removing bad baselines shortly.
The bad news is that this bumped our failures to 875 (from 778 this morning).
The good news is that the
for them?
>
> Ojan
> On Thu, Aug 27, 2009 at 11:46 AM, Dimitri Glazkov
> wrote:
>>
>> BTW, about to filter out all LayoutTests/media out for now, skipping
>> them. We can't have codecs for most of these tests, so we (Alpha and
>> myself) decided it
A boolean return value here is going to work best.
if (!getMessagePortArray(args[1], portArray) {
// bail.
}
:DG<
On Sun, Aug 30, 2009 at 5:12 PM, Drew Wilson wrote:
> I have a utility routine that I want to call from various v8 bindings. This
> utility routine does some validation on the pas
Dear Chromiumites and friends of the show,
We now have a builder upstream that builds Chromium webkit port:
http://build.webkit.org/waterfall (look to the very right of the
columns).
Granted, the road to the actual complete Chromium WebKit port is still
long and winding (https://trac.webkit.org/
Marc-Antoine, you will forever have a special place in every WebKit
committer's heart if you can pull of setting up these trybots.
Given that this thread quickly discombobulated into a general WebKit
rant, I want to wind it back to the topic: Yaar, I think your plan is
good. Keep it coming.
:DG<
Go Yaar! Thanks for taking on this task.
:DG<
On Fri, Sep 18, 2009 at 10:56 AM, Yaar Schnitman wrote:
> webkit.gyp was re-factored as preparatory work for the webkit chromium port.
> More information can be found here:
> http://codereview.chromium.org/212003/show
> Thanks for everybody who help
Thank you so much for doing this!
:DG<
On Tue, Sep 22, 2009 at 9:39 AM, Yaar Schnitman wrote:
> If you use (or consider using) Git, and also work on webkit (or any other
> 3rd party dependency actually) you may find the following valuable:
> The latest depot_tools (revision 26817+) makes it pos
Yep. Dirk was the one to suggest bringing it back. I didn't put this
in the documentation, but only because I wasn't yet sure whether we'll
track them by bug milestone or explicitly using the tag.
:DG<
On Tue, Sep 22, 2009 at 11:33 AM, Ojan Vafai wrote:
> On Tue, Sep 22, 2009 at 10:26 AM, Jeffr
Today wasn't a happy day for p...@. He did a seemingly innocuous roll
that broke the world: selenium, ui tests, layout tests. I am sure it
was stressful and probably added unnecessary gray to his hair.
Stuff like this happens to WebKit gardeners. We're used to breakages
upstream. That's the cost
On Tue, Sep 22, 2009 at 6:08 PM, Adam Barth wrote:
>
> On Tue, Sep 22, 2009 at 5:40 PM, Nicolas Sylvain
> wrote:
>> If this is an issue, I am proposing that Webkit merges be done outside peak
>> hours (11am-5pm pacific).
>
> This seems backwards. Don't we want to integrate more often so we can
On Tue, Sep 22, 2009 at 6:10 PM, Nicolas Sylvain wrote:
>
>
> On Tue, Sep 22, 2009 at 6:08 PM, Adam Barth wrote:
>>
>> On Tue, Sep 22, 2009 at 5:40 PM, Nicolas Sylvain
>> wrote:
>> > If this is an issue, I am proposing that Webkit merges be done outside
>> > peak
>> > hours (11am-5pm pacific).
> 1) writers of patches don't mention that the patch is two-sided and
> will break Chromium if landed prematurely. I don't have to go far for
> an example. Commit queue bot landed
> http://trac.webkit.org/changeset/48659 a few minutes ago and broke the
> canary. This means that the canary will be
On Wed, Sep 23, 2009 at 7:46 AM, Mike Pinkerton wrote:
>> It is hard to be a WebKit gardener if you do not have WebKit commit access.
>> Sometimes the gardener has to commit a quick bustage fix upstream or roll
>> back a fellow Chromium committers change to WebKit.
>> -Darin
>
> Correct, it is ha
I think this is a great idea! Do we have a Python/gcl/rietveld expert
who can tackle this?
:DG<
On Wed, Sep 23, 2009 at 9:49 AM, John Abd-El-Malek wrote:
> I didn't know this was possible. It seems it will get a lot more usage if
> it "just works", i.e. the try script grabs these settings auto
ver
> does this. I don't think it'll be much work.
>
> On Wed, Sep 23, 2009 at 10:04 AM, Dimitri Glazkov
> wrote:
>>
>> I think this is a great idea! Do we have a Python/gcl/rietveld expert
>> who can tackle this?
>>
>> :DG<
>>
>> On
On Wed, Sep 23, 2009 at 12:33 PM, Ojan Vafai wrote:
> +pam, tc, darin in case they disagree with what I'm saying here.
>
> Also a bunch of current expectations would need to be modified. All
> the cases where there is currently FAIL would need to be changed to
> either FAIL or IMAGE or both if it
BTW, huge kudos to STP folks for jumping on that and getting it fixed.
Vitaly and Pavel, you are our secret weapon.
:DG<
On Thu, Sep 24, 2009 at 12:03 AM, Jeremy Orlow wrote:
> On Tue, Sep 22, 2009 at 6:10 PM, Jeremy Orlow wrote:
>>
>> There are 2 major issues here (besides leaving things for
Dear Finder-folks,
As you sift through lines in test_expectations.txt, you may discover
that some of them have bugs that are marked as duplicate or even
WontFix. Please don't let the crbug.com bug status fool you -- if they
are in test_expectations, they are still bugs. In such cases, please:
1)
To clarify: if a bug is marked as WONTFIX in test_expectations, it is
indeed a WontFix.
To summarize: always trust what's in test_expectations.txt.
:DG<
On Mon, Sep 28, 2009 at 11:00 AM, Dimitri Glazkov wrote:
> Dear Finder-folks,
>
> As you sift through lines in test_expe
Good point on HTML. Why not instead make DevTools
better/faster/do-what-you-want-them-to-do?
:DG<
On Tue, Sep 29, 2009 at 9:08 AM, Evan Martin wrote:
>
> I'd like to suggest early on that it's done in HTML for the usual
> reasons. (And also that there are the usual negatives. Just wanna
> pla
You've hit the laziness landmine :) The instructions on
http://code.google.com/p/chromium/wiki/UsingWebKitGit go like this:
1) see how to change your .gclient on
http://dev.chromium.org/developers/contributing-to-webkit (that is,
add the big custom_deps hunk)
2) then change first line to "Webkit:
Honestly -- haven't been actually doing anything in the past 3 weeks.
Still an AI to write up a proposal :)
:DG<
On Tue, Sep 29, 2009 at 1:08 PM, Marc-Antoine Ruel wrote:
> +Dimitri, who is doing that and didn't put Jeremy in the loop.
>
> On Tue, Sep 29, 2009 at 4:06 PM, Jeremy Orlow wrote:
>
+1 to "glowing hot" idea!
:DG<
On Wed, Oct 7, 2009 at 10:10 AM, Glen Murphy wrote:
>
> Something like yes! Maybe not a dialog, as I use things that peg my
> CPU (games) somewhat frequently.
>
> One idea we toyed with was marking such tabs as 'on fire' (icon or
> color), so at least there was a
On Tue, Sep 22, 2009 at 6:06 PM, Dimitri Glazkov wrote:
> Today wasn't a happy day for p...@. He did a seemingly innocuous roll
> that broke the world: selenium, ui tests, layout tests. I am sure it
> was stressful and probably added unnecessary gray to his hair.
>
> 2) writ
1 - 100 of 119 matches
Mail list logo
