Bear Travis | 29 Jul 19:42 2014
Picon

Updating and Enabling the CSS Font Loading Spec

Hi All,

WebKit has support for an older version of the CSS Font Loading Specification [1], implemented back in 2013 [2]. I would like to bring this work in line with the current version of the specification, and enable it by default in the nightlies. The specification provides support for coordinating font loading: querying if fonts have loaded, requesting specific fonts to load, and providing notifications as fonts are loading.

Other browsers have a positive outlook on the feature. Chrome has already shipped it [3], and Mozilla is in the process of implementing it [4].

Please let me know if you have any questions, comments, or concerns.
-Bear

[1] http://dev.w3.org/csswg/css-font-loading/
[2] https://bugs.webkit.org/show_bug.cgi?id=98395
[3] http://www.chromestatus.com/features/6244676289953792
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=835247
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
David Farler | 28 Jul 21:47 2014
Picon

Swift in WebKit

Hello all,

I have the following bug to help build out support for layout tests in the iOS Simulator.

iOS Simulator LayoutTestRelay

I'd like to include this as a new tool written in Swift.

Why I think it's fine in this case:
- This tool is specific to the iOS and OS X platforms
- Swift is a fully supported, albeit new, language starting in Xcode 6.
- Swift is probably the best way to get Objective-C bridging "for free" in the long term
- Swift supports script-like "immediate mode" with good JIT-compiled performance
- The tool's size and scope is sufficiently small with no complex or WebKit-specific dependencies

I understand that its freshness and continual evolution means that we won't reviewer support relative to our C family languages. I would argue that it will be difficult to subjectively tell when the time is "right", that a good way to solve that is to start using the language itself, and take an incremental approach to crafting the Swift story in WebKit. Using it for some simple tools is a good place to start.

The larger discussion of using Swift in larger AOT-compiled contexts but is probably going to happen in this thread anyway, so let's have it:

What of future use of Swift in WebKit?

Regards,
David Farler
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
David Farler | 28 Jul 21:25 2014
Picon

Any old-run-webkit-tests clients left?

Hi,

Are there any ports or users of old-run-webkit-tests left besides the iOS Simulator? I'm on the verge of
completing iOS Simulator support for webkitpy and run-webkit-tests so, once the new port is stable, I'd
like to consider removing this code.

David
Michael Catanzaro | 24 Jul 16:13 2014

Re: Mixed content checking

Hi Alexey,

On Wed, 2014-07-23 at 22:59 -0700, Alexey Proskuryakov wrote:
> Thank you for the heads up!
> 
> Can you elaborate on why this is desirable? A non-https frame always
> has a different origin, so it can't script the main frame.
> 
> In other words, how is "active content" defined here?

One big reason is that if an insecure frame is loaded on an HTTPS page,
users may believe the page to be secure even though a substantial
portion of that page may not be; browsers generally display a warning
icon when a page display mixed content, but users generally ignore it.
This used to be a big problem, but nowadays no major browser except
Safari allows mixed content frames [1], so it's a low-risk catch-up for
us.

[2] describes a couple other good reasons for blocking these frames
(scroll down to "mixed content frames"). Please note that when [2] was
authored only IE and Firefox were blocking mixed content frames, but
Chrome started doing so some months ago.

> Same question, why? Cross origin XMLHttpRequest is different from
> cross origin scripts in that it takes quite a bit of effort to make it
> work, so it's not the same case of accidentally loading a subresource
> using http instead of https.

Even so, no major browser besides Safari currently allows mixed content
XMLHttpRequests, so I think this is a low-risk restriction. (Again see
[1], but note that Chrome has quite recently begun blocking these as
well.)

Happy Thursday,

Michael

[1]
https://community.qualys.com/blogs/securitylabs/2014/03/19/https-mixed-content-still-the-easiest-way-to-break-ssl
[2]
https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/
Michael Catanzaro | 24 Jul 02:08 2014

Mixed content checking

Hi,

I'm an intern with Igalia currently working on mixed content blocking in
WebKitGTK+. I see WebCore already has decent support for mixed content
blocking using the settings allow-display-of-insecure-content and
allow-running-of-insecure-content, which were previously used by the
Chromium port.

One problem with these settings is that frames are treated as mixed
passive content rather than mixed active content. For the WebKitGTK+ API
I want frames to be treated as active content, which is what most major
browsers currently do. Is it OK if I change this, so that
allow-running-of-insecure-content and not
allow-display-of-insecure-content will be checked to determine whether
or not to block a frame? These settings seem to be currently unused, so
I don't think this will be an unexpected behavior change for anyone.

