[webkit-dev] Proposal: Dropping MSVC support and use clang-cl exclusively on Windows

[Yusuke Suzuki via webkit-dev]

Hello WebKittens!

Right now, MSVC support is putting significant burden on JavaScriptCore. It 
lacks many features for JSC development,
as a result, we have so many workarounds for MSVC in JavaScriptCore (For 
example, LLInt CLoop 16-bit opcode is disabled only for MSVC since MSVC cannot 
compile it reasonably).

I talked with JSC team and Don at Sony, and now I would like to propose 
dropping MSVC support on Windows port and using clang-cl exclusively on Windows.

There are many motivating factors for this change.

1. Post-commit testing bots (WinCairo) are using clang-cl. So literally, there 
is zero test coverage on MSVC build right now.
2. On the other hand, EWS is using MSVC for build test. This discrepancy is 
making maintenance of Windows ports harder and harder.
3. MSVC has various compilation issues which makes JSC lesser quality. Lack of 
`__builtin_frame_address` support makes JSC bloating JIT code much. 
CheckedArith has bunch of special code due to lack of overflow-detecting 
`__builtin_add_overflow` like operations, and so on.  (but TBH, given there is 
zero coverage, we even don't know whether it is working right now!)
4. Major third-parties using Windows WebKit (e.g. Bun.js, praywright etc.) are 
using clang-cl, not MSVC.

Not only solving existing issues, using clang-cl opens significant code / 
implementation quality improvements opportunities for Windows.

1. MSVC does not support various C++20 features, so it is putting our C++20 
adoption much behind (For example, we cannot use  concept). By using clang-cl, 
we can start much newer set of C++20 features, improving code quality, static 
checks etc.
2. This paves a way to make Windows JSC implementation super solid. clang-cl 
offers sysv-abi feature for function attributes. This allows using Linux / 
macOS amd64 ABI on certain annotated functions. This basically means that we 
potentially unify our interpreter and JIT implementations completely in Linux / 
macOS / Windows for x64, (which makes our LLInt / Wasm LLInt on Windows super 
solid, plus, it paves a way to fully enable all JIT tiers on Windows including 
FTL).

We already discussed with Don and we agreed on this.
And now I would like to formally propose MSVC deprecation towards more cleaner 
and solid Windows port.

Best regards,
-Yusuke Suzuki
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Replacing Cairo in WebKit with Skia

[Yusuke Suzuki via webkit-dev]

Nice, this sounds really good.
Cairo performance was one of the limiting factors in WebKitGTK, and adopting 
some libraries which can use GPU is great improvement.
One of questions is, should we rename WinCairo to something different? (Like, 
Win, or WinSkia).

-Yusuke

> On Feb 2, 2024, at 6:49 AM, Carlos Garcia Campos via webkit-dev 
>  wrote:
> 
> Hi WebKittens,
> 
> At Igalia we have spent some time exploring different options to
> replace the Cairo 2D rendering library in the GTK and WPE ports (we
> even tried rolling our own library). Recently we decided to try Skia
> and we have successfully integrated it in the WPE port. Right now we
> can compile WebKit with Skia linked statically, as part of the CMake
> build, and run a number benchmarks. This has allowed us to compare the
> Skia GPU and CPU renderers with the existing Cairo one in different
> devices.
> 
> The results are very promising: benchmarks are faster than Cairo's CPU
> rendering, specially with Skia's GPU renderer. The improvement varies
> for each device, but in any case it is already clear that the change is
> a net positive on every configuration we have tested. Additionally, the
> integration in the build system is well isolated: importing Skia under
> Source/ThirdParty there is no need for any additional dependencies,
> patching Skia has not been needed, and the changes in WebKit are
> limited to code from the WPE port.
> 
> After talking to teams from Google, Sony, Apple and RedHat during this
> week, everyone thinks using Skia will be a great improvement for the
> GTK, WPE, PlayStation and WinCairo ports. Therefore, we would like to
> start upstreaming what we have to the WebKit repository and continue
> the work there.
> 
> Points we need to consider:
> 
>- Skia is licensed under the BSD 3-Clause “New” license, which
> should be compatible with WebKit's.
> 
>- The Skia source tree would add about 170MiB to the repository
> under Source/ThirdParty. For the sake of comparison, libwebrtc weighs
> 367MiB and ANGLE 73MiB.
> 
>- We plan to update Skia frequently following Google's
> recommendation. We have already agreed with the Skia maintainers to
> stay in contact and will explore integrating an automated system to
> test updates. We have also discussed Skia's security policy with
> Google, and we will have a procedure in place to incorporate security
> fixes, the latest when we start making releases using Skia.
> 
>- We cannot promise a timeline at the moment but expect refactors
> in the GTK and WPE ports after the initial integration. We have big
> plans for rearchitecting the rendering pipeline to better take
> advantage of GPUs, and we hope we can get rid of some complex code
> while at it.
> 
> Please let us know if you have any questions, we plan to do this job
> sooner rather than later if there are no objections. We are very
> excited about this move since we really think it will be a great step
> ahead for the non Apple ports of WebKit, allowing the project to grow
> even bigger and stronger.
> 
> Best regards,
> 
> - The Igalia team
> 
> -- 
> Carlos Garcia Campos
> ___
> 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] constinit: C++20 tip about constexpr initialization for global variables

[Yusuke Suzuki via webkit-dev]

Hello WebKittens,

Now, our baseline is GCC 10, so I would like to introduce useful C++20 feature 
here, constinit.
https://en.cppreference.com/w/cpp/language/constinit

You can annotate the global variables etc. with `constinit`, like,

```
static constinit StaticStringImpl aboutBlankString { "about:blank" };
```

Tthe benefit is that, compiler knows the strong requirement that this variable 
must be initialized at compile-time (constexpr constructors).

