date:20150730

Re: [webkit-dev] Switching servers for EWS and flakiness dashboard

2015-07-30 Thread Aakash Jain

The upgrade was a success!  EWS and the Flakiness Dashboard are running 
smoothly. Please reply to this thread if you notice any issues.

New urls are:
https://webkit-queues.webkit.org/ 
https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html 


Thanks
Aakash

> On Jul 30, 2015, at 12:10 AM, Aakash Jain  wrote:
> 
> Hi All,
> 
> We are planning to switch to new servers for two of the apps: 
> EWS(webkit-queues.appspot.com) and flakiness dashboard 
> (http://webkit-test-results.appspot.com/dashboards/flakiness_dashboard.html). 
> It would be good to restart all the bots communicating with these apps to 
> ensure that they switch to new server. We will be handling most of the bots, 
> except the ones which we don't have the admin access to (e.g.: efl-wk2-ews 
> and gtk-wk2-ews). It would be great if the admins for these bots can do the 
> necessary.
> 
> We plan to commit the patch to switch the servers tomorrow early afternoon 
> (July 30, PST timezone) and restart the bots soon after. You can see more 
> details at https://bugs.webkit.org/show_bug.cgi?id=147178
> 
> For those who are interested in knowing more, we are switching the servers 
> since Google is depreciating one of the datastore model : master/slave 
> datastore (https://cloud.google.com/appengine/docs/deprecations/ms_datastore) 
> which these Apps were using. Going forward, we will be using AppScale which 
> is an open-source alternative to Google App Engine.
> 
> Thanks
> Aakash
> 

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

Re: [webkit-dev] border-radius lost when applying -webkit-filter

2015-07-30 Thread Vienneau, Christopher

Thanks for the info, I’m going to have to pause investigation on this for a 
bit.  When I pick up the investigation again, I think I’ll also see if the 
latest wincairo exhibits the same issue just to rule out any missing fixes 
(unless one of you have a recent build handy you can quickly validate?)  If 
wincairo is still reproducing the issue then I’m confident that we have some 
missing implementation to fill in on our end.

Thanks

Chris

From: Brent Fulgham [mailto:bfulg...@gmail.com]
Sent: Thursday, July 30, 2015 2:38 PM
To: Myles C. Maxfield; achristen...@apple.com
Cc: Vienneau, Christopher; Webkit Development List
Subject: Re: [webkit-dev] border-radius lost when applying -webkit-filter

I'll see if I can reproduce this using our Apple Windows port, which also uses 
GraphicsLayerCA, though one based on  Windows graphics primitives.

The WinCairo compositor is based on the OpenGL ES backend, via the ANGLE 
library. Alex Christensen knows more about how that works.

Thanks,

-Brent

Sent from my iPad

On Jul 30, 2015, at 2:26 PM, Myles C. Maxfield 
mailto:mmaxfi...@apple.com>> wrote:
I'm testing on the Mac OS X port, which uses GraphicsLayerCA.

Sounds like a bug with whichever compositor the win-cairo port is using, which 
I am not familiar with.

--Myles
On Jul 29, 2015, at 10:24 AM, Vienneau, Christopher 
mailto:cvienn...@ea.com>> wrote:

Thanks Myles,

Before I go through the effort of re-integrating, a few questions about your 
test:

Which port are you testing on? I had been able to repro in our demo and the 
win-cairo demo (both using the 179714 build).
Are you are using the GraphicsLayerCA as I mentioned below? If so regardless 
that your version is newer than mine, it *might* be why it’s working.

Chris

From: Myles C. Maxfield [mailto:mmaxfi...@apple.com]
Sent: Tuesday, July 28, 2015 5:36 PM
To: Vienneau, Christopher
Cc: Webkit Development List
Subject: Re: [webkit-dev] border-radius lost when applying -webkit-filter

This works for me using the latest ToT build. I would recommend updating your 
source tree.

--Myles
On Jul 28, 2015, at 4:52 PM, Vienneau, Christopher 
mailto:cvienn...@ea.com>> wrote:

Hi,

I’m on a slightly older pull from WebKit trunk (179714) and I’m seeing this 
issue where border radius is lost if a css filter is also applied.  My sample 
page looks like this:

Basic CSS Filters
Basic CSS Filters

#pic {
  border-radius: 10px;
  -webkit-filter: sepia(0.8);
}