I'm also planning to block mixed XMLHttpRequest and WebSocket
connections when allow-running-of-insecure-content is false. 

Thanks,

Michael Catanzaro
Filip Pizlo | 22 Jul 23:09 2014
Picon

Heads up: merging the ftlopt branch

For the past two months we’ve been doing some JSC compiler work on a branch called ftlopt.  I’m merging
this branch now.

This should be relatively low-risk.  Most of the changes turned out to be fairly low-risk and they are well tested.

-Filip

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Jacques-Olivier | 22 Jul 06:22 2014
Picon

Trying to turn WebRTC's code on - MEDIA_STREAM flags

Hi everyone,

Note: I already sent this email, but I didn’t get any answer, nor can I see the thread in the archives. Therefore I think it was blocked, maybe because of the attachment that I remove this time.

I’m new on this mailing so I’ll start by introducing myself:
My name Jacques-Olivier Haché (J-O), I’m working for Temasys Communication, and I’m entering the WebKit project to work on the implementation of WebRTC inside WebKit.
For those who would be following the WebRTC’s news, I’m also the main developer of the WebRTC plugin released by Temasys.

Back to business:

I was able to download the project, build it and run it inside Safari. I did not try to run it in a different browser yet.

My configuration:
  • Macbook Air 2012
  • Mac OS X 10.9.4
  • Revision 171167
  • I’m on master
  • I suppose I’m using the regular Mac port as I didn’t see where to change from one port to another yet.
  • building for debug mode
I am now trying to enable the WebRTC related features to get a better understanding of the current state of this part of the project. 
I have to say that I faced a lack of documentation on this area. I found the features list, a document about how to add a new feature but nothing about how to turn a feature on and off (there is actually a TODO about that in the second link).

I looked into the files that one needs to change to add a new feature and found two interesting files:
  • Source/WTF/wtf/FeatureDefines.h - where the WebRTC related contants were set to 0 instead of 1
  • Source/cmake/WebKitFeatures.cmake - where the contants were set to OFF
I listed the following definitions that look related to WebRTC
  • ENABLE_MEDIA_CAPTURE
  • ENABLE_MEDIA_CONTROLS_SCRIPT
  • ENABLE_MEDIA_SOURCE
  • ENABLE_MEDIA_STATISTICS
  • ENABLE_MEDIA_STREAM
  • ENABLE_VIDEO
  • ENABLE_VIDEO_TRACK
I turned those definitions to 1 and ON in the respective file and tried to build.
The code in the header WebCore/Modules/mediastream/mediastream.h could not compile apparently because the observer did not have a destructor. I created one:
    class Observer {
    public:
        virtual void didAddOrRemoveTrack() = 0;
      virtual ~Observer() {};
    };

and tried to build again.

I now have a linking error when building WebCore with Xcode. 

Ld /Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/Debug/WebCore.framework/Versions/A/WebCore normal x86_64
    cd /Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/Source/WebCore
    export MACOSX_DEPLOYMENT_TARGET=10.9
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -arch x86_64 -dynamiclib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -L/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/Debug -F/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/Debug -filelist /Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/WebCore.build/Debug/WebCore.build/Objects-normal/x86_64/WebCore.LinkFileList -Xlinker --no-demangle -exported_symbols_list /Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/Debug/DerivedSources/WebCore/WebCore.LP64.exp -install_name /System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/WebCore -mmacosx-version-min=10.9 -lsqlite3 -lobjc -lANGLE -sub_library libobjc -umbrella WebKit -allowable_client WebCoreTestSupport -allowable_client WebKit2 -allowable_client WebKitLegacy -framework ApplicationServices -framework AudioUnit -framework Carbon -framework Cocoa -framework IOSurface -framework OpenGL -stdlib=libc++ -fobjc-link-runtime -framework Accelerate -framework AudioToolbox -framework CoreAudio -framework IOKit -framework JavaScriptCore -licucore -lobjc -lxml2 -lz -framework QuartzCore -framework Security -framework SystemConfiguration -single_module -compatibility_version 1 -current_version 600.1 -Xlinker -dependency_info -Xlinker /Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/WebCore.build/Debug/WebCore.build/Objects-normal/x86_64/WebCore_dependency_info.dat -o /Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/Debug/WebCore.framework/Versions/A/WebCore