Our global constructor warning is just a warning, so compilers typically allow 
compiling and at the very end, it emits a warning as an error.
So, at that time, we don't know what is breaking constexpr condition. For 
example,

```
/Volumes/WebKit/macOS/OpenSource/Source/WTF/wtf/URL.cpp:932:25: error: 
declaration requires a global constructor [-Werror,-Wglobal-constructors]
static StaticStringImpl aboutBlankString { "about:blank" };
```

You can see that *something* in StaticStringImpl breaks `constexpr`, but we 
cannot see what is breaking it, because, when emitting this warning, compiler 
already lost that information (and compiler just already compiled it via non 
constexpr, and at the very end, it emits warnings like this).

But if you annotate this variable with `constinit`, then compiler knows this 
requirement a-priori, thus,

```
/Users/yusukesuzuki/dev/OpenSource/Source/WTF/wtf/URL.cpp:932:35: error: 
variable does not have a constant initializer
static constinit StaticStringImpl aboutBlankString { "about:blank" };
/Users/yusukesuzuki/dev/OpenSource/Source/WTF/wtf/URL.cpp:932:8: note: required 
by 'constinit' specifier here
static constinit StaticStringImpl aboutBlankString { "about:blank" };
In file included from 
/Users/yusukesuzuki/dev/OpenSource/Source/WTF/wtf/URL.cpp:28:
In file included from 
/Users/yusukesuzuki/dev/OpenSource/Source/WTF/wtf/URL.h:28:
In file included from 
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/WTFString.h:28:
In file included from 
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/StringImpl.h:43:
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/WYHasher.h:248:28:
 note: cast that performs the conversions of a reinterpret_cast is not allowed 
in a constant expression
const uint8_t* p = (const uint8_t*)characters;
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/WYHasher.h:64:40:
 note: in call to 'computeHashImpl(&"about:blank"[0], 11, 0)'
return finalizeAndMaskTop8Bits(computeHashImpl(data, 
characterCount, 0));
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/WYHasher.h:76:16:
 note: in call to 'computeHashAndMaskTop8Bits(&"about:blank"[0], 11)'
return computeHashAndMaskTop8Bits(characters, 
charactersCount - 1);
In file included from 
/Users/yusukesuzuki/dev/OpenSource/Source/WTF/wtf/URL.cpp:28:
In file included from 
/Users/yusukesuzuki/dev/OpenSource/Source/WTF/wtf/URL.h:28:
In file included from 
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/WTFString.h:28:
/Users/yusukesuzuki/dev/OpenSource/WebKitBuild/Release/usr/local/include/wtf/text/StringImpl.h:1251:89:
 note: in call to 'computeLiteralHashAndMaskTop8Bits("about:blank")'
s_hashFlag8BitBuffer | s_hashFlagDidReportCost | stringKind | 
BufferInternal | (WYHasher::computeLiteralHashAndMaskTop8Bits(characters) << 
s_flagCount), ConstructWithConstExpr)
```

The compiler can tell directly what is breaking `constexpr` condition.

`constinit` is available from GCC 10, so it is now supported in all 
WebKit-supporting compilers.

Best regards,
-Yusuke___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] GCC 10 upgrade and C++20 availability

[Yusuke Suzuki via webkit-dev]

Hello WebKittens,

Now, based on milestone, we upgraded GCC requirement from 9.3 to 10.2.
This further unlocks many C++20 features, like <=> operator and constinit
You can see more C++20 features in https://en.cppreference.com/w/cpp/20

Best regards,
-Yusuke___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Removal of trailing whitespace

[Yusuke Suzuki via webkit-dev]

I agree that we should not do it because it pollutes change history of files, 
git-blame results, and review-diff in PR.
But at the same time, I think there is no reason to add a new trailing 
whitespace via a new commit.
It is nice if we can enforce this rule only for newly added code (via 
style-checker) not to add new trailing spaces.

-Yusuke

> On Apr 12, 2023, at 10:08 AM, Ryosuke Niwa via webkit-dev 
>  wrote:
> 
> WebKi proejctt’s long term policy has been to not do this:
> https://lists.webkit.org/pipermail/webkit-dev/2009-August/009665.html
> 
> I don’t think we should change that.
> 
> - R. Niwa
> 
>> On Apr 12, 2023, at 9:17 AM, Chris Dumez via webkit-dev 
>>  wrote:
>> 
>> I am against this because it adds a lot of noise to patches I am trying to 
>> review.
>> I have seen PRs where white space changes account for more than half the 
>> patch I am trying to review.
>> 
>> Dropping trailing spaces on the lines you’re modifying is OK but in the 
>> whole file is too noisy IMO.
>> 
>> Chris.
>> 
>>> On Apr 12, 2023, at 1:22 AM, Anne van Kesteren via webkit-dev 
>>>  wrote:
>>> 
>>> To reduce the overhead of switching between projects with different
>>> whitespace requirements, I would like to suggest we start being
>>> lenient when trailing whitespace is removed. In particular when a file
>>> is being changed to fix a bug.
>>> 
>>> I could see going even further and enforcing this via the style
>>> checker, if there is appetite for that.
>>> 
>>> Thanks for considering!
>>> ___
>>> 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 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] Proposal on retiring JIT on Windows

[Yusuke Suzuki via webkit-dev]

The reason is that the patch is reverted because it broke Windows DFG. This is 
not acceptable to us since we have no EWS bots running tests.
Without active maintainers / EWS bots, we cannot land JIT changes since it can 
break Windows, and it becomes huge burden than before (previously there was a 
Windows EWS bot running tests).

This is unfortunate, but if nobody steps up as a maintainer of JSC JIT on 
Windows (it involves adding test-running EWS bots, bug fixes of JSC on Windows 
etc.), then I think only the solution is disabling this feature.

