[webkit-dev] WebKit2 component in Bugzilla

2010-07-08 Thread Zoltan Horvath 
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

Re: [webkit-dev] WebKit2 build system

2010-07-08 Thread Balazs Kelemen 
On 07/07/2010 07:27 PM, Sam Weinig wrote:
> Hi. 
>
> On Wed, Jul 7, 2010 at 7:02 AM, Balazs Kelemen  > 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 common parts of WebKit2
> should change, that is why I thought that discussing them in the list
> would be useful.
> There are two main problem I see:
>  * Usage of precompiled header. Without using WebKitPrefix.h as a
> precompiled header it seems like includes are broken. The reason why I
> dislike precompiled header is that distcc does not support it.
>
>
> It should not be necessary to use WebKitPrefix.h as a precompiled
> header, it is only necessary for it to be used a prefix header.  Does
> discc also not support prefix headers?

The config.h in JavaScriptCore and WebCore is there for similar purposes
as this prefix header. Why don't we use this one in the same way? This
would solve our problems with distcc and icecc.

>  
>
>  * Include paths. The common files in WebKit2 includes headers in the
> form #include  while the real place of the file is for
> example WebKit2/UIProcess/API/C/xyz.h. We can workaround the
> problem by
> copying headers into the build dir and set the includepath to contain
> it, but I do not think it is a good practice.
>
>
> We should probably change the mac to have forwarding headers (as we do
> with WebCore for JavaScriptCore) to avoid this.
>
>
That would be great. I have started to create them.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Add WebKit EFL component on Bugzilla

2010-07-08 Thread Gustavo Sverzut Barbieri 
On Wed, Jun 30, 2010 at 4:08 PM, Leandro Pereira  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
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebKit2 component in Bugzilla

2010-07-08 Thread Adam Roben 
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
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Add WebKit EFL component on Bugzilla

2010-07-08 Thread Adam Roben 
On Jul 8, 2010, at 8:40 AM, Gustavo Sverzut Barbieri wrote:

> On Wed, Jun 30, 2010 at 4:08 PM, Leandro Pereira  
> wrote:
>> Hi.
>> 
>> Could anyone please add a WebKit EFL component on Bugzilla?
> 
> Anyone could handle this?

Done.

-Adam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior

2010-07-08 Thread Adam Barth 
On Wed, Jul 7, 2010 at 7:29 PM, Maciej Stachowiak  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 that's the main negative of the commit-queue, we can make it as
agressive at landing patches as we want.  We started out with a very
conservative design, so there are a bunch of knobs to turn:

1) Currently the commit-queue only lands a patch if there were no
commits between when it updated its working copy and when the tests
finish.  This check is to avoid the possibility of another change
sneaking in that causes problems (e.g., a change to another file that
conflicts semantically).  The error case is probably very rare and
might not be worth worrying about, but generally mean the commit-queue
doesn't land during times when the tree is busy.

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 introducing new failures that are masked by existing failures.

3) Currently the commit-queue lands each patch individually.  We could
instead stack up a bunch of commits in a git branch and build/test
them all at once.  (Potentially this could be a massive increase in
throughput.)  We do this to space out the commits so that they
generally get separate buildbot runs, which makes failures easier to
localize.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior

2010-07-08 Thread Xan Lopez 
On Thu, Jul 8, 2010 at 7:54 PM, Adam Barth  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 introducing new failures that are masked by existing failures.

commit-queue has been pushing stuff all day and many core bots have
been red since yesterday. How is this possible? 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)

>
> 3) Currently the commit-queue lands each patch individually.  We could
> instead stack up a bunch of commits in a git branch and build/test
> them all at once.  (Potentially this could be a massive increase in
> throughput.)  We do this to space out the commits so that they
> generally get separate buildbot runs, which makes failures easier to
> localize.
>
> Adam
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] DerivedSources.make & CPP DOM Bindings

