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

[Kirsling, Ross via webkit-dev]

Seems like a great opportunity to turn WinCairo into simply "Win".

Ross

On 2/7/24, 3:31 PM, "Yusuke Suzuki via webkit-dev" 
mailto:webkit-dev@lists.webkit.org>> wrote:


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 
> mailto:webkit-dev@lists.webkit.org>> 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Anne Van Kesteren is now a WebKit reviewer

[Kirsling, Ross via webkit-dev]

Indeed, congratulations!!

From: Mathias Bynens via webkit-dev 
Sent: Friday, January 12, 2024 10:02:13 PM
To: Tim Nguyen 
Cc: WebKit Development 
Subject: Re: [webkit-dev] Anne Van Kesteren is now a WebKit reviewer

Congrats Anne!

On Thu, Jan 11, 2024 at 8:32 PM Tim Nguyen via webkit-dev 
mailto:webkit-dev@lists.webkit.org>> wrote:
Hi everyone!

I’m delighted to announce that Anne Van Kesteren is now a WebKit reviewer!  

He’s been working on HTML parsing, CSS parsing and native theme related things.

Please feel free to reach out to him for reviews.

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

Re: [webkit-dev] ENABLE macro placement between includes

[Kirsling, Ross via webkit-dev]

I would support specifying the common pattern in our styleguide.

Ross

From: Alex Christensen via webkit-dev 
Reply-To: Alex Christensen 
Date: Thursday, August 3, 2023 at 2:52 PM
To: Webkit Development List 
Subject: [webkit-dev] ENABLE macro placement between includes

Our coding style says to include config.h, then the primary header, then other 
headers.  It does not say where to put any ENABLE macros in that list.

We have about 1700 places where we follow this pattern:

#include "config.h"
#include "RemoteSampler.h"

#if ENABLE(GPU_PROCESS)
…
#endif

We have about 350 places where we follow this pattern:

#include "config.h"

#if ENABLE(WEBGL)

#include "WebGLUniformLocation.h"
…
#endif

The less common pattern has the advantage of not needing to search the 
directory where the header is if the feature is not enabled, but I like the 
more common pattern more and I think it matches our style guidelines better.  
Should we specify one or the other, or should we not specify this in our coding 
style?
___
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

[Kirsling, Ross via webkit-dev]

I guess the shock to me is that bots were taken down instead of reconfigured. 
Maybe I misunderstood that part of the AppleWin removal—I was excited about 
this change because it seemed like a net *gain* in resources.

Ross

From: Yusuke Suzuki 
Sent: Sunday, March 26, 2023 3:18:36 PM
To: Kirsling, Ross 
Cc: Fujii Hironori ; Brent Fulgham 
; Mark Lam ; WebKit Development 

Subject: Re: [webkit-dev] Proposal on retiring JIT on Windows

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<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<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

[Kirsling, Ross via webkit-dev]

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
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] WebKit Documentation

[Kirsling, Ross via webkit-dev]

I’d vote for (1) since it’s easy to type!

Thanks,
Ross

From: Ryosuke Niwa via webkit-dev 
Reply-To: Ryosuke Niwa 
Date: Friday, March 10, 2023 at 6:41 AM
To: Brandon Stewart 
Cc: Ling Ho via webkit-dev 
Subject: Re: [webkit-dev] WebKit Documentation




On Mar 9, 2023, at 10:48 AM, Brandon Stewart via webkit-dev 
 wrote:

Sorry for the delay on the documentation update.

For getting the documentation system online, we were trying to settle on a 
subdomain.

What would people prefer we use as the official documentation location:
(1) docs.webkit.org
(2) developer.webkit.org
(3) documentation.webkit.org

(1) or (3) seems good.

- R. Niwa

On Feb 28, 2023, at 12:39 AM, dpino via webkit-dev 
 wrote:

On 9/20/22 05:28, Brandon Stewart via webkit-dev wrote:

Hi WebKit Developers,



Documentation is an important part of any open source project, especially for a 
larger project like WebKit. Being able to ramp up during the onboarding 
process, reading up on architectural decisions, and learning how to perform 
common procedures are all features the documentation should tackle. WebKit has 
a large set of documentation already, but it is scattered around a wide range 
of platforms (Trac, GitHub Wiki, markdown files in the code, Git commits, 
etc...), and some of the information is out of date.



A few months ago, I started working on a new documentation solution based on 
the DocC documentation framework. This provides an easy way to add and edit 
documentation through markdown files. I have already ported a large section of 
Trac, all of the GitHub Wiki, and all of the non third party markdown files in 
the code over to this platform. I have tested this on macOS and Linux and have 
found it works extremely well. (Windows should be able to use WSL2 at the 
moment, while a few remaining issues get sorted out). The only dependency for 
this project is a recent installation of Swift.