When I run with the above code the image is rendered with the Sepi filter, but 
the border radius is not applied.  If I comment out the filter the image is 
properly rendered with the border radius applied.  By debugging I can see that 
a different code path is followed in the two cases.
Without the filter:
> WebKitd.dll!WebCore::GraphicsContext::clip(const WebCore::Path & 
> path, WebCore::WindRule windRule) Line 951C++
   WebKitd.dll!WebCore::GraphicsContext::clipRoundedRect(const 
WebCore::FloatRoundedRect & rect) Line 586 C++

WebKitd.dll!WebCore::RenderBoxModelObject::clipRoundedInnerRect(WebCore::GraphicsContext
 * context, const WebCore::FloatRect & rect, const WebCore::FloatRoundedRect & 
clipRect) Line 540  C++
   WebKitd.dll!WebCore::RenderReplaced::paint(WebCore::PaintInfo & 
paintInfo, const WebCore::LayoutPoint & paintOffset) Line 180  C++
…
we get into clipRoundedInnerRect which goes into the code which can perform the 
clipping operation, and all works as expected.

With the Filter (3 callstacks below):
> WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const 
> WebCore::FloatRoundedRect & roundedRect) Line 377  C++
   WebKitd.dll!WebCore::RenderLayerBacking::updateImageContents() 
Line 1960C++
   WebKitd.dll!WebCore::RenderLayerBacking::updateConfiguration() 
Line 595  C++

WebKitd.dll!WebCore::RenderLayerCompositor::rebuildCompositingLayerTree(WebCore::RenderLayer
 & layer, WTF::Vector & 
childLayersOfEnclosingLayer, int depth) Line 1522 C++
…

> WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const 
> WebCore::FloatRoundedRect & roundedRect) Line 377  C++
   WebKitd.dll!WebCore::RenderLayerBacking::resetContentsRect() 
Line 1124   C++

WebKitd.dll!WebCore::RenderLayerBacking::updateAfterDescendants() Line 1003 
 C++

WebKitd.dll!WebCore::RenderLayerCompositor::rebuildCompositingLayerTree(WebCore::RenderLayer
 & layer, WTF::Vector & 
childLayersOfEnclosingLayer, int depth) Line 1609 C++
…
> WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const 
> WebCore::FloatRoundedRect & roundedRect) Line 377  C++
   WebKitd.dll!WebCore::RenderLayerBacking::resetContentsRect() 
Line 1124   C++

WebKitd.dll!WebCore::RenderLayerBacking::updateAfterDescendants() Line 1003 
 C++

Re: [webkit-dev] border-radius lost when applying -webkit-filter

2015-07-30 Thread Brent Fulgham

I'll see if I can reproduce this using our Apple Windows port, which also uses 
GraphicsLayerCA, though one based on  Windows graphics primitives.

The WinCairo compositor is based on the OpenGL ES backend, via the ANGLE 
library. Alex Christensen knows more about how that works.

Thanks,

-Brent

Sent from my iPad

