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
(Continue reading)

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
Alexey Proskuryakov | 11 Jul 09:41 2014

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

(re-sent from correct address)

11 июля 2014 г., в 3:59, Maciej Stachowiak <mjs <at> apple.com> написал(а):

So it seems like the extra request for people using “webkitbot rollout” is to add diagnostic information to the rollout bug, and wait a reasonable period before cq+ing it. Is that something everyone could live with?

In the past, I've seen people overlook comments in rollout bugs more frequently than in original bugs, so I usually added the diagnostic information to the original bug. I think that it's more relevant there, as that's where people will be continuing the work. Knowing what the failure symptoms were is certainly relevant when reviewing a new iteration of the patch.

I have a potential issue with "reasonable period". In the thread, someone mentioned "~3 hours" as the time to wait. But having brokenness for a good part of a business day is unhelpful even if it's only one thing that's broken at a given time. Regressions are introduced more frequently than one per three hours on average, so a grace period this long will result in never having green tests (here I assume that no one advocates for any sort of grace period for build failures).

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.

- Alexey
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Brent Fulgham | 10 Jul 07:53 2014
Picon

Windows (Temporary) Build Turmoil

If you don’t care about building WebKit on Windows, you can stop reading now!

Still here?  Okay:

I’m attempting to make the Windows build rely less on the Cygwin tool chain. There are a number of reasons for this, but one of the major benefits I hope to derive is to reduce the amount of effort required to successfully build WebKit on Windows.

In service of that goal, I am actually making things slightly more complicated: you now need to install a Windows build of Perl and Python, You can use ActiveState’s builds (http://downloads.activestate.com), or the ‘official’ Windows ports of these products.

If you encounter any problems with this “dual Perl/dual Python” situation, please let me know and I’ll work to resolve whatever difficulty you encounter. However, based on my testing on our internal build machines I do not anticipate you will have any trouble.

Thanks,

-Brent
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Ryosuke Niwa | 9 Jul 16:43 2014

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

Hi all,

This is a friendly remainder that you should
  • comment on the associated bug
  • email the patch author and the reviewer who reviewed the patch
before rolling out / reverting a patch.

- R. Niwa

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

Gmane