Hey,
I think it would be good to create a WebKit2 component for bug reports in
Bugzilla. Could someone create it please?
Regards,
Zoltan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On 07/07/2010 07:27 PM, Sam Weinig wrote:
Hi.
On Wed, Jul 7, 2010 at 7:02 AM, Balazs Kelemen k...@inf.u-szeged.hu
mailto:k...@inf.u-szeged.hu wrote:
Hi folks!
While I worked on the Qt port of WebKit2, I faced with some build
issues. To solve these problems it seems like
On Wed, Jun 30, 2010 at 4:08 PM, Leandro Pereira lean...@profusion.mobi wrote:
Hi.
Could anyone please add a WebKit EFL component on Bugzilla?
Anyone could handle this?
(I see that people requested WebKit2 component, so the one doing it
could do EFL as well?)
--
Gustavo Sverzut Barbieri
On Jul 8, 2010, at 4:14 AM, Zoltan Horvath wrote:
I think it would be good to create a WebKit2 component for bug reports in
Bugzilla. Could someone create it please?
Done.
-Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
On Jul 8, 2010, at 8:40 AM, Gustavo Sverzut Barbieri wrote:
On Wed, Jun 30, 2010 at 4:08 PM, Leandro Pereira lean...@profusion.mobi
wrote:
Hi.
Could anyone please add a WebKit EFL component on Bugzilla?
Anyone could handle this?
Done.
-Adam
On Wed, Jul 7, 2010 at 7:29 PM, Maciej Stachowiak m...@apple.com wrote:
One negative externality is that it
sometimes makes people excessively upset about tree redness, and sometimes
makes them want to fix redness in a way that papers over problems (e.g. by
adding to the skipped list).
If
On Thu, Jul 8, 2010 at 7:54 PM, Adam Barth aba...@webkit.org wrote:
2) Currently the commit-queue only lands if it gets a 100% passing run
of all the tests. We could instead change it to land if there are no
new test failures as a result of applying the patch. This check is to
avoid
Hi all,
I'm working on making the CPP DOM bindings accessible to the wx port, and while
I've got the whole thing building, one thing I have yet to sort out is how to
add building of the CPP DOM bindings to the build system. DerivedSources.make
seems to be the appropriate place to put the code,
On Jul 8, 2010, at 10:58 AM, Xan Lopez wrote:
Oh, and might this serve as a ping for whoever set the trees on fire... at
least some of it seems related to the refPtr work that's been going on (see
https://bugs.webkit.org/show_bug.cgi?id=41823)
Yes, I’ll be working on this more today. I
On Thu, Jul 8, 2010 at 10:58 AM, Xan Lopez x...@gnome.org wrote:
On Thu, Jul 8, 2010 at 7:54 PM, Adam Barth aba...@webkit.org wrote:
2) Currently the commit-queue only lands if it gets a 100% passing run
of all the tests. We could instead change it to land if there are no
new test failures
On Thu, Jul 8, 2010 at 8:09 PM, Adam Barth aba...@webkit.org wrote:
Originally, we had the commit-queue to land only if all the core
builders were green. One recent change we made to make the
commit-queue more agressive is to land when the commit-queue itself
sees 100% passing tests on
On Thu, Jul 8, 2010 at 11:05 AM, Darin Adler da...@apple.com wrote:
On Jul 8, 2010, at 10:58 AM, Xan Lopez wrote:
Oh, and might this serve as a ping for whoever set the trees on fire... at
least some of it seems related to the refPtr work that's been going on (see
Thanks to all,
the bug is here: https://bugs.webkit.org/show_bug.cgi?id=41878
I've added link to tracking Chromium bug as well.
Dmitry
On Wed, Jul 7, 2010 at 7:59 PM, Jeremy Orlow jor...@chromium.org wrote:
That would be the standard thing to do.
The sooner someone gets started on the
On Fri, Jul 9, 2010 at 2:14 AM, Xan Lopez x...@gnome.org wrote:
On Thu, Jul 8, 2010 at 8:09 PM, Adam Barth aba...@webkit.org wrote:
Originally, we had the commit-queue to land only if all the core
builders were green. One recent change we made to make the
commit-queue more agressive is to
On Jul 8, 2010, at 11:05 AM, Darin Adler wrote:
Yes, I’ll be working on this more today. I could use some help diagnosing
what’s going wrong on various platforms.
Most of the problems caused by the adoptRef change should be fixed now. Just
need to wait for the bots to catch up and see that.
On Thu, Jul 8, 2010 at 11:38 PM, Jeremy Orlow jor...@chromium.org wrote:
I think the point that's been made in this thread is that whatever policy
the commit queue uses should be in line with whatever policies all
committers should be using. Otherwise you run into the problems Maciej
noted.
Dmitry,
The asynchronous API makes composition much more difficult. Like if we
generate code that wraps the database API into business objects, all the
business object methods need to accept callback parameters.
Suppose I want to show an employee together with their department name, I
could
On Thu, Jul 8, 2010 at 14:55, Xan Lopez x...@gnome.org wrote:
On Thu, Jul 8, 2010 at 11:38 PM, Jeremy Orlow jor...@chromium.org wrote:
I think the point that's been made in this thread is that whatever policy
the commit queue uses should be in line with whatever policies all
committers
On Fri, Jul 9, 2010 at 12:30 AM, Daniel Cheng dch...@chromium.org wrote:
As someone who doesn't have committer access, I like the change to the CQ.
Before, I might have to wait 3 days for a patch to land since the CQ would
wait for all the core builders to be green. Meanwhile, committers see
On Thu, Jul 8, 2010 at 15:38, Xan Lopez x...@gnome.org wrote:
Aren't you essentially saying that you like the change because it
allows you to join the fun of adding code to already broken trees?
Again, I don't see how this helps us to move towards
as-greener-as-possible trees.
If
Hi all,
I'd like to start adding some wx-specific tests for our port's API, at least
initially using Python, and since I've noticed a lot of changes being made to
the testing infrastructure over the past few months or so (Perl - Python
transition, etc.), I was wondering if someone would mind
What I noticed wrt the commit queue is that when a core build is broken
continuously for days (like what happened with the Chromium Linux bot
earlier this week for example), it causes big problems for the commit queue.
Perhaps a 12 hour rule would be sufficient -- the cq doesn't submit if a
22 matches
Mail list logo