Undefined symbols for architecture x86_64:
  "__ZN7WebCore11JSNavigator18webkitGetUserMediaEPN3JSC9ExecStateE", referenced from:
      __ZN7WebCore46jsNavigatorPrototypeFunctionWebkitGetUserMediaEPN3JSC9ExecStateE in JSNavigator.o
  "__ZN7WebCore15RTCOfferOptions6createERKNS_10DictionaryERi", referenced from:
      __ZN7WebCore17RTCPeerConnection11createOfferEN3WTF10PassRefPtrINS_29RTCSessionDescriptionCallbackEEENS2_INS_30RTCPeerConnectionErrorCallbackEEERKNS_10DictionaryERi in RTCPeerConnection.o
  "__ZN7WebCore20MediaConstraintsMock17verifyConstraintsEN3WTF10PassRefPtrINS_16MediaConstraintsEEE", referenced from:
      __ZN7WebCore21MockMediaStreamCenter26validateRequestConstraintsEN3WTF10PassRefPtrINS_25MediaStreamCreationClientEEENS2_INS_16MediaConstraintsEEES6_ in MockMediaStreamCenter.o
      __ZN7WebCore21MockMediaStreamCenter17createMediaStreamEN3WTF10PassRefPtrINS_25MediaStreamCreationClientEEENS2_INS_16MediaConstraintsEEES6_ in MockMediaStreamCenter.o
  "__ZN7WebCore21RTCOfferAnswerOptions6createERKNS_10DictionaryERi", referenced from:
      __ZN7WebCore17RTCPeerConnection12createAnswerEN3WTF10PassRefPtrINS_29RTCSessionDescriptionCallbackEEENS2_INS_30RTCPeerConnectionErrorCallbackEEERKNS_10DictionaryERi in RTCPeerConnection.o
  "__ZN7WebCore4toJSEPN3JSC9ExecStateEPNS_17JSDOMGlobalObjectEPNS_16RTCConfigurationE", referenced from:
      __ZN7WebCore52jsRTCPeerConnectionPrototypeFunctionGetConfigurationEPN3JSC9ExecStateE in JSRTCPeerConnection.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I found that these strange names actually meant WebCore::JSNavigator::webkitGetUserMedia(execState *) - and same for the others.
Xcode will not find the definition of these functions, but Sublime_Text will. It looks like Xcode projects don’t include the files containing these definitions.
Am I supposed to run a script to re-generate the projects once I enable new features? If yes, I cannot find such a script.
I tried running cmake, but got this message:
Please choose which WebKit port to build (one of Efl;WinCE;GTK;AppleWin;WinCairo)
When what I want is the AppleMac port

If I build using build-webkit, I get a different stack


=== BUILD TARGET WebCoreExportFileGenerator OF PROJECT WebCore WITH CONFIGURATION Debug ===

Check dependencies
iOS.xcconfig line 1: Unable to find included file "<DEVELOPER_DIR>/AppleInternal/XcodeConfig/AspenFamily.xcconfig"
Base.xcconfig line 24: Unable to find included file "../../../../Internal/Configurations/UseInternalSDK.xcconfig"