So, if we would like to keep it, we need someone who steps up as a maintainer 
of JIT on Windows, and setting up bots running tests on Windows on EWS.

-Yusuke

> On Mar 25, 2023, at 9:27 PM, Kirsling, Ross  wrote:
> 
> This seems unfortunate and unexpected to me—I thought having a singular 
> Windows port was supposed to mean reduced maintenance burden, since we don't 
> have to divide the number of Windows maintainers into two.
> 
> Although reconciling FTL with Windows' calling convention is a challenge that 
> no one's ever had the time to prioritize, we've had a fully working DFG on 
> Windows for so many years. If we turn that off, I can't imagine it ever being 
> revived again.
> 
> How come the discussion here is immediately about getting rid of such a large 
> swath of functionality instead of starting with consideration of the EWS 
> situation itself?
> 
> Ross
> From: Yusuke Suzuki via webkit-dev 
> Sent: Sunday, March 26, 2023 7:23:04 AM
> To: Fujii Hironori ; Brent Fulgham 
> ; Mark Lam 
> Cc: WebKit Development 
> Subject: Re: [webkit-dev] Proposal on retiring JIT on Windows
>  
>> How about LLInt? LLInt has some Windows specific code.
>> Can I revert the change if the JSC team breaks Windows port even though we 
>> have no EWS nor maintainers?
> 
> I think, ultimately, we cannot guarantee that it is working given that there 
> is no EWS bots running tests on Windows, it means it is not debuggable to us.
> Frequency of breakage on LLInt would be smaller than breakage on JIT. But if 
> it happens, then I think reverting is not OK since nothing is doable to JSC 
> team.
> 
> @Brent @Mark What is your thought and plan?
> 
> -Yusuke
> 
>> On Mar 25, 2023, at 3:02 PM, Fujii Hironori  wrote:
>> 
>> It sounds reasonable. I don't object to removing Windows JIT support.
>> 
>> How about LLInt? LLInt has some Windows specific code.
>> Can I revert the change if the JSC team breaks Windows port even though we 
>> have no EWS nor maintainers?
>> 
>> On Sun, Mar 26, 2023 at 6:52 AM Yusuke Suzuki via webkit-dev 
>> mailto:webkit-dev@lists.webkit.org>> wrote:
>> Hello,
>> 
>> I would like to propose retiring JIT on Windows JavaScriptCore.
>> Recently, Apple Windows EWS bots get removed. As a result, there is no 
>> test-running EWS bots on Windows.
>> 
>> This can work for the other part of WebKit since other ports EWS bots are 
>> running tests. However this does not work well for JSC.
>> Compile-tests is not sufficient for JIT since JIT is dynamically generated. 
>> And JIT is very architecture and platform specific.
>> Windows has different ABI, different calling convention, and register usage. 
>> JIT on Windows has very specific things.
>> 
>> Now, because there is no running EWS bots on Windows, it is not possible to 
>> catch Windows specific JIT related issues before landing.
>> Recently, JSC DFG patch has been reverted because Windows gets broken[1]. 
>> But this puts high burden to JSC maintenance since
>> there is no way to test it before landing, and it makes DFG changes very 
>> hard due to Windows.
>> 
>> So, given that there is no active maintainers of Windows JSC JIT and no EWS 
>> bots running tests, I propose retiring JIT on Windows.
>> 
>> [1]: 
>> https://github.com/WebKit/WebKit/commit/58f0d9e4a395e0173e4d3f59888bf0e761cf6ce3
>> 
>> -Yusuke
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto: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] Proposal on retiring JIT on Windows

[Yusuke Suzuki via webkit-dev]

> How about LLInt? LLInt has some Windows specific code.
> Can I revert the change if the JSC team breaks Windows port even though we 
> have no EWS nor maintainers?

I think, ultimately, we cannot guarantee that it is working given that there is 
no EWS bots running tests on Windows, it means it is not debuggable to us.
Frequency of breakage on LLInt would be smaller than breakage on JIT. But if it 
happens, then I think reverting is not OK since nothing is doable to JSC team.

@Brent @Mark What is your thought and plan?

-Yusuke

> On Mar 25, 2023, at 3:02 PM, Fujii Hironori  wrote:
> 
> It sounds reasonable. I don't object to removing Windows JIT support.
> 
> How about LLInt? LLInt has some Windows specific code.
> Can I revert the change if the JSC team breaks Windows port even though we 
> have no EWS nor maintainers?
> 
> On Sun, Mar 26, 2023 at 6:52 AM Yusuke Suzuki via webkit-dev 
> mailto:webkit-dev@lists.webkit.org>> wrote:
>> Hello,
>> 
>> I would like to propose retiring JIT on Windows JavaScriptCore.
>> Recently, Apple Windows EWS bots get removed. As a result, there is no 
>> test-running EWS bots on Windows.
>> 
>> This can work for the other part of WebKit since other ports EWS bots are 
>> running tests. However this does not work well for JSC.
>> Compile-tests is not sufficient for JIT since JIT is dynamically generated. 
>> And JIT is very architecture and platform specific.
>> Windows has different ABI, different calling convention, and register usage. 
>> JIT on Windows has very specific things.
>> 
>> Now, because there is no running EWS bots on Windows, it is not possible to 
>> catch Windows specific JIT related issues before landing.
>> Recently, JSC DFG patch has been reverted because Windows gets broken[1]. 
>> But this puts high burden to JSC maintenance since
>> there is no way to test it before landing, and it makes DFG changes very 
>> hard due to Windows.
>> 
>> So, given that there is no active maintainers of Windows JSC JIT and no EWS 
>> bots running tests, I propose retiring JIT on Windows.
>> 
>> [1]: 
>> https://github.com/WebKit/WebKit/commit/58f0d9e4a395e0173e4d3f59888bf0e761cf6ce3
>> 
>> -Yusuke
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto: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] Proposal on retiring JIT on Windows