> On Jul 30, 2015, at 2:26 PM, Myles C. Maxfield  wrote:
> 
> I'm testing on the Mac OS X port, which uses GraphicsLayerCA.
> 
> Sounds like a bug with whichever compositor the win-cairo port is using, 
> which I am not familiar with.
> 
> --Myles
>> On Jul 29, 2015, at 10:24 AM, Vienneau, Christopher  wrote:
>> 
>> Thanks Myles,
>>  
>> Before I go through the effort of re-integrating, a few questions about your 
>> test:
>>  
>> Which port are you testing on? I had been able to repro in our demo and the 
>> win-cairo demo (both using the 179714 build). 
>> Are you are using the GraphicsLayerCA as I mentioned below? If so regardless 
>> that your version is newer than mine, it *might* be why it’s working.
>>  
>> Chris
>>  
>> From: Myles C. Maxfield [mailto:mmaxfi...@apple.com] 
>> Sent: Tuesday, July 28, 2015 5:36 PM
>> To: Vienneau, Christopher
>> Cc: Webkit Development List
>> Subject: Re: [webkit-dev] border-radius lost when applying -webkit-filter
>>  
>> This works for me using the latest ToT build. I would recommend updating 
>> your source tree.
>>  
>> --Myles
>> On Jul 28, 2015, at 4:52 PM, Vienneau, Christopher  wrote:
>>  
>> Hi,
>>  
>> I’m on a slightly older pull from WebKit trunk (179714) and I’m seeing this 
>> issue where border radius is lost if a css filter is also applied.  My 
>> sample page looks like this:
>> 
>>  
>> 
>> Basic CSS Filters
>> Basic CSS Filters
>>  
>> 
>> #pic {
>>   border-radius: 10px;
>>   -webkit-filter: sepia(0.8);
>> }
>> 
>>  
>> 
>> 
>>   
>> 
>> 
>> 
>>  
>> When I run with the above code the image is rendered with the Sepi filter, 
>> but the border radius is not applied.  If I comment out the filter the image 
>> is properly rendered with the border radius applied.  By debugging I can see 
>> that a different code path is followed in the two cases.  
>> Without the filter:
>> > WebKitd.dll!WebCore::GraphicsContext::clip(const WebCore::Path 
>> > & path, WebCore::WindRule windRule) Line 951C++
>>WebKitd.dll!WebCore::GraphicsContext::clipRoundedRect(const 
>> WebCore::FloatRoundedRect & rect) Line 586 C++
>>
>> WebKitd.dll!WebCore::RenderBoxModelObject::clipRoundedInnerRect(WebCore::GraphicsContext
>>  * context, const WebCore::FloatRect & rect, const WebCore::FloatRoundedRect 
>> & clipRect) Line 540  C++
>>WebKitd.dll!WebCore::RenderReplaced::paint(WebCore::PaintInfo 
>> & paintInfo, const WebCore::LayoutPoint & paintOffset) Line 180  C++
>> …
>> we get into clipRoundedInnerRect which goes into the code which can perform 
>> the clipping operation, and all works as expected.
>>  
>> With the Filter (3 callstacks below):
>> > 
>> > WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const 
>> > WebCore::FloatRoundedRect & roundedRect) Line 377  C++
>>
>> WebKitd.dll!WebCore::RenderLayerBacking::updateImageContents() Line 1960 
>>C++
>>
>> WebKitd.dll!WebCore::RenderLayerBacking::updateConfiguration() Line 595  
>> C++
>>
>> WebKitd.dll!WebCore::RenderLayerCompositor::rebuildCompositingLayerTree(WebCore::RenderLayer
>>  & layer, WTF::Vector & 
>> childLayersOfEnclosingLayer, int depth) Line 1522 C++
>> …
>>  
>> > 
>> > WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const 
>> > WebCore::FloatRoundedRect & roundedRect) Line 377  C++
>>WebKitd.dll!WebCore::RenderLayerBacking::resetContentsRect() 
>> Line 1124   C++
>>
>> WebKitd.dll!WebCore::RenderLayerBacking::updateAfterDescendants() Line 1003  
>> C++
>>
>> WebKitd.dll!WebCore::RenderLayerCompositor::rebuildCompositingLayerTree(WebCore::RenderLayer
>>  & layer, WTF::Vector & 
>> childLayersOfEnclosingLayer, int depth) Line 1609 C++
>> …
>> > 
>> > WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const 
>> > WebCore::FloatRoundedRect & roundedRect) Line 377  C++
>>WebKitd.dll!WebCore::RenderLayerBacking::resetContentsRect() 
>> Line 1124   C++
>>
>> WebKitd.dll!WebCore::RenderLayerBacking::updateAfterDescendants() Line 1003  
>> C++
>> 
>> WebKitd.dll!WebCore::RenderLayerCompositor::updateCompositingDescendantGeometry(WebCore::RenderLayer
>>  & compositingAncestor, WebCore::RenderLayer & layer, bool 
>> compositedChildrenOnly) Line 1862   C++
>> …
>>  
>> In this path we never call clipRoundedInnerRect, we do however call 
>> setContentsClippingRect with what looks like appropriate parameters to do 
>> what we would want

Re: [webkit-dev] Adding generated files to the Mac build

2015-07-30 Thread Benjamin Poulain


On 7/30/15 10:56 AM, Xabier Rodríguez Calvar wrote:

Maybe it is something very stupid that I am missing, but I added a new
IDL file, I added the object cpp and h files to the WebCore target, the
idl file to the corresponding list, etc, but when I build I get linking
errors caused by the non compilation of the generated JSxxxfile.cpp.
How do I add that? Do I have to really do it by hand?

