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

[dpino]

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 agree that the best solution is to have a
EWS non-unified build bot. 

Lastly, I wonder if the opposition against deploying a EWS non-unified
bot is because the proposed bot targets WPE. I would be equally happy if
the bot targeted Mac, but we're not proposing that platform because we
don't have the required infrastructure. Is there any chance Apple would
consider deploying EWS non-unified bots for Mac?  

Diego
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20220602/725bb10a/attachment.htm>