[Yusuke Suzuki via webkit-dev]

Hello,

I would like to propose retiring JIT on Windows JavaScriptCore.
Recently, Apple Windows EWS bots get removed. As a result, there is no 
test-running EWS bots on Windows.

This can work for the other part of WebKit since other ports EWS bots are 
running tests. However this does not work well for JSC.
Compile-tests is not sufficient for JIT since JIT is dynamically generated. And 
JIT is very architecture and platform specific.
Windows has different ABI, different calling convention, and register usage. 
JIT on Windows has very specific things.

Now, because there is no running EWS bots on Windows, it is not possible to 
catch Windows specific JIT related issues before landing.
Recently, JSC DFG patch has been reverted because Windows gets broken[1]. But 
this puts high burden to JSC maintenance since
there is no way to test it before landing, and it makes DFG changes very hard 
due to Windows.

So, given that there is no active maintainers of Windows JSC JIT and no EWS 
bots running tests, I propose retiring JIT on Windows.

[1]: 
https://github.com/WebKit/WebKit/commit/58f0d9e4a395e0173e4d3f59888bf0e761cf6ce3

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

Re: [webkit-dev] Remove the version labels in GitHub

[Yusuke Suzuki via webkit-dev]

I also would like to propose removing Version label asking in git-webkit when 
creating a bugzilla entry.
This was not happening when using webkit-patch.
Given that we have no consensus on adding this, I think this is a regression.

-Yusuke

> On Nov 14, 2022, at 2:38 PM, Darin Adler via webkit-dev 
>  wrote:
> 
> A couple days ago I created a pull request for part of this:
> 
> https://github.com/WebKit/WebKit/pull/6434
> Anyone interested in reviewing?
> 
> — Darin
> ___
> 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] Style guide: enforce `while (true)` over `for (; ; )`

[Yusuke Suzuki via webkit-dev]

+1

-Yusuke

> On Oct 5, 2022, at 5:07 PM, Tim Nguyen via webkit-dev 
>  wrote:
> 
> Hi everyone,
> 
> The WebKit codebase has an inconsistent mix of `while (true)` and `for (;;)`. 
> Given 2/3 of the usages are `while (true)` and only 1/3 is `for (;;)` from 
> code search, I would suggest enforcing `while (true)`. I also think it is 
> generally more explicit and readable than `for (;;)`. If everyone agrees, 
> I’ll enforce this via webkit-style, so we can end up in a consistent place.
> 
> What does everyone think?
> 
> Cheers,
> Tim
> ___
> 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] Justin Michaud is now a WebKit Reviewer

[Yusuke Suzuki via webkit-dev]

Hello WebKittens,

I’m pleased to announce that Justin Michaud is now a WebKit Reviewer :)

Justin started his WebKit contributions from CSS area and expanded it to 
JavaScriptCore too.
He landed many great optimizations and improvements in JSC and fixed various 
super complicated compiler and runtime bugs.

Congratulation Justin!

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

Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs

[Yusuke Suzuki via webkit-dev]

Another idea (not formally proposing): Safari extension to bring Bugzilla's 
good points to GitHub UI.

I tried writing random userscripts, and while threaded comments for commit 
message / conversation view while reviewing are still missing,
I got some UI to make comment on commit message easier while reviewing.
Good thing is that we can bring interesting things to GitHub without changing 
underlying protocol much.
Bad thing is it can be fragile.

Anyway, I hope we can have a solution :)

-Yusuke

> On May 10, 2022, at 8:50 PM, Yusuke Suzuki via webkit-dev 
>  wrote:
> 
> 
> 
>> On May 10, 2022, at 1:32 PM, Jonathan Bedard via webkit-dev 
>>  wrote:
>> 
>> The last thing I’d like to note is that a full git-native commit message 
>> policy now is something we can modify in the future if we find that 
>> reviewing commit messages with “Quote reply” comments is not sufficient,
> 
> I'm happy that this is noted explicitly!
> Do we have some of candidate plans that make reviewing experience better?
> For reviewing, to me, this is the only problem in GitHub.
> 
> -Yusuke
> 
>> 
>> Jonathan
>> WebKit Continuous Integration
>> 
>> ___
>> 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: Immediate Deprecation of ChangeLogs

[Yusuke Suzuki via webkit-dev]

> On May 10, 2022, at 1:32 PM, Jonathan Bedard via webkit-dev 
>  wrote:
> 
> The last thing I’d like to note is that a full git-native commit message 
> policy now is something we can modify in the future if we find that reviewing 
> commit messages with “Quote reply” comments is not sufficient,

I'm happy that this is noted explicitly!
Do we have some of candidate plans that make reviewing experience better?
For reviewing, to me, this is the only problem in GitHub.

-Yusuke

> 
> Jonathan
> WebKit Continuous Integration
> 
> ___
> 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] JSC broken on s390x

[Yusuke Suzuki via webkit-dev]

Do you have a s390x machine which can be accessible to JSC developers?
I think, probably, only someone having this machine access can fix the problem.

-Yusuke

> On Apr 19, 2022, at 5:23 AM, Michael Catanzaro via webkit-dev 
>  wrote:
> 
> Hi,
> 
> I want to call attention to:
> 
> https://bugs.webkit.org/show_bug.cgi?id=238956
> 
> It breaks JSC on s390x. If anybody is interested in this architecture, or 
> cares about WebKitGTK updates in Fedora (this issue will be a blocker), any 
> help would be much appreciated. :)
> 
> I've also informed Red Hat that this architecture needs more help.
> 
> Michael
> 
> 
> ___
> 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] ChangeLog Deprecation Plans

