On Thu, Apr 4, 2013 at 9:18 PM, Ryosuke Niwa wrote:
> 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 you
On Friday, April 05, 2013 09:24:59 AM Geoffrey Garen wrote:
> Hi Mario.
>
> > First of all, let me say upfront that I see all the potential advantages
> > of
> > sticking to just one JS engine, and also perfectly understand the points
> > that most of the people here have made on favour of not sup
On Apr 5, 2013, at 5:25 AM, Mario Sanchez Prada wrote:
>
> Also, my mail was not really a formal request to keep the V8 bits around in
> the long term, but just a quick reply to the following comment from Maciej:
>
> """
> Geoff posted the list in part because we'd like to know
> If any of
On Friday 05 April 2013, Max Stepin wrote:
> > To me it looks more like it requires 0.3.0 to enable color correction.
> > Older ABIs are still supported.
>
> Yes, but some WebP images (created with 0.3.0) will not work.
> I tried, not even the first frame is displayed.
>
> Would it be OK to just
There are plenty of other bindings - Gtk has a set of dom bindings i believe,
there used to be COM (shudder) bindings as well, but those aren't the problem.
We could have as many binding languages as we want, there's no major
architectural reason not to.
But supporting javascript isn't simply
> To me it looks more like it requires 0.3.0 to enable color correction.
> Older ABIs are still supported.
Yes, but some WebP images (created with 0.3.0) will not work.
I tried, not even the first frame is displayed.
Would it be OK to just take future WEBPImageDecoder.cpp updates from Chromium?
_
On Friday 05 April 2013, Max Stepin wrote:
> Also, WebP project is unfinished state right now. This changeset requires
> libwebp version 0.3.0:
> https://trac.webkit.org/changeset/147048
>
To me it looks more like it requires 0.3.0 to enable color correction. Older
ABIs are still supported.
`All
Hi Mario.
> First of all, let me say upfront that I see all the potential advantages of
> sticking to just one JS engine, and also perfectly understand the points
> that most of the people here have made on favour of not supporting multiple
> engines.
>
> Also, my mail was not really a formal req
Also, WebP project is unfinished state right now. This changeset requires
libwebp version 0.3.0:
https://trac.webkit.org/changeset/147048
But version 0.3.0 also supports animated webp, and google doesn't have the
code for animation support in WEBPImageDecoder.cpp yet, not even in
Chromium.
So thi
On Qui, 2013-04-04 at 18:46 +0200, Balazs Kelemen 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 perh
Hi Geoff,
First of all, let me say upfront that I see all the potential advantages of
sticking to just one JS engine, and also perfectly understand the points
that most of the people here have made on favour of not supporting multiple
engines.
Also, my mail was not really a formal request to keep
Hi,
On Fri, Apr 5, 2013 at 12:19 AM, Benjamin Poulain wrote:
>
> I don't know exactly what is the problem with integrating Qt...but I think
> fixing that will be far less work than making a new WebKit2 port from
> scratch.
> WebKitGTK+ also run on Windows. But I don't know if it supports WebKit2.
On Fri, Apr 5, 2013 at 12:21 AM, Maciej Stachowiak wrote:
>
> 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.
>
>
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/reviw
Sent from my iPhone
On Apr 5, 2013, at 12:00 AM, "Ryosuke Niwa"
mailto:rn...@webkit.org>> wrote:
On Thu, Apr 4, 2013 at 11:53 PM, Kenneth Rohde Christiansen
mailto:kenneth.christian...@gmail.com>> wrote:
I am not sure this is really needed. People sometimes disappear from
working on trunk for
Sorry. Wrong address again.
On Fri, Apr 5, 2013 at 12:09 AM, Eric Seidel wrote:
> Neither here nor there, but...
>
> I had interest in sunsetting committers/reviewers in the past. There
> are loads of folks listed in committers.py who haven't committed or
> reviewed in 5+ years. I believe ther
Neither here nor there, but...
I had interest in sunsetting committers/reviewers in the past. There
are loads of folks listed in committers.py who haven't committed or
reviewed in 5+ years. I believe there are some old threads on
webkit-reviewers about such.
I believe the timeout for sunsetting
On Thu, Apr 4, 2013 at 11:56 PM, Nikolas Zimmermann <
zimmerm...@physik.rwth-aachen.de> wrote:
> 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
> c
On Thu, Apr 4, 2013 at 11:53 PM, Kenneth Rohde Christiansen <
kenneth.christian...@gmail.com> wrote:
> 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 t
19 matches
Mail list logo