CompileC /Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/WebCore.build/Debug/WebCoreExportFileGenerator.build/Objects-normal/x86_64/ExportFileGenerator.o /Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/Debug/DerivedSources/WebCore/ExportFileGenerator.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler
    cd /Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/Source/WebCore
    export LANG=en_US.US-ASCII
    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c++ -arch x86_64 -fmessage-length=204 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -fcolor-diagnostics -std=gnu++11 -stdlib=libc++ -Wno-trigraphs -fno-exceptions -fno-rtti -fpascal-strings -O0 -Werror -Wno-missing-field-initializers -Wmissing-prototypes -Wnon-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time-destructors -Wno-missing-braces -Wparentheses -Wswitch -Wunused-function -Wno-unused-label -Wno-unused-parameter -Wunused-variable -Wunused-value -Wempty-body -Wuninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wconstant-conversion -Wint-conversion -Wbool-conversion -Wenum-conversion -Wsign-compare -Wno-shorten-64-to-32 -Wnewline-eof -Wno-c++11-extensions -DDISABLE_THREAD_CHECK -DENABLE_3D_RENDERING -DENABLE_CACHE_PARTITIONING -DENABLE_CANVAS_PATH -DENABLE_CHANNEL_MESSAGING -DENABLE_CSS_BOX_DECORATION_BREAK -DENABLE_CSS_COMPOSITING -DENABLE_CSS_EXCLUSIONS -DENABLE_CSS_FILTERS -DENABLE_CSS_GRID_LAYOUT -DENABLE_CSS_REGIONS -DENABLE_CSS_SHAPES -DENABLE_CSS_TRANSFORMS_ANIMATIONS_UNPREFIXED -DENABLE_CSS3_CONDITIONAL_RULES -DENABLE_CURSOR_VISIBILITY -DENABLE_DASHBOARD_SUPPORT -DENABLE_DETAILS_ELEMENT -DENABLE_DOM4_EVENTS_CONSTRUCTOR -DENABLE_ENCRYPTED_MEDIA -DENABLE_ENCRYPTED_MEDIA_V2 -DENABLE_FILTERS -DENABLE_FULLSCREEN_API -DENABLE_GAMEPAD -DENABLE_GEOLOCATION -DENABLE_HIDDEN_PAGE_DOM_TIMER_THROTTLING -DENABLE_ICONDATABASE -DENABLE_INDEXED_DATABASE -DENABLE_INDIE_UI -DENABLE_INPUT_TYPE_COLOR -DENABLE_INPUT_TYPE_COLOR_POPOVER -DENABLE_INSPECTOR -DENABLE_LEGACY_CSS_VENDOR_PREFIXES -DENABLE_LEGACY_NOTIFICATIONS -DENABLE_LEGACY_VENDOR_PREFIXES -DENABLE_LEGACY_WEB_AUDIO -DENABLE_MATHML -DENABLE_MEDIA_CONTROLS_SCRIPT -DENABLE_METER_ELEMENT -DENABLE_MOUSE_CURSOR_SCALE -DENABLE_NAVIGATOR_CONTENT_UTILS -DENABLE_NAVIGATOR_HWCONCURRENCY -DENABLE_NOTIFICATIONS -DENABLE_PDFKIT_PLUGIN -DENABLE_PROMISES -DENABLE_PUBLIC_SUFFIX_LIST -DENABLE_REQUEST_ANIMATION_FRAME -DENABLE_SHARED_WORKERS -DENABLE_SPEECH_SYNTHESIS -DENABLE_SQL_DATABASE -DENABLE_SUBPIXEL_LAYOUT -DENABLE_SUBTLE_CRYPTO -DENABLE_SVG_FONTS -DENABLE_TEMPLATE_ELEMENT -DENABLE_USERSELECT_ALL -DENABLE_VIDEO -DENABLE_VIDEO_TRACK -DENABLE_DATACUE_VALUE -DENABLE_WEBGL -DENABLE_WEB_AUDIO -DENABLE_WEB_REPLAY -DENABLE_WEB_SOCKETS -DENABLE_PICTURE_SIZES -DENABLE_WEBVTT_REGIONS -DENABLE_XHR_TIMEOUT -DENABLE_XSLT -DENABLE_FTL_JIT -DWEBKIT_VERSION_MIN_REQUIRED=WEBKIT_VERSION_LATEST -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk -fasm-blocks -fstrict-aliasing -Wdeprecated-declarations -Winvalid-offsetof -mmacosx-version-min=10.9 -g -fvisibility=hidden -fvisibility-inlines-hidden -fno-threadsafe-statics -Wno-sign-conversion -I/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/WebCore.build/Debug/WebCoreExportFileGenerator.build/WebCoreExportFileGenerator.hmap -I/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/Debug/include -IForwardingHeaders -Iicu -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/libxslt -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/libxml2 -I/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/Debug/DerivedSources/WebCore -I/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/Debug/usr/local/include -I/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/Debug/usr/local/include/WebKitAdditions -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/local/include/WebKitAdditions -I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include -I/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/WebCore.build/Debug/WebCoreExportFileGenerator.build/DerivedSources/x86_64 -I/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/WebCore.build/Debug/WebCoreExportFileGenerator.build/DerivedSources -Wall -Wextra -Wcast-qual -Wchar-subscripts -Wextra-tokens -Wformat=2 -Winit-self -Wmissing-format-attribute -Wmissing-noreturn -Wpacked -Wpointer-arith -Wredundant-decls -Wundef -Wwrite-strings -Wexit-time-destructors -Wglobal-constructors -Wtautological-compare -Wimplicit-fallthrough -F/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/Debug -include /Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/PrecompiledHeaders/WebCorePrefix-gcoyowpevvvzkbecqfhdngvxbkag/WebCorePrefix.h -MMD -MT dependencies -MF /Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/WebCore.build/Debug/WebCoreExportFileGenerator.build/Objects-normal/x86_64/ExportFileGenerator.d --serialize-diagnostics /Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/WebCore.build/Debug/WebCoreExportFileGenerator.build/Objects-normal/x86_64/ExportFileGenerator.dia -c /Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/Debug/DerivedSources/WebCore/ExportFileGenerator.cpp -o /Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/WebCore.build/Debug/WebCoreExportFileGenerator.build/Objects-normal/x86_64/ExportFileGenerator.o