Thanks for the help advance!


You need to add the cpp file in Xcode (WebCore->Derived Sources).

If you don't have Xcode, email me the bug number and I'll update your patch.


PS: Please, please, please, Alex, finish the migration to CMake :)


+1!

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

Re: [webkit-dev] border-radius lost when applying -webkit-filter

2015-07-30 Thread Myles C. Maxfield

I'm testing on the Mac OS X port, which uses GraphicsLayerCA.

Sounds like a bug with whichever compositor the win-cairo port is using, which 
I am not familiar with.

--Myles
> On Jul 29, 2015, at 10:24 AM, Vienneau, Christopher  wrote:
> 
> Thanks Myles,
>  
> Before I go through the effort of re-integrating, a few questions about your 
> test:
>  
> Which port are you testing on? I had been able to repro in our demo and the 
> win-cairo demo (both using the 179714 build). 
> Are you are using the GraphicsLayerCA as I mentioned below? If so regardless 
> that your version is newer than mine, it *might* be why it’s working.
>  
> Chris
>  
> From: Myles C. Maxfield [mailto:mmaxfi...@apple.com] 
> Sent: Tuesday, July 28, 2015 5:36 PM
> To: Vienneau, Christopher
> Cc: Webkit Development List
> Subject: Re: [webkit-dev] border-radius lost when applying -webkit-filter
>  
> This works for me using the latest ToT build. I would recommend updating your 
> source tree.
>  
> --Myles
> On Jul 28, 2015, at 4:52 PM, Vienneau, Christopher  > wrote:
>  
> Hi,
>  
> I’m on a slightly older pull from WebKit trunk (179714) and I’m seeing this 
> issue where border radius is lost if a css filter is also applied.  My sample 
> page looks like this:
> 
>  
> 
> Basic CSS Filters
> Basic CSS Filters
>  
> 
> #pic {
>   border-radius: 10px;
>   -webkit-filter: sepia(0.8);
> }
> 
>  
> 
> 
>   
> 
> 
> 
>  
> When I run with the above code the image is rendered with the Sepi filter, 
> but the border radius is not applied.  If I comment out the filter the image 
> is properly rendered with the border radius applied.  By debugging I can see 
> that a different code path is followed in the two cases.  
> Without the filter:
> > WebKitd.dll!WebCore::GraphicsContext::clip(const WebCore::Path 
> > & path, WebCore::WindRule windRule) Line 951C++
>WebKitd.dll!WebCore::GraphicsContext::clipRoundedRect(const 
> WebCore::FloatRoundedRect & rect) Line 586 C++
>
> WebKitd.dll!WebCore::RenderBoxModelObject::clipRoundedInnerRect(WebCore::GraphicsContext
>  * context, const WebCore::FloatRect & rect, const WebCore::FloatRoundedRect 
> & clipRect) Line 540  C++
>WebKitd.dll!WebCore::RenderReplaced::paint(WebCore::PaintInfo 
> & paintInfo, const WebCore::LayoutPoint & paintOffset) Line 180  C++
> …
> we get into clipRoundedInnerRect which goes into the code which can perform 
> the clipping operation, and all works as expected.
>  
> With the Filter (3 callstacks below):
> > 
> > WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const 
> > WebCore::FloatRoundedRect & roundedRect) Line 377  C++
>WebKitd.dll!WebCore::RenderLayerBacking::updateImageContents() 
> Line 1960C++
>WebKitd.dll!WebCore::RenderLayerBacking::updateConfiguration() 
> Line 595  C++
>
> WebKitd.dll!WebCore::RenderLayerCompositor::rebuildCompositingLayerTree(WebCore::RenderLayer
>  & layer, WTF::Vector & 
> childLayersOfEnclosingLayer, int depth) Line 1522 C++
> …
>  
> > 
> > WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const 
> > WebCore::FloatRoundedRect & roundedRect) Line 377  C++
>WebKitd.dll!WebCore::RenderLayerBacking::resetContentsRect() 
> Line 1124   C++
>
> WebKitd.dll!WebCore::RenderLayerBacking::updateAfterDescendants() Line 1003   
>C++
>
> WebKitd.dll!WebCore::RenderLayerCompositor::rebuildCompositingLayerTree(WebCore::RenderLayer
>  & layer, WTF::Vector & 
> childLayersOfEnclosingLayer, int depth) Line 1609 C++
> …
> > 
> > WebKitd.dll!WebCore::GraphicsLayer::setContentsClippingRect(const 
> > WebCore::FloatRoundedRect & roundedRect) Line 377  C++
>WebKitd.dll!WebCore::RenderLayerBacking::resetContentsRect() 
> Line 1124   C++
>
> WebKitd.dll!WebCore::RenderLayerBacking::updateAfterDescendants() Line 1003   
>C++
> 
> WebKitd.dll!WebCore::RenderLayerCompositor::updateCompositingDescendantGeometry(WebCore::RenderLayer
>  & compositingAncestor, WebCore::RenderLayer & layer, bool 
> compositedChildrenOnly) Line 1862   C++
> …
>  
> In this path we never call clipRoundedInnerRect, we do however call 
> setContentsClippingRect with what looks like appropriate parameters to do 
> what we would want.  However upon investigation it appears that this data is 
> not used by anything.  Looking at other ports it seems that 
> GraphicsLayerCA.cpp may be making use of this data in its clipping technique.
>  
> Looking for fixes that might already be available I found the two below 
> interesting, however note that I already have these in the change that we 
> last took.  They just sounds extremely similar to what I’m describing.
> http://trac.webkit.org/changeset/179147 
>