2010-07-08 Thread Kevin Ollivier 
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, and it's where I've put 
things for now, but I wasn't sure if others would feel this is the right place. 
If I do add it, what is the appropriate way to do it? Should generation be 
conditional on some define the port will set, like MAKE_CPP_BINDINGS, or should 
we just directly check for BUILDING_ defines?

Thoughts?

Thanks,

Kevin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Trees on fire, how commit-bot does and does not help

2010-07-08 Thread Darin Adler 
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 could use some help diagnosing 
what’s going wrong on various platforms.

The discussion of the commit-bot overlooks the fact that the bot does not 
prevent problems like this, ones that affect only certain platforms.

I think we‘re conflating things here. The commit bot enforces one particular 
item; it makes sure all the layout tests pass on a single platform. But few of 
the real world problems I end up dealing with fall into that category.

The reason the commit-bot doesn’t work for me is that it randomizes the time my 
patch lands, and makes it hard for me to be there at that time to follow up 
with what we learn from all the other bots.

What could solve that would be a much fancier version of the early warning 
system that could do all the same testing that the build bots do, before 
checking in. The most useful form of that would be something not built into the 
commit bot, but something designed to be useful for iterative development.

-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior

2010-07-08 Thread Adam Barth 
On Thu, Jul 8, 2010 at 10:58 AM, Xan Lopez  wrote:
> On Thu, Jul 8, 2010 at 7:54 PM, Adam Barth  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 introducing new failures that are masked by existing failures.
>
> commit-queue has been pushing stuff all day and many core bots have
> been red since yesterday. How is this possible?

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 itself.  When we were waiting for all the
core builders to be green, the commit-queue usually had to wait for me
or Eric or another contributor to clean up the entire tree and ping
the folks who maintain bots that had gotten sick.

My view is, generally, that the commit-queue should act like a
contentious committer, which means it should act the way most
committers act.  Given that folks generally don't wait for all the
bots to be green before committing, I felt this change was worth
experimenting with.  (Note that sheriff-bot still monitors all the
core builders and alerts folks of bustage.)

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior

2010-07-08 Thread Xan Lopez 
On Thu, Jul 8, 2010 at 8:09 PM, Adam Barth  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 itself.  When we were waiting for all the
> core builders to be green, the commit-queue usually had to wait for me
> or Eric or another contributor to clean up the entire tree and ping
> the folks who maintain bots that had gotten sick.
>
> My view is, generally, that the commit-queue should act like a
> contentious committer, which means it should act the way most
> committers act.  Given that folks generally don't wait for all the
> bots to be green before committing, I felt this change was worth
> experimenting with.  (Note that sheriff-bot still monitors all the
> core builders and alerts folks of bustage.)

I see, I interpreted you meant it saw 100% passing tests in the core
bots (as it used to be). The new behavior seems to make it easier to
go back to how things were before, when as soon as one port (say GTK+)
breaks, people will keep piling things on top and if nobody is around
at that moment then it's much harder to figure out what happened, who
was responsible, etc, because you only get clear data of the first
breakage.

So, not a fan.

Of course I see the point that you make about most people committing
manually doing the same thing, but maybe we should create a rule of
not committing code touching all ports if any of the trees is red.
That would improve things, I feel this switch won't do that.

Xan

>
> Adam
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Trees on fire, how commit-bot does and does not help

2010-07-08 Thread Adam Barth 
On Thu, Jul 8, 2010 at 11:05 AM, Darin Adler  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 
>> https://bugs.webkit.org/show_bug.cgi?id=41823)
>
> Yes, I’ll be working on this more today. I could use some help diagnosing 
> what’s going wrong on various platforms.
>
> The discussion of the commit-bot overlooks the fact that the bot does not 
> prevent problems like this, ones that affect only certain platforms.
>
> I think we‘re conflating things here. The commit bot enforces one particular 
> item; it makes sure all the layout tests pass on a single platform. But few 
> of the real world problems I end up dealing with fall into that category.
>
> The reason the commit-bot doesn’t work for me is that it randomizes the time 
> my patch lands, and makes it hard for me to be there at that time to follow 
> up with what we learn from all the other bots.
>
> What could solve that would be a much fancier version of the early warning 
> system that could do all the same testing that the build bots do, before 
> checking in. The most useful form of that would be something not built into 
> the commit bot, but something designed to be useful for iterative development.