[Yusuke Suzuki via webkit-dev]

> On Apr 18, 2022, at 5:38 PM, Michael Catanzaro  wrote:
> 
> 
> On Mon, Apr 18 2022 at 02:55:08 PM -0700, Yusuke Suzuki  
> wrote:
>> I think this is important. We are using commit message / ChangeLog as a 
>> document tied to the change, and we are writing very detailed description to 
>> make the intention / design of the change clear and making it as a good 
>> document when we read the change via git-blame, bisect, using that header, 
>> investigating how it works etc.
>> To make / keep this commit message / ChangeLog helpful, we need review, and 
>> I think reviewing of these messages is critical to keep usefulness of them.
> 
> I agree with all of the above. Actually, I'd suggest that the transition to 
> git is a good opportunity to become a little stricter with commit message 
> format than we historically have been. Except for trivial/obvious changes, 
> more detail is better.
> 
> However, we don't need ChangeLog files in the repo or inline review comments 
> to do this. I'm sure we can make do with the normal GitHub review UI.

GitHub (probably, Phabricator too) does not have UI to review commit message.
Also, showing commit message in an attached diff is pretty much similar to how 
Gerrit etc. shows the commit message for review. (Gerrit shows "Commit Message" 
diff).

> 
>> I think COMMIT_MESSAGE proposal has various good benefits.
>> 1. We can review commit mesasges.
>> 2. In local development, we can commit expected COMMIT_MESSAGE file directly 
>> in our tree. We can eventually add more and more detailed information to 
>> this file while local development continues, and we can also revert 
>> COMMIT_MESSAGE change since it can be commited in the local branch.
> 
> This has few advantages over using 'git commit --amend' or 'git rebase -i'. 
> It would also be a custom, WebKit-specific part of our workflow. This is a 
> good opportunity to remove as many WebKit-isms from our contribution process 
> as possible, to make it easier for people who are not familiar with the 
> project to contribute more easily. I suggest we at least try to do things 
> like most other open source projects first, and only implement custom 
> solutions if that fails.

Many projects are using multiple commits in one PR. Some projects require 
squashed merge (e.g. CoreCLR 
https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/contributing-workflow.md#suggested-workflow,
 https://github.blog/2016-04-01-squash-your-commits/ 
), and some projects just 
merge all of them. Because of the importance of performance / regression 
bisection, we must require landing a PR as one commit, so we need a way to 
squash commits.
If we would like to sane commit message for merged commits, we need to chose 
COMMIT_MESSAGE-like separated metadata for message or squashing manually.
Having separated metadata is much easier for development than manually 
squashing commits and messages because we can keep the final commit message 
safely even while changing history / code in this branch, and it was how 
webkit-patch worked.

> 
>> Commit message is tied to a commit, so editing commit without breaking 
>> commit-message is hard (how to revert one change from one commit without 
>> rewriting commit message? It requires some git hack). Separate independent 
>> COMMIT_MESSAGE file can solve this problem and makes local development easy.
> 
> Developers who are used to git -- which nowadays is pretty much everyone 
> except WebKit devs -- are also used to rewriting commit messages.
> 
> Developers are NOT used to writing commit messages in a file named 
> COMMIT_MESSAGE.

No. Various OSS projects require writing commit message separately from 
git-commit's message.
Chromium requires writing separate commit message data to upload a patch to 
Gerrit (git-cl).
And probably LLVM is too. (Using arc tool to upload a change to Phabricator).
They are conceptually the same to COMMIT_MESSAGE: managing non git-commit 
message for upstreaming.

Also, I'm fine if we can separately keep this message from git-commit. 
COMMIT_MESSAGE is one possible way.
But if we would like to have git-cl like tool which manages message separately 
from git-commit messages, then it is also fine. (but in that case, how to 
review this commit message is yet another problem).

> 
>> 3. This solves the problem how to squash multiple commits in one PR. 
>> Merge-queue can just look at this file and use this as a commit message when 
>> squashing and landing. This means that, in a PR, we can push multiple small 
>> commits in our PR branch.
> 
> What is the advantage to doing this, though? It's best if the commits in your 
> PR match what you intend to land. The structure of commits is subject to 
> review in most open source projects. If the commit history is messy, we 
> should not approve the PR.
> 
> For now, we've agreed that for now each PR should land as one commit.

We do not need to repeatedly 

Re: [webkit-dev] ChangeLog Deprecation Plans

[Yusuke Suzuki via webkit-dev]

> On Apr 18, 2022, at 12:51 PM, Michael Catanzaro via webkit-dev 
>  wrote:
> 
> On Mon, Apr 18 2022 at 08:30:04 AM -0700, Jonathan Bedard via webkit-dev 
>  wrote:
>> 2) We need a way to comment on commit messages in review
>>  Current tooling sets the pull request description as the commit 
>> message, “Quote Reply” kind of provides a way to inline comment, although 
>> it´s not the formal review UI
>>  Proposal: Tooling should support a “COMMIT_MESSAGE” file in each pull 
>> request commit that becomes COMMIT_MESSAGE when a pull request is landed
> 
> Although it's inconvenient that we won't be able to leave inline comments on 
> commit messages anymore, is that really so serious a loss that it requires a 
> strange workaround? It just doesn't seem like a very big deal? We can copy 
> and paste and quote when we suggest changes in commit messages.

I think this is important. We are using commit message / ChangeLog as a 
document tied to the change, and we are writing very detailed description to 
make the intention / design of the change clear and making it as a good 
document when we read the change via git-blame, bisect, using that header, 
investigating how it works etc.
To make / keep this commit message / ChangeLog helpful, we need review, and I 
think reviewing of these messages is critical to keep usefulness of them.