[webkit-dev] Adding generated files to the Mac build

2015-07-30 Thread Xabier Rodríguez Calvar

Hi,

Maybe it is something very stupid that I am missing, but I added a new
IDL file, I added the object cpp and h files to the WebCore target, the
idl file to the corresponding list, etc, but when I build I get linking
errors caused by the non compilation of the generated JSxxxfile.cpp.
How do I add that? Do I have to really do it by hand?

Thanks for the help advance!

PS: Please, please, please, Alex, finish the migration to CMake :)


signature.asc
Description: This is a digitally signed message part
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Switching servers for EWS and flakiness dashboard

2015-07-30 Thread Alexey Proskuryakov

Hi,

Which are the bots that you found missing?

I don't expect any changes to how frequently the dashboard code is updated just 
because of the switch. However, the code is in svn (Tools/TestResultServer), so 
you are encouraged to update the list a appropriate.

- Alexey



30 июля 2015 г., в 5:29, Carlos Alberto Lopez Perez  
написал(а):

> On 30/07/15 09:10, Aakash Jain wrote:
>> Hi All,
>> 
>> We are planning to switch to new servers for two of the apps:
>> EWS(webkit-queues.appspot.com) and flakiness dashboard
>> 
> (http://webkit-test-results.appspot.com/dashboard/flakiness_dashboard.html).
> 
> 
> Regarding the flakiness dashboard it has been without updating the list
> of available bots for a lng time.
> 
> In fact, I always recommend to run it locally to get results from the
> bots added in the last year(s):
> 
> "The Flakiness Dashboard that is online
> (webkit-test-results.appspot.com) is very outdated regarding the list of
> bots. You will do better by running the flakiness dashboard locally. To
> do that just open with a browser the file
> Tools/TestResultServer/static-dashboards/flakiness_dashboard.html (it
> may take a bit to load even if run locally because it fetches the json
> files with the data from webkit.org). " [1]
> 
> 
> I hope that with this switch to new servers the flakiness dashboard will
> be also updated more frequently.
> 
> 
>> It would be good to restart all the bots communicating with these
>> apps to ensure that they switch to new server. We will be handling
>> most of the bots, except the ones which we don't have the admin
>> access to (e.g.: efl-wk2-ews and gtk-wk2-ews). It would be great if
>> the admins for these bots can do the necessary.
> 
> I will take care of switching the GTK EWS bots as soon as the patch lands.
> 
> Regards.
> 
> 
> 
> [1] https://trac.webkit.org/wiki/WebKitGTK/Gardening/Howto
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] Switching servers for EWS and flakiness dashboard

2015-07-30 Thread Carlos Alberto Lopez Perez

