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

[dpino via webkit-dev]

Hi Alexey,

On 6/2/22 06:26, Alexey Proskuryakov wrote: 

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

Sorry, I disagree with your point of view. 

Now that we have the post-commit non-unified build it has become evident
to me that actively maintaining non-unified builds is less work than
doing it on demand. When the post-commit non-unified is green and a
build fails is trivia to spot which commit introduced a regression and
what it might be the causes. When maintaining the bot on demand, errors
eventually accumulate and becomes less trivia how to fix them. A
non-unified EWS bot has the same benefits as the post-commit non-unified
EWS, plus is the developer who attempts to land the patch who is in
charge of fixing the build. This is more efficient that offloading this
work to other developer. Take for instance, this non-unified build fix I
recently landed:
https://github.com/webkit/webkit/compare/3a5a57d060ee%5E..3a5a57d060ee
It took me a long time to figure out I had to include "JSNodeCustom.h"
in some files, but possibly for the developer authorizing the patch that
introduced the regression, this build error was trivial.

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

I don't have stats to answer how often it happens satisfactorily, but I
know that both in WebKitGTK, WPE and other WebKit ports build errors
will eventually happen while building with unified sources. IMHO the
earlier you can find them the better. We have even made WebKitGTK
releases that failed due to unified sources build errors
https://stackoverflow.com/questions/64744576/incomplete-webkitgtk-build.


> How do we decide if everyone is responsible for the convenience of downstream 
> embedders?

I think there's a wrong perception that non-unified build errors are
errors happening in the WebKit ports part of the code. Most of the times
they are build errors in WebCore, JavaScriptCore and many other parts of
the codebase. If you build Mac with non-unified compilation probably
you'll discover a bunch of build errors. I have fixed a bunch of
non-unified build errors in the Mac port while building the Playwright's
version of WebKit for Mac: 

  - [macOS] Unreviewed, non-unified build fixes
https://bugs.webkit.org/show_bug.cgi?id=239889 
  - [macOS] Unreviewed, non-unified build fixes
https://bugs.webkit.org/show_bug.cgi?id=237586 
  - [macOS] Non-unified build fixes
https://bugs.webkit.org/show_bug.cgi?id=236752 

These patches landed upstream, they're not errors in the downstream code
of Playwright. 

So it's not a downstream embedder who introduces a build error in the
codebase, simply they're more likely to discover it because the
introduced downstream changes causes the UnifiedSource files to be
arranged in a different way. Who is the responsible for the build error?
The developer who introduced the build error obviously, not the person
who discovered it. 

>From my point of view, a project's code should be guaranteed to be
always buildable under any supported configuration and it shouldn't rely
on collateral effects to build successful (which is the current
situation with unified sources). I understand the convenience of unified
sources and the advantage they bring. A EWS non-unified bot will
guarantee the entire codebase is always buildable while letting us keep
using unified sources. From time to time, the EWS non-unified bot will
report a build error, and the most suitable person to fix that error
will be in charge of it. And we know, thanks to the post-commit
non-unified bot we deployed, the non-unified bot won't introduce delays
as many times it's even faster than the equivalent unified sources build
bot, and of course it's always faster than the EWS LayoutTests bots. 

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

Exactly, this how I see it. If we agree that a person authorizing a
patch is always in a better position to fix a build error than somebody
else stranger to that patch, and if we value the time of everybody
equally, then we will likely

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

[Michael Catanzaro via webkit-dev]

On Sat, May 21 2022 at 09:43:06 AM -0500, Michael Catanzaro 
 wrote:
I would go even further and consider enabling unified builds only in 
DEVELOPER_MODE (for CMake ports). For non-developer builds, 
compilation time is much less important than limiting RAM usage to 
reasonable levels. Using ninja's default parallelization level, I 
recently started hitting OOM failures even on a machine with 64 GB 
RAM! We have many people complaining that they cannot build on more 
normal machines with 16 GB RAM. If we have an EWS to ensure the 
non-unified build actually works, then it should be safe enough to 
make it the normal supported path for non-developers, rather than 
just a "best effort, let's hope it works today" thing.


Any objections to this proposal?

I would additionally request that the non-unified EWS also disable 
DEVELOPER_MODE, so we can additionally make sure we don't break the 
build when experimental features tied to that (e.g. WebRTC or LFC) are 
disabled. All the other EWS have DEVELOPER_MODE enabled, and this has 
been a regular problem in the past.


Michael


___
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

[Ryosuke Niwa via webkit-dev]

On Wed, Jun 1, 2022 at 16:10 Kirsling, Ross via webkit-dev <
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>>
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 core

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

[Alexey Proskuryakov via webkit-dev]

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

[webkit-dev] 안광림 is out of office.

[안광림 via webkit-dev]

Period : 2022/05/23 00:00 ~ 2022/07/15 00:00 [Korea Standard Time]

부재중입니다.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Request for position on COEP reflection

[Alex Christensen via webkit-dev]

Seems reasonable.

> On May 31, 2022, at 6:14 AM, Arthur Sonzogni via webkit-dev 
>  wrote:
> 
> Greetings webkit-dev,
> 
> I am requesting your feedback about exposing:
> ```js
> self.crossOriginEmbedderPolicy;
> ```
> It reflects the environment's crossOriginEmbedderPolicy's value.
> 
> More details on:
> https://github.com/ArthurSonzogni/coep-reflection 
> 
> Thanks
> Arthur @arthursonzogni
> 
> ___
> 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