On Apr 4, 2013, at 11:19 PM, "Ryosuke Niwa" wrote:
> Hi,
>
> This is somewhat related to the bulk move of Chromium-WebKit contributors to
> Blink, but we might want to consider sunsetting/expiring committership and
> reviewership.
>
> I'm thinking of something like expiring committership/rev
Am 05.04.2013 um 08:19 schrieb Ryosuke Niwa :
> Hi,
>
> This is somewhat related to the bulk move of Chromium-WebKit contributors to
> Blink, but we might want to consider sunsetting/expiring committership and
> reviewership.
> I'm thinking of something like expiring committership/reviwership
On Apr 5, 2013, at 2:19 AM, Ryosuke Niwa wrote:
> Hi,
>
> This is somewhat related to the bulk move of Chromium-WebKit contributors to
> Blink, but we might want to consider sunsetting/expiring committership and
> reviewership.
>
> I'm thinking of something like expiring committership/reviwer
I am not sure this is really needed. People sometimes disappear from
working on trunk for extended periods of time due to internal products
and downstream branches. It has happened multiple times to me. That
doesn't mean that I won't come back and start working upstream later.
Also it could be tha
Hi,
The Qt port of WebKit (based on Qt 5.x) does not use v8.
(Qt 5.x uses v8 in other places, but that is not relevant to the WebKit project
and this discussion)
Simon
Markus wrote:
> For the record though I don't think Qt is using any of that those.
Qt 5.x uses V8.
___
Hi,
This is somewhat related to the bulk move of Chromium-WebKit contributors
to Blink, but we might want to consider sunsetting/expiring committership
and reviewership.
I'm thinking of something like expiring committership/reviwership of a
person after the person didn't have any SVN activities f
On 04/04/2013 09:14 PM, Ryosuke Niwa wrote:
On the other hand, I don't think optimizing WebCore for JSC doesn't
necessarily mean it'll become impossible for you to have a custom build
of WebKit that uses some other binding code. For example, Mac has
Objective-C bindings and that's not going anyw
I've temporarily disabled testing on the commit queue in
http://trac.webkit.org/changeset/147695 since we haven't added enough
hardwares to keep up with patches.
I'll re-enable testing once we've got up to speed. Again, thanks for your
cooperation and patience.
Meanwhile, Let me know (just email
On Thu, Apr 4, 2013 at 7:08 PM, Maciej Stachowiak wrote:
> On Apr 4, 2013, at 4:54 PM, Per Bothner wrote:
>
> On 04/04/2013 10:21 AM, Oliver Hunt wrote:
>
> Supporting V8 places a considerable burden on webkit, there are a number of
> large, cumbersome and expensive abstractions required for to
On Thu, Apr 4, 2013 at 7:42 PM, Tim Horton wrote:
> We should probably sort out some of our known and solvable
> OS-version-dependent color profile bugs *before* attempting any mass
> rebaselines, to avoid having to do them twice.
>
That sounds like a reasonable approach. With ImageOnlyFailures
We should probably sort out some of our known and solvable OS-version-dependent
color profile bugs *before* attempting any mass rebaselines, to avoid having to
do them twice.
On Apr 4, 2013, at 7:37 PM, Benjamin Poulain wrote:
> On Thu, Apr 4, 2013 at 7:26 PM, Ryosuke Niwa wrote:
> Now that a
On Apr 4, 2013, at 7:37 PM, Benjamin Poulain wrote:
> On Thu, Apr 4, 2013 at 7:26 PM, Ryosuke Niwa wrote:
> Now that all Chromium contributors are gone to work on Blink, I'd expect we
> will have much lower rate of commits. We've also converted quite few tests to
> text-only or ref-tests over
On Thu, Apr 4, 2013 at 7:26 PM, Ryosuke Niwa wrote:
> Now that all Chromium contributors are gone to work on Blink, I'd expect
> we will have much lower rate of commits. We've also converted quite few
> tests to text-only or ref-tests over the years.
>
> Can we do some mass rebaselines and re-ena
Now that all Chromium contributors are gone to work on Blink, I'd expect we
will have much lower rate of commits. We've also converted quite few tests
to text-only or ref-tests over the years.
Can we do some mass rebaselines and re-enable pixel tests on Mac port now?
It's really bad to have no pi
On Apr 4, 2013, at 4:54 PM, Per Bothner wrote:
> On 04/04/2013 10:21 AM, Oliver Hunt wrote:
>> Supporting V8 places a considerable burden on webkit, there are a number of
>> large, cumbersome and expensive abstractions required for to support multiple
>> JS engines (see the original discussions
On Thu, Apr 4, 2013 at 6:01 PM, Markus wrote:
> > For the record though I don't think Qt is using any of that those.
>
> Qt 5.x uses V8.
QML uses V8. That does not matter for WebKit.
QtWebKit uses exclusively JSC.
Benjamin
___
webkit-dev mailing list
> For the record though I don't think Qt is using any of that those.
Qt 5.x uses V8.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
We've started our experimental mac-mountainlion commit queue 13 minutes ago.
We're going to add more machines once this one proved to be functional, and
patches started to pile up on the queue.
- R. Niwa
- R. Niwa
On Thu, Apr 4, 2013 at 3:00 PM, Ryosuke Niwa wrote:
> Hi all,
>
> Lucas and I
Supporting multiple JS engines is a major burden, and prevents us from doing
optimizations that more seamlessly bridge the gap between DOM and JSC. I
suspect we won't want to continue supporting multiple JS engines like we did
when the Chrome folks used WebKit with V8.
-Filip
On Apr 4, 2013,
On 04/04/2013 10:21 AM, Oliver Hunt wrote:
Supporting V8 places a considerable burden on webkit, there are a number of
large, cumbersome and expensive abstractions required for to support multiple
JS engines (see the original discussions on the topic from many years ago).
We at Oracle are worki
Hi Justin,
On Apr 4, 2013, at 2:37 PM, Justin Haygood wrote:
> The webkit.org instructions still reference Visual Studio 2005 for instance
We have full VS2010 support in SVN now; we haven't updated the instructions yet
as the build/test machines are not cut over yet.
> Any interest in making
Any update on the upcoming contributors meeting [1]? Logistics? Agenda?
[1] http://trac.webkit.org/wiki/May%202013%20Meeting
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
On Thu, Apr 4, 2013 at 3:09 PM, Justin Haygood
wrote:
> If Qt is the way to support Windows, it would need some work to make it
> easy to integrate into an existing non-Qt Windows application. From memory,
> that isn't the easiest thing in the world to do.
>
I don't know exactly what is the prob
We are also maintaining the WebKit1 Windows port at Apple.
On Apr 4, 2013, at 3:09 PM, Justin Haygood wrote:
> If Qt is the way to support Windows, it would need some work to make it easy
> to integrate into an existing non-Qt Windows application. From memory, that
> isn't the easiest thing i
If Qt is the way to support Windows, it would need some work to make it easy to
integrate into an existing non-Qt Windows application. From memory, that isn't
the easiest thing in the world to do.
From: Benjamin Poulain mailto:benja...@webkit.org>>
Date: Thursday, April 4, 2013 5:42 PM
To: Justi
Hi all,
Lucas and I are working hard to take over the ownership of the WebKit
commit queue today.
Thanks for your cooperation and patience.
- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webk
On Thu, Apr 4, 2013 at 2:37 PM, Justin Haygood
wrote:
> Considering Safari 6 is Mac only, and the departing of Chromium (the
> defacto Windows WebKit browser until yesterday) what is the current status
> of the Windows port?
>
> The webkit.org instructions still reference Visual Studio 2005 for
Considering Safari 6 is Mac only, and the departing of Chromium (the defacto
Windows WebKit browser until yesterday) what is the current status of the
Windows port?
The webkit.org instructions still reference Visual Studio 2005 for instance
Any interest in making it a first class citizen again
On Thu, Apr 4, 2013 at 12:50 PM, Geoffrey Garen wrote:
> To clarify:
>
> (1) The EWS bots are still running.
>
> (2) The mac and mac-wk2 EWS bots are running tests, and passing.
>
> (3) The cr-linux bots are running tests, and failing.
>
> If we're OK with item (3), we can go ahead with cleaning
Resent from the right address.
On Thu, Apr 4, 2013 at 1:09 PM, Eric Seidel wrote:
> We're ready to turn down the cr-linux EWS bots at your command.
>
> Just let us know (via email or #webkit). Thanks!
>
> On Thu, Apr 4, 2013 at 12:50 PM, Geoffrey Garen wrote:
>> To clarify:
>>
>> (1) The EWS bo
We're ready to turn down the cr-linux EWS bots at your command.
Just let us know (via email or #webkit). Thanks!
On Thu, Apr 4, 2013 at 12:50 PM, Geoffrey Garen wrote:
> To clarify:
>
> (1) The EWS bots are still running.
>
> (2) The mac and mac-wk2 EWS bots are running tests, and passing.
>
>
Hi,
On Apr 4, 2013, at 12:50 PM, Geoffrey Garen wrote:
> (3) The cr-linux bots are running tests, and failing.
>
> If we're OK with item (3), we can go ahead with cleaning house, and break the
> cr-* EWS bots entirely, while we work on making the mac and mac-wk2 EWS bots
> faster.
+1
-Brent
On Thu, Apr 4, 2013 at 1:50 PM, Geoffrey Garen wrote:
> To clarify:
>
> (1) The EWS bots are still running.
>
> (2) The mac and mac-wk2 EWS bots are running tests, and passing.
>
> (3) The cr-linux bots are running tests, and failing.
>
> If we're OK with item (3), we can go ahead with cleaning h
To clarify:
(1) The EWS bots are still running.
(2) The mac and mac-wk2 EWS bots are running tests, and passing.
(3) The cr-linux bots are running tests, and failing.
If we're OK with item (3), we can go ahead with cleaning house, and break the
cr-* EWS bots entirely, while we work on making t
On Thu, Apr 4, 2013 at 1:44 PM, Filip Pizlo wrote:
> Sent from my PDP-11
>
11/20? 11/40? RSX-11? RT-11? Love the split I/D memory on 11/70s.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
I think everyone is agreeing that we should have a suitable replacement for
EWS.
But I also want to see us move forward with clean ups. I think such clean ups
will bring clarity to what we would want our EWS testing to look like since
we'll have fewer configurations to test.
I like the appro
I may miss some mails, but I didn't see a proper reply for this mail.
Personally, I think WebKit and its community should also be grateful to
you guys. You did a lot for WebKit as well. Although the cooperation was
not always smooth, let's just keep the good memories. I wish you luck for
your Blin
Hi folks,
I definitely do not want to see the EWS system go away. But in the short term ,
I would be in favor of manual commits and manual testing.
We still have the build bots running tests, so it's not like we lose all
coverage.
Thanks,
-Brent
Sent from my iPhone
On Apr 4, 2013, at 11:56
On Thu, Apr 4, 2013 at 12:56 PM, Geoffrey Garen wrote:
> I'd also suggest purging the chromium layout tests ASAP so we can enjoy
>> the much-reduced archive sync costs.
>>
>
> We really need to get the Mac or Win EWS performing tests by default and
> reliably before doing this. At present, only t
> I'd also suggest purging the chromium layout tests ASAP so we can enjoy the
> much-reduced archive sync costs.
>
> We really need to get the Mac or Win EWS performing tests by default and
> reliably before doing this. At present, only the chromium-linux EWS bot has
> been consistently running
On Thu, Apr 4, 2013 at 11:10 AM, Glenn Adams wrote:
>
> On Thu, Apr 4, 2013 at 11:03 AM, Brent Fulgham wrote:
>
>> I'd also suggest purging the chromium layout tests ASAP so we can enjoy
>> the much-reduced archive sync costs.
>>
>
> We really need to get the Mac or Win EWS performing tests by d
On Thu, Apr 4, 2013 at 11:03 AM, Brent Fulgham wrote:
> I'd also suggest purging the chromium layout tests ASAP so we can enjoy
> the much-reduced archive sync costs.
>
We really need to get the Mac or Win EWS performing tests by default and
reliably before doing this. At present, only the chrom
On Apr 4, 2013, at 10:37 AM, Martin Robinson wrote:
> On Thu, Apr 4, 2013 at 10:34 AM, Geoffrey Garen wrote:
>> What would it take for WebKitGTK+ to adopt the JSC bindings?
>
> Just for clarity's sake. WebKitGTK+ only supports JSC, but it seems
> there are some external branches/forks using V8
Hi Martin.
> Just for clarity's sake. WebKitGTK+ only supports JSC, but it seems
> there are some external branches/forks using V8. In the past, we've
> rejected proposals to add V8 support to WebKitGTK+.
OK, I think that pretty much confirms that no WebKit contributors are
maintaining the v8 bi
> Is the process described in the
> DeprecatingFeatures article on the wiki still going to be followed?
Yes.
I'm generally talking about features that will fall under the "Cold turkey"
approach, based on rough consensus that they are either unsupported or unused.
Geoff
_
On Thu, Apr 4, 2013 at 10:34 AM, Geoffrey Garen wrote:
> What would it take for WebKitGTK+ to adopt the JSC bindings?
Just for clarity's sake. WebKitGTK+ only supports JSC, but it seems
there are some external branches/forks using V8. In the past, we've
rejected proposals to add V8 support to Web
Hi Mario.
> Here at Samsung we are using WebKitGTK+ and V8, and I bet we are not the
> only ones doing it, so it would be great to keep those guards there.
I've heard from others on the list, and I'd like to get your take on this, too.
Who do you envision maintaining the v8 bindings going forwar
Supporting V8 places a considerable burden on webkit, there are a number of
large, cumbersome and expensive abstractions required for to support multiple
JS engines (see the original discussions on the topic from many years ago).
Additionally we will only be supporting JSC in WebKit2, so I don't
On Apr 4, 2013, at 10:03 AM, Brent Fulgham wrote:
> I would strongly suggest purging V8, for the many performance and code
> complexity reasons Google is removing JSC from blink. (See
> www.chromium.org/blink/developer-faq)
+1
>
> I'd also suggest purging the chromium layout tests ASAP so
I would strongly suggest purging V8, for the many performance and code
complexity reasons Google is removing JSC from blink. (See
www.chromium.org/blink/developer-faq)
I'd also suggest purging the chromium layout tests ASAP so we can enjoy the
much-reduced archive sync costs.
-Brent
Sent from
On Apr 4, 2013, at 2:01 AM, Raphael Kubo da Costa wrote:
> Geoffrey Garen writes:
>
>> Also:
>> Adopt libc++
>
> My FreeBSD hat appreciates that, but can you elaborate? Is there
> something specific to libc++ not present in, say, libstdc++, that is
> going to be used?
I think this shoul
On Thu, Apr 4, 2013 at 3:56 AM, Mario Sanchez Prada wrote:
> > On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen
> wrote:
> > [...]
> > #if USE(V8)
> > #if !USE(JSC)
>
> Here at Samsung we are using WebKitGTK+ and V8, and I bet we are not the
> only ones doing it, so it would be grea
On 04/04/2013 03:15 PM, Gustavo Noronha Silva wrote:
Hey,
On Qui, 2013-04-04 at 01:22 -0700, Dirk Pranke wrote:
FWIW, mrobinson has been working on a GYP build for the GTK port, so I
wouldn't delete all of the .gyp files (at least not w/o them weighing
in on it). I thought there was some inter
Geoffrey Garen writes:
> Concepts we plan to remove:
> Features #defines that haven't gained traction
Do you already have anything in mind? Is the process described in the
DeprecatingFeatures article on the wiki still going to be followed?
--
Intel Finland Oy
Open Source Technology Center
> From: webkit-dev-boun...@lists.webkit.org
> [webkit-dev-boun...@lists.webkit.org] on behalf of Eric Seidel
> [e...@webkit.org]
> Sent: Thursday, April 04, 2013 9:41 AM
> To: Geoffrey Garen
> Cc: webkit-dev@lists.webkit.org Development
> Subject: Re: [webkit-dev] Cleaning House
>
> I considered
We'll be in #webkit and happy to be helpful in any way we can.
I considered posting patches to remove *Chromium files yesterday
afternoon, but then abarth reminded me that the commit-queue currently
uses chromium-linux. I spoke with rniwa at some length yesterday in
#webkit about transitioning th
Hey,
On Qui, 2013-04-04 at 01:22 -0700, Dirk Pranke wrote:
> FWIW, mrobinson has been working on a GYP build for the GTK port, so I
> wouldn't delete all of the .gyp files (at least not w/o them weighing
> in on it). I thought there was some interest at Apple in also using
> GYP, but perhaps thin
Hi,
> On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen
wrote:
> [...]
> #if USE(V8)
> #if !USE(JSC)
Here at Samsung we are using WebKitGTK+ and V8, and I bet we are not the
only ones doing it, so it would be great to keep those guards there.
> Geoff posted the list in part because
GoogleURL seems Chromium-specific, i.e. WTF_USE_GOOGLEURL is only defined
for Chromium in Source/WebCore/config.h.
Regards,
-Z
On Thu, Apr 4, 2013 at 10:50 AM, Maciej Stachowiak wrote:
>
> On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen
> wrote:
>
> On Thursday 04 April 2013, Geoffrey Garen
Geoffrey Garen writes:
> Also:
> Adopt libc++
My FreeBSD hat appreciates that, but can you elaborate? Is there
something specific to libc++ not present in, say, libstdc++, that is
going to be used?
--
Intel Finland Oy
Open Source Technology Center
On Thursday 04 April 2013, jpe...@gmx.at wrote:
> BlackBerry is moving away from Skia, a removal wouldn't hurt us at this
> point. With EFL being on cairo, it seems like that item can stay on the
> list.
>
Ah, right. Sorry for the confusion. I had the impression with all the places
Skia specific
On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen wrote:
> On Thursday 04 April 2013, Geoffrey Garen wrote:
>> Hi folks.
>>
>> Since we no longer need to support the Chromium port, let's take the
>> opportunity to streamline. Hopefully, this will make development easier
>> and more coherent for
BlackBerry is moving away from Skia, a removal wouldn't hurt us at this point. With EFL being on cairo, it seems like that item can stay on the list.- Jakob
Hi,
EFL port is using Cairo, not Skia.
Kr,
Christophe DUMEZ.
From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org]
on behalf of Allan Sandfeld Jensen [k...@carewolf.com]
Sent: Thursday, April 04, 2013 11:39
To: webkit-dev@lists.w
On Thursday 04 April 2013, Geoffrey Garen wrote:
> Hi folks.
>
> Since we no longer need to support the Chromium port, let's take the
> opportunity to streamline. Hopefully, this will make development easier
> and more coherent for everyone. Adam and Eric offered to do some of this
> cleanup, but
On Thu, Apr 4, 2013 at 12:30 AM, Geoffrey Garen wrote:
> Hi folks.
>
> Since we no longer need to support the Chromium port, let's take the
> opportunity to streamline. Hopefully, this will make development easier and
> more coherent for everyone. Adam and Eric offered to do some of this
> cleanu
Hi
My problem is that I have to extend Javascript in WebKit2. That is, I
have to add a set of global variables and functions. Potentially I
also need to add custom classes. However, this doesn't seem to be
possible in WebKit2 since it is not yet supported. Can you help me on
this matter?
--
Best
Hi folks.
Since we no longer need to support the Chromium port, let's take the
opportunity to streamline. Hopefully, this will make development easier and
more coherent for everyone. Adam and Eric offered to do some of this cleanup,
but I think it's healthier for people who will continue to be
68 matches
Mail list logo
