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@lists.webkit.org> wrote: > 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. 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
signature.asc
Description: PGP signature
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