fatal error: file '/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/Debug/usr/local/include/wtf/FeatureDefines.h' has been modified since the precompiled header
      '/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/PrecompiledHeaders/WebCorePrefix-gcoyowpevvvzkbecqfhdngvxbkag/WebCorePrefix.h.pch' was built
1 error generated.

** BUILD FAILED **


The following build commands failed:
CompileC /Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/WebCore.build/Debug/WebCoreExportFileGenerator.build/Objects-normal/x86_64/ExportFileGenerator.o /Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/Debug/DerivedSources/WebCore/ExportFileGenerator.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler
(1 failure)



Is anyone used to turn the WebRTC code on and off?
Did I miss an important step?
Do you understand these errors?
Why do I end up with different errors with Xcode than with the script? Isn’t the script using LLVM?
Why is the precompiled header not re-built when there are changes in the headers?


Thanks in advance.
J-O H

--
Haché Jacques-Olivier
R&D Engineer at Temasys Communications Pte Ltd
Fr : 06 45 85 48 80
Sg : 9086 3673 

_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Darin Adler | 20 Jul 08:08 2014
Picon

What’s the status of the GObject bindings?

Which port exposes the GObject bindings? I had the impression that the GTK port was dropping WebKit1. Are
the GObject bindings used with WebKit2?

— Darin
Osztrogonác Csaba | 14 Jul 16:23 2014
Picon

Mac WK2 EWS bots having issues

Hi,

It seems the Mac WK2 EWS bots are very flakey nowadays, they set cq-
and comment bugzilla due to false positive media/* test failures.

Is there any volunteer for fixing them?

Ossy
Geoffrey Garen | 11 Jul 23:22 2014
Picon

Re: Comment on the bug & email author/reviewer before reverting a patch

My strong preference is immediate reaction. It doesn't always have to be a rollout, sometimes an issue can be fixed, or some tests can even be temporarily skipped - just make the tree green and stable for everyone else, as quickly as possible. But if the author is not available, and the bot watcher doesn't have a better fix (or is simply overwhelmed with multiple regressions being under investigation at once), I think that immediate rollout should be considered normal.

I agree.

I used to think that it was rude to roll out a patch right away, and it bothered me when people did it to me. It is inconvenient to rebase and re-land a patch, re-close a bug, have roll-ins and roll-outs in svn history, and so on.

However, over time I’ve become convinced that the value of a green bot and viable archived builds is just so high that it’s worth the inconvenience.

These issues are often a judgement call. But if I had to articulate a firm rule, I would say something like this: “A bot watcher should take immediate action to resolve a failure. Before rolling out a patch, a bot watcher should attempt to contact the patch author and/or reviewer. The burden is on the patch author and/or reviewer to prove that the failure will be resolved in short order.”

In other words, I don’t think the burden should be on the bot watcher to prove that he or she has waited long enough. It’s too easy for politeness to red the tree, and it’s too hard — especially for new bot watchers — to overcome good manners in order to do what is necesary.

If you land a patch, and you don’t want it rolled out, be sure to monitor IRC, email, and/or the bots, and you’ll have a good time. Otherwise, accept a roll out. This seems like a reasonable tradeoff to me, which each engineer can negotiate depending on his or her needs at a given time.

Geoff
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Joseph Pecoraro | 11 Jul 22:38 2014
Picon

EFL and GTK EWS bots having issues

It seems the EFL and GTK EWS bots are having trouble for a few days now:

- GTK EWS bot has "Unable to build without patch” with:
ninja: error: build.ninja:3225: lexing error

- EFL EWS bot doesn’t seem to be processing patches.

Who would be best to look into these issues? I thought there used to be a list of EWS maintainers, but I couldn’t find it.

Having these EWS bots to test CMake build changes is awesome, but with the bots down I’m stuck.

- Joe
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Gmane