On 30/07/15 09:10, Aakash Jain wrote:
> Hi All,
>
> We are planning to switch to new servers for two of the apps:
> EWS(webkit-queues.appspot.com) and flakiness dashboard
>
(http://webkit-test-results.appspot.com/dashboard/flakiness_dashboard.html).

Regarding the flakiness dashboard it has been without updating the list
of available bots for a lng time.

In fact, I always recommend to run it locally to get results from the
bots added in the last year(s):

"The Flakiness Dashboard that is online
(webkit-test-results.appspot.com) is very outdated regarding the list of
bots. You will do better by running the flakiness dashboard locally. To
do that just open with a browser the file
Tools/TestResultServer/static-dashboards/flakiness_dashboard.html (it
may take a bit to load even if run locally because it fetches the json
files with the data from webkit.org). " [1]

I hope that with this switch to new servers the flakiness dashboard will
be also updated more frequently.

> It would be good to restart all the bots communicating with these
> apps to ensure that they switch to new server. We will be handling
> most of the bots, except the ones which we don't have the admin
> access to (e.g.: efl-wk2-ews and gtk-wk2-ews). It would be great if
> the admins for these bots can do the necessary.

I will take care of switching the GTK EWS bots as soon as the patch lands.

Regards.

[1] https://trac.webkit.org/wiki/WebKitGTK/Gardening/Howto

signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Switching servers for EWS and flakiness dashboard

2015-07-30 Thread Gyuyoung Kim

Hi Aakash,

I will support to switch to the new server for efl-ews bots tomorrow.

Gyuyoung.

On Thu, Jul 30, 2015 at 4:10 PM, Aakash Jain  wrote:

> Hi All,
>
> We are planning to switch to new servers for two of the apps: EWS(
> webkit-queues.appspot.com) and flakiness dashboard (
> http://webkit-test-results.appspot.com/dashboards/flakiness_dashboard.html).
> It would be good to restart all the bots communicating with these apps to
> ensure that they switch to new server. We will be handling most of the
> bots, except the ones which we don't have the admin access to (e.g.:
> efl-wk2-ews and gtk-wk2-ews). It would be great if the admins for these
> bots can do the necessary.
>
> We plan to commit the patch to switch the servers tomorrow early afternoon
> (July 30, PST timezone) and restart the bots soon after. You can see more
> details at https://bugs.webkit.org/show_bug.cgi?id=147178
>
> For those who are interested in knowing more, we are switching the servers
> since Google is depreciating one of the datastore model : master/slave
> datastore (
> https://cloud.google.com/appengine/docs/deprecations/ms_datastore) which
> these Apps were using. Going forward, we will be using AppScale which is an
> open-source alternative to Google App Engine.
>
> Thanks
> Aakash
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Switching servers for EWS and flakiness dashboard

2015-07-30 Thread Aakash Jain

Hi All,

We are planning to switch to new servers for two of the apps: 
EWS(webkit-queues.appspot.com) and flakiness dashboard 
(http://webkit-test-results.appspot.com/dashboards/flakiness_dashboard.html). 
It would be good to restart all the bots communicating with these apps to 
ensure that they switch to new server. We will be handling most of the bots, 
except the ones which we don't have the admin access to (e.g.: efl-wk2-ews and 
gtk-wk2-ews). It would be great if the admins for these bots can do the 
necessary.

We plan to commit the patch to switch the servers tomorrow early afternoon 
(July 30, PST timezone) and restart the bots soon after. You can see more 
details at https://bugs.webkit.org/show_bug.cgi?id=147178

For those who are interested in knowing more, we are switching the servers 
since Google is depreciating one of the datastore model : master/slave 
datastore (https://cloud.google.com/appengine/docs/deprecations/ms_datastore) 
which these Apps were using. Going forward, we will be using AppScale which is 
an open-source alternative to Google App Engine.

Thanks
Aakash

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

Re: [webkit-dev] Switching servers for EWS and flakiness dashboard

Re: [webkit-dev] border-radius lost when applying -webkit-filter

Re: [webkit-dev] border-radius lost when applying -webkit-filter

Re: [webkit-dev] Adding generated files to the Mac build

Re: [webkit-dev] border-radius lost when applying -webkit-filter

[webkit-dev] Adding generated files to the Mac build

Re: [webkit-dev] Switching servers for EWS and flakiness dashboard

Re: [webkit-dev] Switching servers for EWS and flakiness dashboard

Re: [webkit-dev] Switching servers for EWS and flakiness dashboard

[webkit-dev] Switching servers for EWS and flakiness dashboard

10 matches

Site Navigation

Mail list logo

Footer information