I think COMMIT_MESSAGE proposal has various good benefits.

1. We can review commit mesasges.
2. In local development, we can commit expected COMMIT_MESSAGE file directly in 
our tree. We can eventually add more and more detailed information to this file 
while local development continues, and we can also revert COMMIT_MESSAGE change 
since it can be commited in the local branch. Commit message is tied to a 
commit, so editing commit without breaking commit-message is hard (how to 
revert one change from one commit without rewriting commit message? It requires 
some git hack). Separate independent COMMIT_MESSAGE file can solve this problem 
and makes local development easy.
3. This solves the problem how to squash multiple commits in one PR. 
Merge-queue can just look at this file and use this as a commit message when 
squashing and landing. This means that, in a PR, we can push multiple small 
commits in our PR branch. Merge-queue can get canonical COMMIT_MESSAGE when 
squashing, so keeping one-commit-per-one-PR in the upstream branch is easy. 
This allows normal git-based development workflow while keeping commit-message 
format canonical: creating a topic branch, committing many small changes to 
this branch, creating a PR, and PR gets merged into the upstream as a single 
commit.

-Yusuke

> 
>>  Proposal: Have Tools/Scripts/git-webkit setup configure hooks in 
>> contributors local git repositories to lay down CommitMessages.history files 
>> on merge, checkout and commit which contain the last 5000 commit messages. 
>> We can put these in similar places to where ChangeLogs are today, although 
>> we would likely want them in fewer places because this will increase local 
>> compute time on many git operations. We could also make this a configurable 
>> setting so that engineers who are more comfortable with the raw command line 
>> tooling do not have to deal with slower git operations.
> 
> What's wrong with `git log`?
> 
> There are GUI apps that can visualize your git history if so desired, e.g. 
> GNOME has gitg.
> 
> Michael
> 
> 
> ___
> 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] Using C++20 in WebKit

[Yusuke Suzuki via webkit-dev]

That’s awesome! Thank you for your work!

-Yusuke

> On Mar 9, 2022, at 4:29 PM, Alex Christensen via webkit-dev 
>  wrote:
> 
> Apple and Sony are finishing updating our build infrastructure to Visual 
> Studio 2022, and we are considering requiring it to build WebKit starting 
> next week.  If anyone has a reason to delay further, please let me know on 
> this list or directly.
> 
>> On Jan 24, 2022, at 1:43 PM, Alex Christensen via webkit-dev 
>>  wrote:
>> 
>> Ok.  We won’t raise the minimum CMake version for all of WebKit right now 
>> then, just on Windows when we start requiring VS2022.
>> 
>>> On Jan 22, 2022, at 1:44 PM, Carlos Alberto Lopez Perez via webkit-dev 
>>>  wrote:
>>> 
>>> On 22/01/2022 01:51, Alex Christensen via webkit-dev wrote:
 While we’re updating things, is there any objection to updating the
 minimum version of CMake required?  Right now it is 3.12, which was
 released in 2018.  Does anyone have any limitations we should consider
 when picking a new minimum version?
 
>>> 
>>> Yes.
>>> 
>>> CMake is one of the core dependencies for GTK and WPE ports, so the
>>> policy of dependencies applies [1]
>>> 
>>> In practical terms that means that we should support the version of
>>> CMake shipped by Debian 10, which is CMake 3.13 until at least 2022-08-14.
>>> 
>>> However, If the purpose of raising the version is to take advantage of
>>> the new Visual Studio generator then I don't think raising the minimum
>>> version is needed.
>>> 
>>> As far as I know you can take advantage of newer CMake features (like
>>> support for a newer generator) without needing to raise the minimum
>>> version required.
>>> 
>>> So if you have a newer version of CMake you can simply pass the flag
>>> -G"Visual Studio 17 2022" (or similar). Raising the minimum version
>>> required of CMake is not needed to use a newer CMake generator, using it
>>> can be made optional for those that want (and can) use it.
>>> 
>>> 
>>> [1] https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
>>> ___
>>> 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 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] Using C++20 in WebKit

[Yusuke Suzuki via webkit-dev]

It sounds nice! New CMake (3.21~) already supports VS 2022.

-Yusuke

> On Jan 21, 2022, at 10:36 AM, Alex Christensen  wrote:
> 
> Related to the C++20 change, I’m working on moving the Visual Studio build to 
> Visual Studio 2022.  I’ve informed several involved parties directly, but now 
> I’ve informed everyone.  If anyone has a reason not to move to VS2022, please 
> let me know.
> 
>> On Jan 6, 2022, at 2:11 AM, Yusuke Suzuki > <mailto:ysuz...@apple.com>> wrote:
>> 
>> We cannot use char8_t since it is not available in GCC 8.3.0 :)
>> 
>> -Yusuke
>> 
>>> On Jan 5, 2022, at 7:43 PM, Alex Christensen via webkit-dev 
>>> mailto:webkit-dev@lists.webkit.org>> wrote:
>>> 
>>> I, with great help from several of you, got 
>>> https://bugs.webkit.org/show_bug.cgi?id=233963 
>>> <https://bugs.webkit.org/show_bug.cgi?id=233963> compiling on all 
>>> platforms, but several of the JSC bots are still red.  I’m under the 
>>> impression that they either need a clean build or I’ve missed something.  
>>> Could a JSC bot maintainer look into it?
>>> 
>>>> On Dec 7, 2021, at 2:38 PM, Carlos Alberto Lopez Perez via webkit-dev 
>>>> mailto:webkit-dev@lists.webkit.org>> wrote:
>>>> 
>>>> On 06/12/2021 22:36, Yusuke Suzuki via webkit-dev wrote:
>>>>> I recently upgraded GCC requirement to 8.3.0 based
>>>>> on https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
>>>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement>
>>>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
>>>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement>> 
>>>>> (https://trac.webkit.org/changeset/283348/webkit 
>>>>> <https://trac.webkit.org/changeset/283348/webkit>
>>>>> <https://trac.webkit.org/changeset/283348/webkit 
>>>>> <https://trac.webkit.org/changeset/283348/webkit>>)
>>>>> As a result, we can use some of C++20 features.
>>>>> I wonder if we can flip C++20 now. While some of C++20 features cannot
>>>>> be used since GCC 8.3.0 does not support, but some of features can be
>>>>> used, and it is super useful.
>>>> 
>>>> From the PoV of WebKitGTK I think it is Ok to enable now the building
>>>> with C++-20 support and to start using the C++-20 features already
>>>> supported by GCC 8.3.0
>>>> 
>>>> Check here: https://gcc.gnu.org/projects/cxx-status.html 
>>>> <https://gcc.gnu.org/projects/cxx-status.html> which C++-20
>>>> features are supported by GCC 8
>>>> 
>>>> Before using them I think it would be a good idea to double-check if
>>>> those are also supported by the minimum version of Clang that we want to
>>>> support.
>>>> And maybe also to check if those are supported by MS Visual C++ ?
>>>> I say maybe because I'm not sure if we support this compiler.
>>>> ___
>>>> webkit-dev mailing list
>>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>>> <https://lists.webkit.org/mailman/listinfo/webkit-dev>
>>> 
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev 
>>> <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] Using C++20 in WebKit