You can already download the documentation and preview it locally, but we are 
looking to publish it online for easy viewing. We were looking to get your 
feedback if we would want to publish the documentation on GitHub Pages or 
webkit.org.



The documentation source can be found at 
https://github.com/webkit/documentation.



- Brandon

___

webkit-dev mailing list

webkit-dev@lists.webkit.org

https://lists.webkit.org/mailman/listinfo/webkit-dev

H,

It has been more than 5 months since this new documentation repository was 
announced and as far as I know it hasn't been published yet. Is there any news 
when this site will be publicly available?

Right now in Igalia we need to publish some information publicly and we were 
discussing where it's the right place to put it.

  * WebKit Documentation 
(https://github.com/webkit/documentation.git),
 IMHO it doesn't make sense because the information needs to be public.

  * Trac (https://trac.webkit.org/wiki), since 
WebKit Documentation hasn't been published yet, the fact is that we have been 
updating Trac pages in the last months.

  * WebKit GitHub Wiki 
(https://github.com/WebKit/WebKit/wiki), 
it seems like the best candidate. It says that new documentation should live 
there instead of being added to Trac. But on the other hand when WebKit 
Documentation was announced some people advocated for keep using the GH Wiki 
but that idea was discarded. It seems like WebKit GitHub Wiki is were new 
documents should be published until WebKit Documentation site is not available? 
Please confirm whether this assumption is correct or not.

--

Diego
___
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] Remove the version labels in GitHub

[Kirsling, Ross via webkit-dev]

Right, I thought that was the point of the above discussion so I was surprised 
to see that the prompt hasn't been removed.

From: Yusuke Suzuki via webkit-dev 
Sent: Monday, November 21, 2022 12:51:42 PM
To: WebKit Development 
Cc: Darin Adler 
Subject: Re: [webkit-dev] Remove the version labels in GitHub

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:


<6434.png>
Don't convert the bugs.webkit.org version to a label when creating a pull 
request by darinadler · Pull Request #6434 · 
WebKit/WebKit
github.com

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] Remove the version labels in GitHub

[Kirsling, Ross via webkit-dev]

Indeed, I'd love it those didn't exist.
(I always imagined them to be exclusively intended for bug reports originating 
from non-contributors, but I'm not even certain how much they've been used in 
that scenario.)

From: Michael Catanzaro via webkit-dev 
Sent: Saturday, October 22, 2022 11:43:51 PM
To: Darin Adler 
Cc: webkit-dev@lists.webkit.org 
Subject: Re: [webkit-dev] Remove the version labels in GitHub

On Sat, Oct 22 2022 at 07:31:06 AM -0700, Darin Adler via webkit-dev
 wrote:
> Can we just get rid of all this?

That would be nice. These labels are not useful for pull requests.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://urldefense.com/v3/__https://lists.webkit.org/mailman/listinfo/webkit-dev__;!!JmoZiZGBv3RvKRSx!6acmLR6WO1OcQDLQ2ughafLmLz1jFFMq2eExjpA1bOHB0z7f6CZSgWhu6N6QR1_hUff4isSJ7zspgXf-ecOWUFrJtX0$
___
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 (; ; )`

[Kirsling, Ross via webkit-dev]

I've always kind of liked that `for (;;)` doesn't involve an explicit constant, 
but I too like consistency even more. :)

From: Ryosuke Niwa via webkit-dev 
Sent: Thursday, October 6, 2022 1:01:01 PM
To: Yusuke Suzuki ; Tim Nguyen ; 
WebKit Development 
Subject: Re: [webkit-dev] Style guide: enforce `while (true)` over `for (; ; )`

I do prefer for (;;) because of less typing but if the existing code mostly 
uses while (true) then we should go with it.

On Oct 5, 2022, at 8:58 PM, Yusuke Suzuki via webkit-dev 
mailto:webkit-dev@lists.webkit.org>> wrote:

+1

-Yusuke

On Oct 5, 2022, at 5:07 PM, Tim Nguyen via webkit-dev 
mailto:webkit-dev@lists.webkit.org>> 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Deployment of new EWS Non-Unified builder

[Kirsling, Ross via webkit-dev]

This conversation has had some diverging threads (which is what makes mailing 
list-based communication so difficult), but I'm disappointed that this should 
mean that the crux of the conversation was lost.

There is no such thing as "not maintaining the non-unified build"; there never 
has been. We have covered that this is an *inherent* problem in a unified build 
mechanism and that this would be an issue even if Mac were the only platform. 
The *singular* question at play is whether contributors have visibility into 
the repercussions of their mistakenly omitted includes. The proposal is to have 
a bot to provide this visibility, and Igalia already has one ready to offer. No 
single platform can provide complete visibility because no single platform 
compiles everything, but incomplete visibility would still save a huge amount 
of labor regularly performed by the community.

The fact that this labor can not only be overlooked but outright *defended* is, 
quite frankly, appalling—it is the most disrespectful behavior I've witnessed 
in my time contributing to this community.

Ross

Get Outlook for Android

From: Alexey Proskuryakov via webkit-dev 
Sent: Wednesday, September 7, 2022 5:05:40 PM
To: Michael Catanzaro 
Cc: webkit-dev@lists.webkit.org 
Subject: Re: [webkit-dev] Deployment of new EWS Non-Unified builder


I can't speak for everyone, but the reason why I haven't been responding was 
that the discussion went in circles, and didn't address the concerns raised.

There is new evidence showing that maintaining the non-unified build is very 
hard. We knew that from the start, which is why the plan was to not maintain 
it. Seems like this newly posted evidence only reinforces the decision.

- Alexey

> 7 сент. 2022 г., в 10:41 AM, Michael Catanzaro via webkit-dev 
>  написал(а):
>
>
> At this point I would just go ahead and create the EWS bot. Even if it's not 
> going to be a default build configuration, we're still wasting a bunch of 
> time and effort to keep it working, and the EWS would help fix that.
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://urldefense.com/v3/__https://lists.webkit.org/mailman/listinfo/webkit-dev__;!!JmoZiZGBv3RvKRSx!_-YAPcPo_76ayjWZ1XeMQ8GeKGm4GosQLa_S2VyNAFELCChziGVCya-6PVjS2uwD27UxfA_DnSX4FpDUJ7rwqxwrjek$


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://urldefense.com/v3/__https://lists.webkit.org/mailman/listinfo/webkit-dev__;!!JmoZiZGBv3RvKRSx!_-YAPcPo_76ayjWZ1XeMQ8GeKGm4GosQLa_S2VyNAFELCChziGVCya-6PVjS2uwD27UxfA_DnSX4FpDUJ7rwqxwrjek$
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Deployment of new EWS Non-Unified builder

[Kirsling, Ross via webkit-dev]

"Supported configurations" may indeed be too tricky of a concept to pin down, 
but I believe Diego explained quite thoroughly how the central issue here would 
be every bit as relevant in a world where we only care about standard Mac 
builds.

If FooBar.cpp and FooBaz.cpp need the same 10 includes, then we may be able to 
omit all 10 of them from FooBaz.cpp and still get the unified build to pass. 
Now, a complete lack of includes might cause a reviewer to raise an eyebrow, 
but missing a few is likely to go unnoticed...until months later, when someone 
working on an totally unrelated patch gets bitten (e.g. by trying to add a 
Blah.cpp that shifts everything after it).

The fact is that "oops, I missed an include" is a one-second fix for the 
original patch author, while it could well be a one-hour fix for someone 
lacking the appropriate context (just think about the inscrutable error output 
that comes from missing an *Inlines.h). This would be quite a frustrating hour 
too, since it has nothing to do with the work they meant to be doing.

Without a bot to verify includes on each patch, an author cannot be blamed for 
missing a few; this has been our status quo, but it is not a state we are in by 
choice—on the contrary, it is a technical debt that this community has carried 
for five whole years. We should be excited to see this debt paid at last.

Ross

On 6/3/22, 4:19 PM, "Darin Adler via webkit-dev"  
wrote:

Here’s my view:

Long ago we agreed that we’ll ask WebKit contributors to keep builds 
working that have EWS bots, and not other configurations. As far as I can tell, 
nothing has changed that invalidates that strategy and we should stick with it.

I do not agree that the statement that “all projects must build under all 
supported configurations” applies to WebKit. We don’t even have a concept of 
“supported configurations” to build that policy on. This has not been a project 
goal in the past and I suggest we do not add this project goal.

We should continue to use the Early Warning System to define which 
configurations must be kept working by all contributors, with anything beyond 
being treated as a stretch goal.

And we should continue to accept patches to fix various configurations that 
people want to keep working that are not checked by EWS. But we absolutely 
should not ask contributors to keep all possible combinations working.

— Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org

https://urldefense.com/v3/__https://lists.webkit.org/mailman/listinfo/webkit-dev__;!!JmoZiZGBv3RvKRSx!_0KKQpKHxvBc_6M9_Y1X-umnEdbZbpx72USGbZhbAXJN3qd9s3G_WOz4R-8KPEGDPvekm30vuZhwS6ae1IoL_Iz3Eko$
 

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

Re: [webkit-dev] Deployment of new EWS Non-Unified builder

[Kirsling, Ross via webkit-dev]

> One day per person per month sounds like a totally reasonable cost for us to 
> ask of ports that don't yet to have EWS setup in the upstream WebKit project.

I don’t follow; I am *purely* concerned with well-established platforms that do 
have EWS set up. The work that is proactively done by Sony and Igalia is 
intended to benefit all platforms. The result of this work is that folks seldom 
encounter errors on their patches that are purely due to unified build shifts 
and not due to anything in the content of their patch. The fact that people are 
able to unaware of these issues occurring is a testament to all the work that 
has been done.

Since these errors would occur on *all* platforms, there’s no justification for 
this labor to be offloaded to any particular group; the problem is that we’ve 
not had a good solution until now (particularly due to the lack of a fully 
working Mac Cmake build). This bot means that people can know their patches are 
free of include errors without having to worry about how to verify that locally.

Ross

From: Ryosuke Niwa 
Date: Wednesday, June 1, 2022 at 4:39 PM
To: "Kirsling, Ross" 
Cc: Alexey Proskuryakov , "webkit-dev@lists.webkit.org" 

Subject: Re: [webkit-dev] Deployment of new EWS Non-Unified builder


On Wed, Jun 1, 2022 at 16:10 Kirsling, Ross via webkit-dev 
mailto:webkit-dev@lists.webkit.org>> wrote:
I feel like this has been discussed adequately in the past, but one more time 
for good measure:

Any two platforms which don't build the exact same set of files will undergo 
unification differently. That means that unification shifts are an inherent 
part of working on WebKit, embedder or otherwise.

The only way to be certain that includes are done correctly in a given patch is 
to perform a non-unified build. This would be an unreasonable burden for local 
development, but that's exactly why an EWS builder is desirable.

To have this appear like a non-issue is to ignore the work that Sony and Igalia 
have continually performed through the 5(?) years since unified builds were 
introduced. From experience, I know that it can take a person about a day per 
month to clean up includes on behalf of the entire WebKit community.

One day per month for one beginner sounds like a really low maintenance cost 
compared to having every WebKit developer fix non-unified builds at all times.

Each patch should be responsible for getting its own includes correct.

It's unclear that this makes sense given that we can already fix build failures 
caused by different set of translation units getting unified for WebKit ports 
that have their own EWS bots.

One day per person per month sounds like a totally reasonable cost for us to 
ask of ports that don't yet to have EWS setup in the upstream WebKit project.

Inevitably, such ports already face other more complex build failures whenever 
we refactor WebKit or WebCore platform by, say, introducing new client 
interface or pure virtual member function that has to be overridden in each 
platform / port.

- R. Niwa

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

Re: [webkit-dev] Deployment of new EWS Non-Unified builder

[Kirsling, Ross via webkit-dev]

I feel like this has been discussed adequately in the past, but one more time 
for good measure:

Any two platforms which don't build the exact same set of files will undergo 
unification differently. That means that unification shifts are an inherent 
part of working on WebKit, embedder or otherwise.

The only way to be certain that includes are done correctly in a given patch is 
to perform a non-unified build. This would be an unreasonable burden for local 
development, but that's exactly why an EWS builder is desirable.

To have this appear like a non-issue is to ignore the work that Sony and Igalia 
have continually performed through the 5(?) years since unified builds were 
introduced. From experience, I know that it can take a person about a day per 
month to clean up includes on behalf of the entire WebKit community.

Each patch should be responsible for getting its own includes correct. This has 
not been possible in the past, but Igalia's generosity in providing an EWS 
builder means that it now could be. They deserve our gratitude.

Ross

From: Alexey Proskuryakov 
Sent: Wednesday, June 1, 2022 3:26:50 PM
To: Kirsling, Ross 
Cc: dpino ; webkit-dev@lists.webkit.org 

Subject: Re: [webkit-dev] Deployment of new EWS Non-Unified builder

Hi,

I'm not sure if we have a consensus on whether it is a project goal to keep 
non-unified build working at all times. As discussed last year, setting up 
post-commit bots is a pre-requisite for having EWS, so this part is resolved. 
But proactively maintaining the non-unified build is strictly more work than 
fixing it on demand. So the immediate response continues to be that we 
shouldn't be doing more work when we can do less.

You mention that embedders who build with non-default flags are more likely to 
hit issues. Building with non-default flags would be resulting in missing 
includes for non-unified builds too, do you have an estimate of how much this 
problem grows due to unified builds? How do we decide if everyone is 
responsible for the convenience of downstream embedders?

It sounds like none of actively supported ports builds non-unified by default, 
which I understand from the fact that a special post-commit queue had to be set 
up for that.

Perhaps part of the argument is that even though proactively maintaining the 
non-unified build is more work, this work is somehow easier than fixing builds 
on demand. If so, can you elaborate on why this is the case?

- Alexey

21 мая 2022 г., в 12:10 AM, Kirsling, Ross via webkit-dev 
mailto:webkit-dev@lists.webkit.org>> написал(а):

This is wonderful news―thanks Diego!

Ross

From: dpino via webkit-dev 
mailto:webkit-dev@lists.webkit.org>>
Sent: Friday, May 20, 2022 9:17:56 PM
To: webkit-dev@lists.webkit.org<mailto:webkit-dev@lists.webkit.org> 
mailto:webkit-dev@lists.webkit.org>>
Subject: [webkit-dev] Deployment of new EWS Non-Unified builder

Hi,

Last year we started a thread to discuss the possibility of deploying a
new EWS bot that builds WebKit with Non-Unified sources [1]. This thread
explains the technical reasons why a non-unified build bot is desirable.
If you're aware of the problems introduced by unified sources
compilation, skip the next paragraph.

Unified sources compilation consists of merging several source files
together into one big file to improve building times. Usually the same
sources files are grouped together, but compilation flags or downstream
changes can create different source file groups. When that happens, you
may hit a build error. Since unified sources group files together,
missing headers in one file can be satisfied by another file in the same
group. What's happening in WebKit development currently is that source
code that breaks non-unified compilation frequently lands without even
being noticed. The breaks are usually related to missing headers.
Embedders that need to support WebKit builds with different flags or
maintain downstream changes are more likely to hit these compilation
errors.

Last year's attempt to deploy an EWS Non-Unified builder ended up in a
deployment of a post-commit bot plus two workers running in the UAT. It
was actually hard to get the Non-Unified builder working [2], something
that we achieved at the beginning of this year (kudos to Adrián and
Lauro). Since then we have been maintaining the post-commit bot very
closely. There are periods of time where the bot has remained green for
a long period of time.

But lately maintaining the bot green has become harder and harder,
specially due to the big refactorizations that have happened in WebKit
source code lately. The bot very rarely stays green longer than 2 or 3
days without close maintenance. We believe that we all should share the
responsibility of keeping the non-unified build working, and therefore
we want to proceed with the deployment of a EWS Non-Unified builder.

Initially, we'll provide two workers

Re: [webkit-dev] Deployment of new EWS Non-Unified builder

[Kirsling, Ross via webkit-dev]

This is wonderful news—thanks Diego!

Ross

From: dpino via webkit-dev 
Sent: Friday, May 20, 2022 9:17:56 PM
To: webkit-dev@lists.webkit.org 
Subject: [webkit-dev] Deployment of new EWS Non-Unified builder

Hi,

Last year we started a thread to discuss the possibility of deploying a
new EWS bot that builds WebKit with Non-Unified sources [1]. This thread
explains the technical reasons why a non-unified build bot is desirable.
If you're aware of the problems introduced by unified sources
compilation, skip the next paragraph.

Unified sources compilation consists of merging several source files
together into one big file to improve building times. Usually the same
sources files are grouped together, but compilation flags or downstream
changes can create different source file groups. When that happens, you
may hit a build error. Since unified sources group files together,
missing headers in one file can be satisfied by another file in the same
group. What's happening in WebKit development currently is that source
code that breaks non-unified compilation frequently lands without even
being noticed. The breaks are usually related to missing headers.
Embedders that need to support WebKit builds with different flags or
maintain downstream changes are more likely to hit these compilation
errors.

Last year's attempt to deploy an EWS Non-Unified builder ended up in a
deployment of a post-commit bot plus two workers running in the UAT. It
was actually hard to get the Non-Unified builder working [2], something
that we achieved at the beginning of this year (kudos to Adrián and
Lauro). Since then we have been maintaining the post-commit bot very
closely. There are periods of time where the bot has remained green for
a long period of time.

But lately maintaining the bot green has become harder and harder,
specially due to the big refactorizations that have happened in WebKit
source code lately. The bot very rarely stays green longer than 2 or 3
days without close maintenance. We believe that we all should share the
responsibility of keeping the non-unified build working, and therefore
we want to proceed with the deployment of a EWS Non-Unified builder.

Initially, we'll provide two workers on a modern host with 8 cores
assigned each. We have found this setup faster for most patches than
many of the existing EWS queues, as it only runs a build in non-unified
mode, without test or upload steps. If this were not fast enough, we
would consider increasing the number of workers in the queue. We set up
a page[3] with a rough comparison to the regular (unified) bot and the
build times are pretty similar.

Diego

[1]
https://urldefense.com/v3/__https://www.mail-archive.com/webkit-dev@lists.webkit.org/msg30077.html__;!!JmoZiZGBv3RvKRSx!6YGOGRuK21OCDj8_MKm9gtNOYvBg9Ry10BMna8HXDHWUcUpVeDPBeA4QBT-nC3xj3j8wgt_mjpqbrrOsbTOSWjtVsXQ$
[2] 
https://urldefense.com/v3/__https://bugs.webkit.org/show_bug.cgi?id=226088__;!!JmoZiZGBv3RvKRSx!6YGOGRuK21OCDj8_MKm9gtNOYvBg9Ry10BMna8HXDHWUcUpVeDPBeA4QBT-nC3xj3j8wgt_mjpqbrrOsbTOSqxngQkY$
[3] 
https://urldefense.com/v3/__https://people.igalia.com/lmoura/webkit-bots-dashboard/unified.html__;!!JmoZiZGBv3RvKRSx!6YGOGRuK21OCDj8_MKm9gtNOYvBg9Ry10BMna8HXDHWUcUpVeDPBeA4QBT-nC3xj3j8wgt_mjpqbrrOsbTOSPFziSrI$
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://urldefense.com/v3/__https://lists.webkit.org/mailman/listinfo/webkit-dev__;!!JmoZiZGBv3RvKRSx!6YGOGRuK21OCDj8_MKm9gtNOYvBg9Ry10BMna8HXDHWUcUpVeDPBeA4QBT-nC3xj3j8wgt_mjpqbrrOsbTOS8gKEMAU$
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Basuke Suzuki is now a WebKit reviewer!

[Kirsling, Ross via webkit-dev]

Hi everybody,

I’m happy to announce that Basuke Suzuki is WebKit’s newest reviewer!

Basuke has done significant work on the PlayStation and WinCairo ports, Curl, 
the socket-based remote web inspector, and bmalloc, so keep him in mind next 
time you need a review.

Please join me in congratulating Basuke!

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

Re: [webkit-dev] Request for position: relative indexing method on JS indexables

[Kirsling, Ross via webkit-dev]

Hey Shu,

This is already implemented behind the JSC runtime option `useAtMethod`.
(Latest relevant revision is r270005.)
Looking forward to seeing whether the new name is in fact web-compatible. 爛

Ross


From: Shu-yu Guo via webkit-dev 
Sent: Monday, November 30, 2020 5:04:02 PM
To: webkit-dev@lists.webkit.org 
Subject: [webkit-dev] Request for position: relative indexing method on JS 
indexables

Hi all,

This is a request for the WebKit position on the TC39 relative indexing method 
proposal, which has been at Stage 3 since September 2020. It was initially 
named `.item`, but due to web incompatibility with the YUI library and Flickr, 
it was renamed in November 2020 to `.at`, pending further web incompatibility 
data.

Chrome would like to ship ASAP to gather said incompatibility data.

- Proposal: https://github.com/tc39/proposal-relative-indexing-method
- Specification: https://tc39.es/proposal-relative-indexing-method/
- ChromeStatus: https://chromestatus.com/feature/6123640410079232

Cheers,
Shu-yu Guo, V8
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-changes] [264332] trunk/Source

[Kirsling, Ross]

Non-unified build fixes are done to support *all* platforms, because sudden 
unification shifts can happen anywhere. We can't currently perform a full 
non-unified build on Mac since the CMake build only works up through JSC, so 
Sony and Igalia have been performing this maintenance by hand on Windows and 
Linux for years. It is for this reason that one is unlikely to encounter 
unification shift issues via EWS.

Tips for how to make better build fixes are helpful, but these build fixes 
can't go anywhere until we have a bot to identify missing includes and such as 
they arise.

Ross

From: Geoffrey Garen 
Sent: Thursday, July 16, 2020 8:54:00 AM
To: Yusuke Suzuki 
Cc: Fujii, Hironori (SIE) ; Darin Adler 
; WebKit Development Mailing List 
Subject: Re: [webkit-dev] [webkit-changes] [264332] trunk/Source

The original question was, as I understood it, was do we need to support 
non-unified builds as an essential requirement for a given port, and if so, why?

I’d like to finish answering that question, before we wonder off-topic and 
consider whether supporting non-unified builds as an optional way to improve 
our workflow is a good idea.

Thanks,
Geoff

On Jul 15, 2020, at 4:20 PM, Yusuke Suzuki 
mailto:ysuz...@apple.com>> wrote:

And I agree, keeping non-unified build sane is quite useful.
In addition to the benefit described by Alex, this also allows CMake to 
generate sane compile_commands.json, so that my completion in Neovim works 
better in cpp files,
and I think this compile_commands.json is also used in several clang-related 
toolings too.

I think we should have a bot maintaining it.

-Yusuke

On Jul 15, 2020, at 7:33 AM, Alex Christensen 
mailto:achristen...@apple.com>> wrote:

I think it is still quite useful to fix non-unified builds.  Otherwise adding a 
file usually involves many unrelated build fixes.

On Jul 14, 2020, at 5:25 PM, Fujii Hironori 
mailto:fujii.hiron...@gmail.com>> wrote:



On Wed, Jul 15, 2020 at 6:32 AM Sam Weinig 
mailto:wei...@apple.com>> wrote:
While I don’t want to take away from what Darin is saying here about correct 
usage of forward declaration and , I’d like to understand why we 
have two different compilation models supported in WebKit. Is there a reason 
both need to be supported? Can we remove one?


I also want to know that. Does anyone still need non-unified builds?

I introduced other unnecessary header inclusion, and Darin asked me to fix it.
https://bugs.webkit.org/show_bug.cgi?id=214204#c25
Reducing header inclusion can easily cause build breakages for non-unified 
builds.
So, I fixed non-unified build breakage in r264332 and r264333 as the 
preparation for that.
Non-unified builds was more broken than I expected. Does anyone still need it?
Should we maintain non-unified builds until C++20 modules will nullify unified 
builds?

___
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] Introducing a minimum ICU version for WebKit

[Kirsling, Ross]

No need for apology—I hugely appreciate the support on this, given the shrouded 
process of getting those ZIP files updated! :D

Ross

From:  on behalf of Brent Fulgham 
Date: Thursday, April 9, 2020 at 3:16 PM
To: Ryosuke Niwa 
Cc: "Kirsling, Ross" , "webkit-dev@lists.webkit.org" 

Subject: Re: [webkit-dev] Introducing a minimum ICU version for WebKit

Please note that Per Arne updated the Apple ZIP files to have the correctly 
aligned ICU libraries, so the Windows bots should have what they need.

I apologize for taking so long to complete that.

Thanks,

-Brent


On Apr 3, 2020, at 4:57 PM, Ryosuke Niwa 
mailto:rn...@webkit.org>> wrote:


On Fri, Apr 3, 2020 at 4:25 PM Kirsling, Ross 
mailto:ross.kirsl...@sony.com>> wrote:
Hi everybody,

Just sending out an email blast for visibility regarding 
https://bugs.webkit.org/show_bug.cgi?id=209694.

This patch:

  *   Upgrades the Mac ICU headers under Source/WTF/icu from ICU 55 to ICU 62, 
matching Mojave
  *   Introduces a minimum ICU version of 60.2 throughout the codebase, as 
required by GTK for Ubuntu 18.04 LTS

As written in the ChangeLog, the immediate motivations are:

  1.  To properly establish a minimum ICU version for WebKit as a whole
(responding to a pain point identified in 
https://bugs.webkit.org/show_bug.cgi?id=209579)
  2.  To support the development of ECMA-402 Intl API features, which JSC is 
quite behind on
(and which often boil down to exposing ICU functionality to JavaScript)

The only remaining concern of which I am aware is that AppleWin’s ICU headers, 
stored in WebKitAuxiliaryLibrary.zip, need to be upgraded from ICU 49 to 62 (to 
match the lib files stored in WebKitSupportLibrary.zip). We do have a potential 
workaround for this (i.e. having CMake copy the Mac headers to 
WebKitLibraries/win) but it is feared that this may break Apple-internal builds 
and we would certainly like to avoid a revert if possible. Any help on this 
front would be greatly appreciated.

FWIW, I've been told that Brent / Per might be able to help you there but might 
need some more time due to other more urgent commitments.

- R. Niwa

___
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] Introducing a minimum ICU version for WebKit

[Kirsling, Ross]

Hi everybody,

Just sending out an email blast for visibility regarding 
https://bugs.webkit.org/show_bug.cgi?id=209694.

This patch:

  *   Upgrades the Mac ICU headers under Source/WTF/icu from ICU 55 to ICU 62, 
matching Mojave
  *   Introduces a minimum ICU version of 60.2 throughout the codebase, as 
required by GTK for Ubuntu 18.04 LTS

As written in the ChangeLog, the immediate motivations are:

  1.  To properly establish a minimum ICU version for WebKit as a whole
(responding to a pain point identified in 
https://bugs.webkit.org/show_bug.cgi?id=209579)
  2.  To support the development of ECMA-402 Intl API features, which JSC is 
quite behind on
(and which often boil down to exposing ICU functionality to JavaScript)

The only remaining concern of which I am aware is that AppleWin’s ICU headers, 
stored in WebKitAuxiliaryLibrary.zip, need to be upgraded from ICU 49 to 62 (to 
match the lib files stored in WebKitSupportLibrary.zip). We do have a potential 
workaround for this (i.e. having CMake copy the Mac headers to 
WebKitLibraries/win) but it is feared that this may break Apple-internal builds 
and we would certainly like to avoid a revert if possible. Any help on this 
front would be greatly appreciated.

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

Re: [webkit-dev] Terminology: Could we change 'roll out' to 'roll back'?

[Kirsling, Ross]

I'd be thrilled for us to use 'revert'.
Somehow I'd convinced myself that it'd be easier to ask for this if we kept the 
'roll' part, but I'm not really sure why I thought so.

Of course, it's fine for folks to continue to _say_ 'roll out' due to habit; I 
just think it would be great if our automated 'rollouts' turned into automated 
'reverts' instead.

Ross

On 3/6/20, 6:31 PM, "Ryosuke Niwa"  wrote:

On Fri, Mar 6, 2020 at 6:15 PM Kirsling, Ross  
wrote:
>
> Late on Friday seems like a good time for a terminological debate (), so 
I’d like to propose we revisit one of the strangest items of WebKit-specific 
terminology: the phrase ‘roll out’.
>
> In our industry, the typical meaning of the phrase ‘roll out’ is, of 
course, ‘deploy’ or ‘launch’; this corresponds with the colloquial usage of 
‘roll out’ to mean ‘depart (for a destination)’. In WebKit, we use ‘roll out’ 
to mean the exact opposite, ‘revert’ or ‘roll back’.

I think the ship has sailed on this one. People who have been working
on the WebKit project for long enough are so used to the phrase
"rollout a patch" that it's gonna be tricky to change the terminology.
Having said that, I'd much prefer the term "revert" over "rollout" or
"rollback". It's also the term git uses.

> This term is confusing enough for native English speakers outside our 
community, let alone non-natives (since phrasal verbs are notoriously tricky as 
it is).

As a non-native speaker myself, I never find this term confusing
because I have no mental model of what "rollout" or "rollback" means.
However, I find those two terms infinitely more confusing than the
very direct "revert".

- R. Niwa


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

[webkit-dev] Terminology: Could we change 'roll out' to 'roll back'?

[Kirsling, Ross]

Greetings WebKittens,

Late on Friday seems like a good time for a terminological debate (), so I’d 
like to propose we revisit one of the strangest items of WebKit-specific 
terminology: the phrase ‘roll out’.

In our industry, the typical meaning of the phrase ‘roll out’ is, of course, 
‘deploy’ or ‘launch’; this corresponds with the colloquial usage of ‘roll out’ 
to mean ‘depart (for a destination)’. In WebKit, we use ‘roll out’ to mean the 
exact opposite, ‘revert’ or ‘roll back’.

In terms of metaphors: The typical meaning of ‘roll out’ is synonymous with 
‘roll forward’, hence the opposite being ‘roll back’. The way that I came to 
explain to myself and others what WebKit means by ‘roll out’ is that it’s 
movement along the other axis. There is a tree (SVN trunk) which is built up 
from disc-shaped slices (revisions), and these slices are rolled sideways in 
and out of the tree. Needless to say, this is not obvious to a newcomer, and 
it’s not even accurate to how SVN works—rollouts don’t remove an old revision, 
they add a new revision to perform the revert!

This term is confusing enough for native English speakers outside our 
community, let alone non-natives (since phrasal verbs are notoriously tricky as 
it is). Having heard complaints about this from people in both of these groups 
within the last few weeks, I hereby propose that we start using ‘roll back’ 
instead. Given the string similarity between the two, I hope that this will be 
a relatively easy change to enact, if folks are onboard with it.

Thanks for your consideration!

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

[webkit-dev] Question regarding per-file BSD license text

[Kirsling, Ross]

Hi all,

I have a simple question about the license text included in each source file.

My understanding is that if a non-Apple contributor adds a new file, their 
affiliation should only be reflected in the copyright line and NOT in the BSD 
license text itself (which reads "APPLE INC."), because the latter is a 
"per-file copy of a project-wide license". Could someone confirm whether or not 
this is correct?

I believe this is what's implied by "preferred license text" at 
https://webkit.org/contributing-code/#develop-your-changes, but it's not 100% 
spelled out.
I do see a handful of exceptions in the codebase, where "THE COPYRIGHT HOLDER" 
or "GOOGLE INC." or "UNIVERSITY OF SZEGED" is used instead, but the vast 
majority of files are in alignment.

(Incidentally, it looks like we also need to update the paragraph I linked to 
reflect the WebKitLegacy move.)

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