> On Apr 29, 2021, at 9:06 PM, Tim Horton via webkit-dev
> wrote:
>
> it is definitely highly annoying
It’s possible that where my thinking differs from others on this is that I
don’t think shifting annoying work from one set of commits (the ones adding a
new file) to a different set (the
> On Apr 29, 2021, at 9:02 PM, Darin Adler wrote:
>
>> On Apr 29, 2021, at 9:01 PM, Tim Horton wrote:
>>
>> This is a huge problem for people on the Apple platforms using the Xcode
>> projects. Nearly every time someone adds a file they have to add random
>> headers to unrelated code.
>
>
> On Apr 29, 2021, at 7:15 PM, Darin Adler via webkit-dev
> wrote:
>
>> On Apr 29, 2021, at 12:04 PM, Ross Kirsling via webkit-dev
>> wrote:
>>
>> Yeah, I think it's important to clarify that nobody is "using
>> non-Unified-Source building for their development", at least to my
>>
> On Apr 29, 2021, at 9:01 PM, Tim Horton wrote:
>
> This is a huge problem for people on the Apple platforms using the Xcode
> projects. Nearly every time someone adds a file they have to add random
> headers to unrelated code.
OK, sorry, I must be out of touch with the rest of you about how
> On Apr 29, 2021, at 12:04 PM, Ross Kirsling via webkit-dev
> wrote:
>
> Yeah, I think it's important to clarify that nobody is "using
> non-Unified-Source building for their development", at least to my knowledge.
> Being broken by the shifting sands of unified sources is an everybody
On 2021-04-29 20:07, BJ Burg wrote:
> Given that there is some disagreement as to whether this is even a
> problem at all, perhaps we could try it out for a while. Diego, do you
> have the resources to set up an EWS bot in this configuration?
>
Yes, we have two workers ready for this new EWS
On Thu, 29 Apr 2021 19:04:55 + Ross Kirsling via webkit-dev
wrote:
> Yeah, I think it's important to clarify that nobody is "using
> non-Unified-Source building for their development", at least to my
> knowledge. Being broken by the shifting sands of unified sources is an
> everybody
Thanks, David. I think we’re on the same page now.
> On Apr 29, 2021, at 12:47 PM, David Benjamin wrote:
>
> Ah yes, that is confusing. Not quite. What's going on here is that we've
> moved 3DES (and SHA-1 server signatures) under a fallback connection, so our
> first connection won't
Ah yes, that is confusing. Not quite. What's going on here is that we've
moved 3DES (and SHA-1 server signatures) under a fallback connection, so
our first connection won't advertise them, but on error the second one
will. This means that, for compatibility and security purposes, we *do* support
On Thu, 29 Apr 2021 15:56:31 + Don Olmstead via webkit-dev
wrote:
> When the Mac CMake build is in a working state I'd request an EWS that is
> Non-Unified as well since Mac builds cover more code.
This would be a great addition, I agree. While I don't have a Mac around,
I can try and
Yeah, I think it's important to clarify that nobody is "using
non-Unified-Source building for their development", at least to my knowledge.
Being broken by the shifting sands of unified sources is an everybody problem
(or at the very least an "everybody that builds via CMake problem", which is
I'm in favor of a non-Unified EWS builder. It seems it would largely prevent
the current situation where I have to add random headers to make my patch
build, usually after the patch has been reviewed and revised. This "surprise,
someone forgot a header" situation has no effect on our production
I don’t see the goal as “keep non-Unified-Source building” but rather “prevent
unrelated build fixes when we add another file later”. Right now when we add a
new file we often have to sprinkle includes, declarations, and other build
fixes in files unrelated to the current change. If we had a
Given the issue is that there are people that are using non-Unified-Source
building for their development, the best fix is to add post-commit and EWS
builders for one of those platforms. I do not support the idea of adding an
additional builder just to “keep non-Unified-Source building” if no
Hi,
Do we have a post-commit non-unified builder? Starting with EWS wouldn't seem
like a workable plan to me, as breakages would creep in anyway, and it's really
hard to notice and isolate those from EWS results alone.
Giving all WebKit developers the responsibility to support more build
When the Mac CMake build is in a working state I'd request an EWS that is
Non-Unified as well since Mac builds cover more code.
-Original Message-
From: Alex Christensen via webkit-dev
Sent: Thursday, April 29, 2021 8:16 AM
To: dpino
Cc: webkit-dev@lists.webkit.org
Subject: Re:
I’d be excited to have this. Those build failures have been bothering me ever
since we started using unified builds. We would have a way to see more
problems in our code that are currently hidden.
> On Apr 28, 2021, at 11:45 PM, dpino via webkit-dev
> wrote:
>
> Hi everyone,
>
> In Igalia
Hi webkit-dev,
This is a request for WebKit's position on Delegated Ink Trails.
It is currently in progress behind a flag in Chromium. There is no spec yet,
but here is a link to the WICG explainer:
https://github.com/WICG/ink-enhancement
Thanks,
Mario Bianucci
(Apologies for the noise if you
Hi everyone,
In Igalia we have been discussing the need of deploying a new builder
which builds WebKit using non-unified sources, and we know that at least
the folks at Sony are also in favor.
One side effect of Unified Source building is that it hides compilation
errors. The kinds of errors
19 matches
Mail list logo