[Yusuke Suzuki via webkit-dev]

We cannot use char8_t since it is not available in GCC 8.3.0 :)

-Yusuke

> On Jan 5, 2022, at 7:43 PM, Alex Christensen via webkit-dev 
>  wrote:
> 
> I, with great help from several of you, got 
> https://bugs.webkit.org/show_bug.cgi?id=233963 
> <https://bugs.webkit.org/show_bug.cgi?id=233963> compiling on all platforms, 
> but several of the JSC bots are still red.  I’m under the impression that 
> they either need a clean build or I’ve missed something.  Could a JSC bot 
> maintainer look into it?
> 
>> On Dec 7, 2021, at 2:38 PM, Carlos Alberto Lopez Perez via webkit-dev 
>> mailto:webkit-dev@lists.webkit.org>> wrote:
>> 
>> On 06/12/2021 22:36, Yusuke Suzuki via webkit-dev wrote:
>>> I recently upgraded GCC requirement to 8.3.0 based
>>> on https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement>
>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
>>> <https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement>> 
>>> (https://trac.webkit.org/changeset/283348/webkit 
>>> <https://trac.webkit.org/changeset/283348/webkit>
>>> <https://trac.webkit.org/changeset/283348/webkit 
>>> <https://trac.webkit.org/changeset/283348/webkit>>)
>>> As a result, we can use some of C++20 features.
>>> I wonder if we can flip C++20 now. While some of C++20 features cannot
>>> be used since GCC 8.3.0 does not support, but some of features can be
>>> used, and it is super useful.
>> 
>> From the PoV of WebKitGTK I think it is Ok to enable now the building
>> with C++-20 support and to start using the C++-20 features already
>> supported by GCC 8.3.0
>> 
>> Check here: https://gcc.gnu.org/projects/cxx-status.html 
>> <https://gcc.gnu.org/projects/cxx-status.html> which C++-20
>> features are supported by GCC 8
>> 
>> Before using them I think it would be a good idea to double-check if
>> those are also supported by the minimum version of Clang that we want to
>> support.
>> And maybe also to check if those are supported by MS Visual C++ ?
>> I say maybe because I'm not sure if we support this compiler.
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org <mailto: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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Using C++20 in WebKit

[Yusuke Suzuki via webkit-dev]

I recently upgraded GCC requirement to 8.3.0 based on 
https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement 
 
(https://trac.webkit.org/changeset/283348/webkit 
)
As a result, we can use some of C++20 features.
I wonder if we can flip C++20 now. While some of C++20 features cannot be used 
since GCC 8.3.0 does not support, but some of features can be used, and it is 
super useful.
One of the good features is initializer for bit-fields, which can avoid 
uninitialized bit-field bugs.

class A {
bool m_test : 1 : { false };
};

-Yusuke

> On Dec 6, 2021, at 12:52 PM, Alex Christensen via webkit-dev 
>  wrote:
> 
> In April 2019 in https://bugs.webkit.org/show_bug.cgi?id=197131 
>  I increased WebKit’s minimum 
> C++ language requirement from C++14 to C++17.  In 2022 I’m planning to 
> increase WebKit’s minimum C++ requirement from C++17 to C++20.  Would April 
> 2022 be a good time to do that?
> ___
> 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] Caio Lima is now a WebKit reviewer

[Yusuke Suzuki via webkit-dev]

Congrats!

-Yusuke

> On Mar 18, 2021, at 3:42 PM, Saam Barati via webkit-dev 
>  wrote:
> 
> Hi folks,
> 
> I'm happy to announce that Caio Lima is now a WebKit reviewer. Send your 
> JavaScriptCore reviews his way!
> 
> Congrats, Caio.
> 
> - Saam
> ___
> 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] Commit Authorship on GitHub

[Yusuke Suzuki via webkit-dev]