Yeah, I definitely agree that try servers would be useful.  I think
it's a matter of setting up a second buildbot master configured for
try jobs and attaching slaves.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?

2010-07-08 Thread Dmitry Titov 
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  wrote:

> That would be the standard thing to do.
>
> The sooner someone gets started on the feature, the easier it'll be to
> revert the patch that removes the code.  :-)
>
> J
>
> On Thu, Jul 8, 2010 at 10:55 AM, David Levin  wrote:
>
>>
>>
>> On Wed, Jul 7, 2010 at 5:24 PM, Peter Kasting wrote:
>>
>>> On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov wrote:
>>>
 I'd lean to the removal, unless there is a port that has work ongoing or
 planned soon for those implementations.

 Does anybody vote for #ifdefs?

>>>
>>> I vote against removal if only because Chromium has really wanted these
>>> badly for a long time and simply hasn't been able to find someone to
>>> implement them.  Perhaps I could make it worth your while to implement
>>> rather than remove the stubs?  :)
>>>
>>
>> *Even if someone to implement them for chromium, it doesn't seem to fix
>> the overall problem. *Dmitry indicated that the presences of these is
>> breaking feature detection in browsers using WebKit (-- which is something
>> being heard from web developers).
>>
>> A simple solution is to remove them. Later, any port (including chromium)
>> who gets someone to work on them could re-add these methods back properly
>> under ifdef's.
>>
>> dave
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior

2010-07-08 Thread Jeremy Orlow 
On Fri, Jul 9, 2010 at 2:14 AM, Xan Lopez  wrote:

> On Thu, Jul 8, 2010 at 8:09 PM, Adam Barth  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 itself.  When we were waiting for all the
> > core builders to be green, the commit-queue usually had to wait for me
> > or Eric or another contributor to clean up the entire tree and ping
> > the folks who maintain bots that had gotten sick.
> >
> > My view is, generally, that the commit-queue should act like a
> > contentious committer, which means it should act the way most
> > committers act.  Given that folks generally don't wait for all the
> > bots to be green before committing, I felt this change was worth
> > experimenting with.  (Note that sheriff-bot still monitors all the
> > core builders and alerts folks of bustage.)
>
> I see, I interpreted you meant it saw 100% passing tests in the core
> bots (as it used to be). The new behavior seems to make it easier to
> go back to how things were before, when as soon as one port (say GTK+)
> breaks, people will keep piling things on top and if nobody is around
> at that moment then it's much harder to figure out what happened, who
> was responsible, etc, because you only get clear data of the first
> breakage.
>
> So, not a fan.
>
> Of course I see the point that you make about most people committing
> manually doing the same thing, but maybe we should create a rule of
> not committing code touching all ports if any of the trees is red.
> That would improve things, I feel this switch won't do that.
>

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.

If you think we should all follow such a policy, well that's an entirely
different topic.  And one that seems to keep coming up.  If you want to
raise it again, you should probably start by looking at the archives.

J
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Trees on fire

2010-07-08 Thread Darin Adler 
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. The fixes in reverse 
chronological order:

Leopard bot: http://trac.webkit.org/changeset/62842 
http://trac.webkit.org/changeset/62845 http://trac.webkit.org/changeset/62847
GTK bot: http://trac.webkit.org/changeset/62832
WebKit2: http://trac.webkit.org/changeset/62797
Chromium bots and IDB: http://trac.webkit.org/changeset/62791 
http://trac.webkit.org/changeset/62795

-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior

