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

[Adrian Perez de Castro]

Hello,

I have picked this message from Ryosuke because I want to explicitly address
a misjudged metric on the effort it takes to address non-unified build issues
after patches that break them have landed -- but my comments apply to the
discussion in general.

On Wed, 01 Jun 2022 16:39:39 -0700 Ryosuke Niwa via webkit-dev <webkit-dev at lists.webkit.org> wrote:
> On Wed, Jun 1, 2022 at 16:10 Kirsling, Ross via webkit-dev <
> webkit-dev at 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.

I have recorded at least 23 patches fixing non-unified builds in the last
couple of weeks. Not all of them from Sony/Igalia folks. Assuming that each
patch took around 1h to solve on average, this means we are investing a
whopping *six days per month* fixing non-unified builds. Let me re-state
that:

  We have collectively spent 1 out of every 4 weeks fixing build issues.

Let that sink in for a moment.

Sure, some patches take less than an hour, but I *know* from working on them
that some take definitely more than one or two hours. One hour average seems
reasonable, knowing that it's not only applying the fix, but also testing
whether it worked, making sure we don't introduce unneeded #includes, writing
commit log entries, and waiting that EWS runs over the fix to be minimally
sure that nothing else got broken.

The above 1h per patch is time from *experienced* developers. Even if we could
offload these patches to beginners, it would take them *even more time* and in
my opinion it would be *extremely unfair* towards them. Not to mention it
would be counter-productive for the WebKit project at large to burn out
newcomers with a responsibility that, as others already pointer, should be
shared among all of us.

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

This is a straw man argument. The fact that other changes like refactors
may break other ports is not a justification to push more build failures
(even if simpler) to other ports *unnecessarily*.

We are not only pointing the issues with non-unified builds, but we are also
putting the money^W effort where our mouth is. Not only we had made building
WebKit more robust for everybody with our continued trickle of patches, we
have spent time and hardware resources setting up a post-commit builder, and
now we are offering to commit further hardware to have pre-commit EWS
builders. We want to see the EWS block from merging patches which break
the non-unified builds *that* badly.

Cheers,
—Adrián
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20220902/5bd26283/attachment.bin>