> On Dec 1, 2020, at 11:57 AM, Jonathan Bedard  wrote:
> 
> 
> 
>> On Dec 1, 2020, at 1:55 PM, Yusuke Suzuki > > wrote:
>> 
>> Hi Jonathan!
>> 
>>> On Dec 1, 2020, at 8:22 AM, Jonathan Bedard via webkit-dev 
>>> mailto:webkit-dev@lists.webkit.org>> wrote:
>>> 
>>> Hello contributors,
>>> 
>>> I am in the process of modifying one of our Git mirrors of the repository 
>>> for permanent use. As part of that modification, I am repairing authorship 
>>> of historical commits based on contributors.json. This effort includes our 
>>> branches and resolving commits attributed to commit-queue but authored by 
>>> contributors. Once this task of rewriting history is completed, I will push 
>>> the new repository to GitHub to replace the broken mirror that currently 
>>> resides there.
>> 
>> Does it mean that https://github.com/WebKit/WebKit 
>>  will become an usual repository (not 
>> GitHub sync-ed mirror repository) which is mirrored by ourselves?
>> Previously, when I tried, GitHub-mirrored repository does not invoke 
>> web-hooks correctly, and it was the reason why I needed to create WKR bots.
>> But if WebKit in GitHub repository becomes an usual repository (while it is 
>> mirrored, it is not mirrored by GitHub side), I think this is a good timing 
>> to setting up GitHub <-> slack integration to put commits into #changes and 
>> retiring WKR bot (while WebKitBot exists).
> 
> It does mean that https://github.com/WebKit/WebKit 
>  will become a normal GitHub repository! 
> That being said, I need to set up the automated syncing before we start using 
> web-hooks.

Cool! Let me know in slack etc. when the repository gets ready. I’ll look into 
GitHub integration for commits and retire WKR feature if GitHub slack 
integration can cover that feature.

-Yusuke


> 
> Jonathan
> 
>> 
>> -Yusuke
>> 
>>> 
>>> Since the new repository will have correctly attributed commits, now is a 
>>> good time to ensure that the email address (or addresses) that you use or 
>>> have used to contribute to WebKit are attached to your GitHub account, 
>>> since this is how GitHub connects a user to their contributions.
>>> 
>>> Also note that GitHub will still just be a mirror for the next few months, 
>>> so there is no requirement to have an account with GitHub yet.
>>> 
>>> Jonathan
>>> ___
>>> 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] Commit Authorship on GitHub

[Yusuke Suzuki via webkit-dev]

Hi Jonathan!

> On Dec 1, 2020, at 8:22 AM, Jonathan Bedard via webkit-dev 
>  wrote:
> 
> Hello contributors,
> 
> I am in the process of modifying one of our Git mirrors of the repository for 
> permanent use. As part of that modification, I am repairing authorship of 
> historical commits based on contributors.json. This effort includes our 
> branches and resolving commits attributed to commit-queue but authored by 
> contributors. Once this task of rewriting history is completed, I will push 
> the new repository to GitHub to replace the broken mirror that currently 
> resides there.

Does it mean that https://github.com/WebKit/WebKit 
 will become an usual repository (not GitHub 
sync-ed mirror repository) which is mirrored by ourselves?
Previously, when I tried, GitHub-mirrored repository does not invoke web-hooks 
correctly, and it was the reason why I needed to create WKR bots.
But if WebKit in GitHub repository becomes an usual repository (while it is 
mirrored, it is not mirrored by GitHub side), I think this is a good timing to 
setting up GitHub <-> slack integration to put commits into #changes and 
retiring WKR bot (while WebKitBot exists).

-Yusuke

> 
> Since the new repository will have correctly attributed commits, now is a 
> good time to ensure that the email address (or addresses) that you use or 
> have used to contribute to WebKit are attached to your GitHub account, since 
> this is how GitHub connects a user to their contributions.
> 
> Also note that GitHub will still just be a mirror for the next few months, so 
> there is no requirement to have an account with GitHub yet.
> 
> Jonathan
> ___
> 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] Reminder: include everything that you use in implementation files

[Yusuke Suzuki via webkit-dev]

I think, without EWS / post-build bots using non-unified builds, this is 
difficult to achieve…

-Yusuke

> On Nov 12, 2020, at 4:16 AM, Adrian Perez de Castro via webkit-dev 
>  wrote:
> 
> Hello Peng,
> 
> On Wed, 11 Nov 2020 12:05:18 -0800 "Peng (WebKit) Liu via webkit-dev" 
>  wrote:
> 
>> Any way/option to turn off the unified build completely or partially in a
>> local build? That would be very helpful for a developer to locally verify
>> that header files are included correctly in a patch. Thanks!
> 
> You can use “build-webkit --no-unified-builds” to disable them; though I am
> unsure if this will work for the Mac/iOS ports… It surely works with the
> ports that use CMake (WPE, GTK, JSCOnly), and when using CMake you can also
> use “cmake -DENABLE_UNIFIED_BUILDS=OFF” if you would rather configure and
> build manually.
> 
> I hope this helps.
> 
> Cheers,
> —Adrián
> 
>> Best regards
>> Peng
>> 
>>> On Nov 6, 2020, at 11:21 AM, Brian Burg via webkit-dev 
>>>  wrote:
>>> 
>>> Hello folks,
>>> 
>>> I'd like to remind everyone to please include what you use in .cpp,  .mm, 
>>> and other files. When reviewing patches, please
>>> ensure that new mentions of classes, structs, etc. within an implementation 
>>> file have a corresponding header include. 
>>> All of our headers have #pragma once, so there is no downside to being more 
>>> explicit.
>>> 
>>> I've been noticing an uptick in the number of unified sources-related build 
>>> failures. I can't remember the last nontrivial patch
>>> I wrote that did *not* include unrelated build fixes. Typically these 
>>> failures aren't found until EWS results come back, reducing developer 
>>> velocity.
>>> And obviosuly it's super annoying to encounter completely unrelated build 
>>> failures that must be nonetheless addressed.
>>> 
>>> Let's all do our part so that hacking on WebKit remains delightful.
>>> 
>>> Thanks,
>>> 
>>> Brian Burg (he/they)
>>>  WebKit Developer Experience
> ___
> 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