2010-07-08 Thread Xan Lopez 
On Thu, Jul 8, 2010 at 11:38 PM, Jeremy Orlow  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.

I don't see this particular point being made by anyone in the thread.
Who are you referring to? In any case I'm not quite sure I follow the
logic of downgrading machines to a lesser standard of quality just
because this is what humans tend to do.

> If you think we should all follow such a policy, well that's an entirely
> different topic.  And one that seems to keep coming up.  If you want to
> raise it again, you should probably start by looking at the archives.

Fair enough. My point was mostly about undoing the change to cq, not
creating new rules for committers in general.

> J
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Web SQL Database API - openDatabaseSync

2010-07-08 Thread Evan Ireland 
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 write:

function formatEmployee(e)
{
return e.getName() + ", " + e.getDepartment().getName();
}
alert(formatEmployee(Employee.find(123));

Forgive my using "alert", just for the purpose of example.

Now suppose that e.getDepartment() call (child to parent navigation) needs
to be asynchronous due to lazy loading.

Now I need something like:

function formatEmployee(e, success, failure)
{
e.getDepartment
(
function(d)
{
success(e.getName() + ", " + d.getName());
},
failure
);
}
Employee.find
(
123,
function(e)
{
formatEmployee
(
e,
function(s) { alert(s); },
function() { /* ignore failure */ }
)
},
function() { /* ignore failure */ }
);

Is soon gets very nasty. I do appreciate how to program in a
continuation-passing style, which can be easier with good language support
(e.g. Haskell). But just imagine if the '+' operator was asynchronous, how
much more trouble ordinary programming would be.

In any case, I can accept that using synchronous DB API in the UI thread
could be considered undesirable.
Using it from a worker thread however is essential. To get good
composability, I might wish to run business objects in a worker thread using
a synchronous API rather than using an asynchronous API from the UI thread.

I hope this helps to clarify where I am coming from with my questions.

-Original Message-
From: Dmitry Titov [mailto:dim...@google.com] 
Sent: Thursday, July 08, 2010 2:27 PM
To: Evan Ireland
Cc: Andrei Popescu; Eric Uhrhane; webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Web SQL Database API - openDatabaseSync

On Tue, Jul 6, 2010 at 10:00 AM, Evan Ireland  wrote:

> Andrei,
>
> On page:
>
>  http://www.ibm.com/developerworks/library/x-html5mobile4/
>
> I see:
>
>  "Starting with Android 2.0, the Android browser has had full support for
> the HTML 5 Web Worker specification."
>
> Is the quoted page incorrect about Web Workers on Android? (It seems to
> contradict what you wrote below).
>
> I was hoping to do some prototyping with Web Workers and Google Gears on
> Android until such time as the sync database API is available. But perhaps
> I
> will need to limit testing to desktop Chrome for the moment.
>

I'd be curious what benefit the synchronous version of API gives? Isn't it
useful to keep even the workers responsive to PostMessage from UI thread, as
opposite to accumulating a ton of posted messages and then receiving them in
a rapid-fire in the worker after a sync API returns? What if it never
returns (the database is locked or who knows)? I don't know what you are
building of course, but using async code everywhere doesn't look like a
terrible choice. Or does it? :-) Just curious.



>
> -Original Message-
> From: Andrei Popescu [mailto:andr...@google.com]
> Sent: Friday, July 02, 2010 3:54 AM
> To: Eric Uhrhane
> Cc: Evan Ireland; webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] Web SQL Database API - openDatabaseSync
>
> Hi,
>
> On Fri, Jul 2, 2010 at 2:40 AM, Eric Uhrhane  wrote:
> > I doubt that it's been pushed to any Android phone yet.  It only went
> > into webkit in the past couple of months, and there's a bit of lag as
> > they incorporate new code.  You'd have to ask Android folks when they
> > plan to ship it.
> >
>
> Async Web SQL Database is available on Android since version 2.0.
>
> Sync Web SQL Database and Web Workers are not currently available on
> Android (not even on 2.2).
>
> Thanks,
> Andrei
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior

2010-07-08 Thread Daniel Cheng 
On Thu, Jul 8, 2010 at 14:55, Xan Lopez  wrote:

> On Thu, Jul 8, 2010 at 11:38 PM, Jeremy Orlow  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.
>
> I don't see this particular point being made by anyone in the thread.
> Who are you referring to? In any case I'm not quite sure I follow the
> logic of downgrading machines to a lesser standard of quality just
> because this is what humans tend to do.
>
> > If you think we should all follow such a policy, well that's an entirely
> > different topic.  And one that seems to keep coming up.  If you want to
> > raise it again, you should probably start by looking at the archives.
>
> Fair enough. My point was mostly about undoing the change to cq, not
> creating new rules for committers in general.
>

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 that
the CQ is behind and commit directly instead, so the tree stays on fire and
the CQ gets even further behind. I don't care if the commit queue behavior
is reverted, but if it is, it'd be really nice if committers tried to follow
the same commit policy as the bot.


>
> > J
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior

2010-07-08 Thread Xan Lopez 
On Fri, Jul 9, 2010 at 12:30 AM, Daniel Cheng  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 that
> the CQ is behind and commit directly instead, so the tree stays on fire and
> the CQ gets even further behind. I don't care if the commit queue behavior
> is reverted, but if it is, it'd be really nice if committers tried to follow
> the same commit policy as the bot.

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 core-builders are repeatedly red for days on end this is something
we should address instead of adding workarounds so that people can
keep working without paying attention to it. It has been noted that
this is an often visited topic and off-topic to the thread, though.

Xan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior

2010-07-08 Thread Daniel Cheng 
On Thu, Jul 8, 2010 at 15:38, Xan Lopez  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 core-builders are repeatedly red for days on end this is something
> we should address instead of adding workarounds so that people can
> keep working without paying attention to it. It has been noted that
> this is an often visited topic and off-topic to the thread, though.
>
> Xan
>

What I'm saying is that if the commit queue behavior is reverted, there
ought to be some sort of policy (strong suggestion? rule?) in place for
committers to discourage committing on top of a red tree as well. Maybe
there's already one, but it's not strongly enforced and it's very easy to
ignore if you just want to land your patch and start working on something
else. For what it's worth, it was especially frustrating for me since I was
only updating an interface in the Chromium platform layer and the 3 day
delay blocked me from landing any of the associated patches on the Chromium
side.

Daniel
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Python-based unit tests for wx port

2010-07-08 Thread Kevin Ollivier 
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 giving me some 
pointers about where in the tree I should put my tests and how best to 
integrate them with the overall testing system?

Thanks,

Kevin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Frustrated at inconsiderate behavior

2010-07-08 Thread David Levin 
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
builder is red unless if the builder been red for >= 12 hours. (Of course,
someone would have to code and I'm not sure if this could be easily this
could be determined). Also, we'd have to be aggressive about what btos would
be included in this list.

dave


On Thu, Jul 8, 2010 at 3:49 PM, Daniel Cheng  wrote:

> On Thu, Jul 8, 2010 at 15:38, Xan Lopez  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 core-builders are repeatedly red for days on end this is something
>> we should address instead of adding workarounds so that people can
>> keep working without paying attention to it. It has been noted that
>> this is an often visited topic and off-topic to the thread, though.
>>
>> Xan
>>
>
> What I'm saying is that if the commit queue behavior is reverted, there
> ought to be some sort of policy (strong suggestion? rule?) in place for
> committers to discourage committing on top of a red tree as well. Maybe
> there's already one, but it's not strongly enforced and it's very easy to
> ignore if you just want to land your patch and start working on something
> else. For what it's worth, it was especially frustrating for me since I was
> only updating an interface in the Chromium platform layer and the 3 day
> delay blocked me from landing any of the associated patches on the Chromium
> side.
>
> Daniel
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev