Re: [webkit-dev] WebKit Documentation

[Carlos Alberto Lopez Perez via webkit-dev]

On 09/03/2023 19:48, Brandon Stewart via webkit-dev wrote:
> What would people prefer we use as the official documentation location:
> (1) docs.webkit.org
> (2) developer.webkit.org
> (3) documentation.webkit.org
> (4) Other
+1 for docs.webkit.org (shorter is better)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] [PSA] WPE WK2 layout testers available on GitHub pull-requests and Bugzilla patches

[Carlos Alberto Lopez Perez via webkit-dev]

Hi,

Since today you should start seeing a new wpe-wk2 bubble/check-mark
appearing both on pull-requests and Bugzilla patches.

It is running with the same Buildbot classes than gtk-wk2 [1], so
it will try hard to discard any flakies or pre-existent failures
and only report new persistent failures caused by the patch.

If you detect it reporting some false positive or giving unexpected
errors please drop me a line (either via slack or reporting a bug
in Bugzilla and adding me to the CC).

Hope you find this useful.

Best regards


[1] https://lists.webkit.org/pipermail/webkit-dev/2021-December/032081.html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal to update WebKitGTK dependency policy

[Carlos Alberto Lopez Perez via webkit-dev]

On 17/02/2022 18:41, Carlos Alberto Lopez Perez via webkit-dev wrote:
> Personally I'm ok with this, since I usually error on the conservative
> side regarding updating dependencies. But I'm raising the topic to put
> things into perspective and to help having a debate.

It turns out this above opinion of mine doesn't reflect a consensus
opinion inside Igalia.

After sending the above e-mail, I talked with my colleagues at Igalia
(my failure for not doing that before) and it seems that we are not
happy with committing to support the libraries for such long amount of time.

On one hand we are afraid this can make upstream development slower.
On the other hand we have limited resources and supporting old libraries
is not part of our goals.


So would like to know whether RedHat plans to contribute to ensure that
the extended support would happen:

  - Which port(s) is RedHat interested in supporting? Only the GTK
port, or both GTK and WPE?

  - Is RedHat willing to devote development time to work upstream on
the goal of keeping WebKit working with older libraries?

  - Will buildbots be provided for RHEL, in the same way Igalia
maintains Ubuntu LTS and Debian stable builders to catch issues?


In any case, we think that 3+2 of support is too much. We can maybe
agree on 3+1 (support each RHEL version until one year after the next
one, like we do with Debian/Ubuntu) or on just 3 (no extra year of
support), depending on how much RH is willing to help upstream.

If RH is not willing to assign resources to help upstream then we would
rather leave the current policy as is (no change to include RHEL in the
dependencies policy)

Regards.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal to update WebKitGTK dependency policy

[Carlos Alberto Lopez Perez via webkit-dev]

On 17/02/2022 17:41, Carlos Alberto Lopez Perez via webkit-dev wrote:
> Also if we are going to do this, and we are serious about it, then we
> would need at least two new buildbots at build.webkit.org for testing
> the build on the last two versions of RHEL.
> Is RedHat going to provide the resources for the bots and is going to
> help taking care of things when they broke there?

Maybe with one is enough, to test on the older of the versions of RHEL
supported.

That is how we handle the Debian/Ubuntu support: we have the buildbots
configured to build on the older version supported.
Because if it builds on the older it should build on the newer :)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal to update WebKitGTK dependency policy

[Carlos Alberto Lopez Perez via webkit-dev]

On 08/02/2022 16:57, Michael Catanzaro via webkit-dev wrote:
> Hi,
> 
> I'd like to selfishly propose updating our dependencies policy
> https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy in order to
> accommodate RHEL in addition to Debian and Ubuntu. My goal is to provide
> WebKitGTK updates for the first five years (the "full support" period)
> of a RHEL major release, not just three years. However, we have some
> magic I don't understand allows use of newer toolchains, including newer
> libstdc++. We can actually somehow link newer libstdc++ into the same
> process as system libstdc++, so we can exempt the entire build toolchain
> (including CMake) from this policy, so this won't have any effect on
> discussions like "when can we use C++20 features" or "what version of
> CMake can we depend on."
> 
> The primary impact would be on dependencies like ICU, GStreamer, etc.
> ICU is particularly important because this library bumps its ABI with
> every major release, so updating ICU to newer major versions is not
> possible. This would lock us into supporting ICU 67 until spring 2027.
> If we decide to land https://bugs.webkit.org/show_bug.cgi?id=235367 --
> which currently looks unlikely -- then it would additionally lock us
> into ICU 60 until spring 2024.
> 
> I think five years' support would benefit Ubuntu as well -- this matches
> the primary support lifetime of an Ubuntu LTS -- except Ubuntu doesn't
> seem to have the capability to build with newer toolchains, which means
> that, in practice, they will stop updating WebKit whenever we require a
> newer build toolchain. And although I think it would be a good idea to
> support Ubuntu for longer, I'm not brave enough to propose that we
> freeze our build toolchain dependencies for five years. So I will not
> suggest extending the support period for Ubuntu.
> 
> Specifically, I propose adding the following text to our policy:
> 
> * "We support the latest minor release of each major version of RHEL
> until two years after the release of the next major version."
> 
> (Note: we currently have a three-year time-based release cycle, so
> that's five years total. If that were to unexpectedly change in the
> future, then adjusting the text of the policy would be needed.)
> 
> And:
> 
> * "For RHEL, WebKit is not expected to remain buildable using the
> default system libstdc++. The requirement for WebKit to remain buildable
> may be satisfied using GCC and LLVM toolsets from Application Streams."

If I understand this correctly, that would mean that we would have to
support the libraries that we rely on, up to a version that may be quite
old.

Right now we are supporting a cycle of 2+1=3 (both debian and ubuntu
release each 2 years). And this change would mean that we would have to
extend the period up to 3+2=5 which is quite more.

I think this may cause tension in the future regarding supporting the
usual GNOME libraries that move fast: GTK, GStreamer, etc

To give some data, the last version of RHEL is 9 (released on Nov 2021)
which means that we would support RHEL 8 up to Nov 2023. And RHEL 8 was
released on May 2019 and includes this versions of libraries we use:

gstreamer = 1.16
gtk = 3.22
glib = 2.56
libsoup = 2.62
cairo = 1.15
icu = 60.3

Personally I'm ok with this, since I usually error on the conservative
side regarding updating dependencies. But I'm raising the topic to put
things into perspective and to help having a debate.

Also if we are going to do this, and we are serious about it, then we
would need at least two new buildbots at build.webkit.org for testing
the build on the last two versions of RHEL.
Is RedHat going to provide the resources for the bots and is going to
help taking care of things when they broke there?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Using C++20 in WebKit

[Carlos Alberto Lopez Perez via webkit-dev]

On 22/01/2022 01:51, Alex Christensen via webkit-dev wrote:
> While we’re updating things, is there any objection to updating the
> minimum version of CMake required?  Right now it is 3.12, which was
> released in 2018.  Does anyone have any limitations we should consider
> when picking a new minimum version?
> 

Yes.

CMake is one of the core dependencies for GTK and WPE ports, so the
policy of dependencies applies [1]

In practical terms that means that we should support the version of
CMake shipped by Debian 10, which is CMake 3.13 until at least 2022-08-14.

However, If the purpose of raising the version is to take advantage of
the new Visual Studio generator then I don't think raising the minimum
version is needed.

As far as I know you can take advantage of newer CMake features (like
support for a newer generator) without needing to raise the minimum
version required.

So if you have a newer version of CMake you can simply pass the flag
-G"Visual Studio 17 2022" (or similar). Raising the minimum version
required of CMake is not needed to use a newer CMake generator, using it
can be made optional for those that want (and can) use it.


[1] https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [PSA] WebKitGTK layout testers available on the Bugzilla EWS bubbles

[Carlos Alberto Lopez Perez via webkit-dev]

On 24/12/2021 15:00, Michael Catanzaro via webkit-dev wrote:
> On Fri, Dec 24 2021 at 12:44:49 AM +0000, Carlos Alberto Lopez Perez via
> webkit-dev  wrote:
>> So we ended deploying a different version of the EWS that has a much
>> higher tolerance to pre-existent failures (up to 500 before exiting
>> early) and also that tries hard to discard pre-existent failures and
>> flakies by repeating each failure 10 times with patch and 10 times
>> without it. [1]
> 
> Mixed thoughts on this:
> 
> (1) Good job. Having layout tests on EWS is a great improvement. We've
> been talking about this for a long time, and you finally made it happen!
> 
> (2) That you needed to use such a big hammer to make the EWS work
> reliably suggests either that either WebKitGTK quality or WebKit test
> quality is quite low. I'm sure it's a mix of both, but mostly the
> former, because test flakiness is not this severe for Apple ports. This
> is not encouraging.
> 


Sorry, but I don't agree with your conclusion about quality.

So, let me explain in more detail the factors that contribute to this
issue with the tests:

  1) Number of unexpected failures on the clean tree

The higher number of unexpected failures on the clean tree is caused
mainly by the following reasons:

  1.1) Until now we didn't have an EWS. So it was pretty hard (if not
  impossible) for any developer to notice that the patch was going to
  break GTK tests. This didn't helped to avoid breaking patches landing.

  1.2) We don't have a rule to roll-back patches breaking GTK tests.
  If a patch lands adding unexpected failures for GTK those usually 
  stay there until some of our gardeners have time to fix the issue
  or mark the new failure as expected. Also having such rule wouldn't
  have made sense before having an EWS that developers can use.

  1.3) We don't have anyone working full-time doing gardening. We try
  to share the effort between us on a best-effort basis. So unexpected
  failures once landed can remain there for days until those are gardened.

  1.4) Patches landing via commit-queue run layout test on Mac before
  landing. So a patch won't land if it breaks layout tests on Mac.
  But it will land anyway if it breaks tests on GTK.

  2) Number of unexpected flaky tests

  2.1) It is true that we do have a higher number of flaky tests compared
  to Apple ports. But the flakiness issue is also a problem there.
  It is not unusual to see the standard EWS giving false positives due
  to some test being flaky.

  2.2) I'm not sure if our higher number of flaky tests is caused by
  some issue on the code of the port or is just that we don't have 
  enough manpower to be on top of flaky tests on a daily basis and
  mark any detected flaky test as soon as it is detected.


And regarding quality or test quality:

  3) Having the results of the layout tests "green" is not synonym of quality.
  Layout tests giving a "green" or "red" result is not about passing or failing
  the tests, is just about giving the "expected" result (which can be a 
failure).
  A port can have lot of failures marked as "expected failure" or lot
  of flaky tests marked as "expected flaky" and be more green than
  other port that has less failures or less flaky tests but not marked.

  If you want to compare the quality of the ports, then maybe something like
  wpt.fyi [1] can be more useful than WebKit layout tests, because tests there
   can't be "expected failures". So it will be only green if it passes the test.


And looking ahead to improve things:

  4) I expect the number of unexpected failures in the clean tree to start
  to be more controllable now that we have this EWS working an developers
  can be notified in advance of a breaking change before landing.

  5) The EWS also has now code to detect flaky tests when it does all those
  runs and repeats, and is sending mails to the bot watchers with the names
  of all the flaky tests that it detects. We will be gardening those with
  the idea of reducing the number of unexpected flakies.


[1] 
https://wpt.fyi/results/?label=master=experimental=safari=webkitgtk

> (3) Any plans for WPE?
> 

Yes. We look forward to add WPE testers as soon as possible. Hopefully it will 
happen in 2022-Q1.


Best regards and happy holidays!


[1] 
https://wpt.fyi/results/?label=master=experimental=safari=webkitgtk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] [PSA] WebKitGTK layout testers available on the Bugzilla EWS bubbles

[Carlos Alberto Lopez Perez via webkit-dev]

Hi,

Some of you might have noticed that since a few days ago on the Bugzilla
there is a new EWS bubble for GTK WK2 layout tests.

Until now the GTK port was without layout test coverage on the EWS.

It has been a challenge to add this testers on the EWS because the GTK
port layout tests are usually not 100% green and there are usually
unexpected failures and also flakies. This means that the EWS was
usually either reporting false positives (due to flakies) or exiting
early (because of more than 30 unexpected failures on the clean tree or
more than 30 accumulated between the ones caused by patch and the ones
in the clean tree)

We tried to do extra gardening efforts to try to mark all the flakies
and also to try to keep it always green, but for several reasons we
couldn't keep it on this always-green status for more than a few
consecutive days. Also new flakies would keep appearing.

So we ended deploying a different version of the EWS that has a much
higher tolerance to pre-existent failures (up to 500 before exiting
early) and also that tries hard to discard pre-existent failures and
flakies by repeating each failure 10 times with patch and 10 times
without it. [1]
This new version of the EWS WK2 layout tester is only used on the GTK
port for now, and we plan to use it also for the WPE port when we deploy
layout tests on the EWS for it.

So this has the advantage that this EWS should not report false
positives or flakies. Any failure reported by it should be a consistent
new failure (fails always with the patch but never without it after 10
runs with patch and 10 without it). If you see it reporting any false
positive please let me know it.

However, it has also the disadvantage that the view to see the layout
test results is a bit confusing because you see there also failures
unrelated with your patch (those are either pre-existent failures or
flakies)

My tip here is to only pay attention to the test failures reported by
the EWS as new, which are those that are shown on the Bugzilla bubble
when you hover the mouse over it (or those that appear on the e-mail
that you receive from the EWS)

Perhaps I'm thinking it can be a further improvement to add an extra
step to do a final run with the patch just for the list of new failures,
in order to present a clean view of the results with only the new failures.
This can be also very useful to be able to properly use the script
update-test-expectations-from-bugzilla to automatically apply the new
test expectations from the EWS locally.

Any comments welcome :)


Best regards!

[1] https://bugs.webkit.org/show_bug.cgi?id=231999
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Using C++20 in WebKit

[Carlos Alberto Lopez Perez via webkit-dev]

On 06/12/2021 22:36, Yusuke Suzuki via webkit-dev wrote:
> I recently upgraded GCC requirement to 8.3.0 based
> on https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement
>  
> (https://trac.webkit.org/changeset/283348/webkit
> )
> As a result, we can use some of C++20 features.
> I wonder if we can flip C++20 now. While some of C++20 features cannot
> be used since GCC 8.3.0 does not support, but some of features can be
> used, and it is super useful.

From the PoV of WebKitGTK I think it is Ok to enable now the building
with C++-20 support and to start using the C++-20 features already
supported by GCC 8.3.0

Check here: https://gcc.gnu.org/projects/cxx-status.html which C++-20
features are supported by GCC 8

Before using them I think it would be a good idea to double-check if
those are also supported by the minimum version of Clang that we want to
support.
And maybe also to check if those are supported by MS Visual C++ ?
I say maybe because I'm not sure if we support this compiler.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Using C++20 in WebKit

[Carlos Alberto Lopez Perez via webkit-dev]

On 06/12/2021 20:52, Alex Christensen via webkit-dev wrote:
> In April 2019 in https://bugs.webkit.org/show_bug.cgi?id=197131
>  I increased WebKit’s
> minimum C++ language requirement from C++14 to C++17.  In 2022 I’m
> planning to increase WebKit’s minimum C++ requirement from C++17 to
> C++20.  Would April 2022 be a good time to do that?
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 



According to the WebKitGTK Dependencies policy [1], we have to support
GCC-8 until August 2022. But we would like, if possible, to support it
until October 2022 which is when we will branch for doing the 2.38.x
releases. That way we can do one more official release supporting GCC-8.

Then, after October 2022 we can raise the minimum GCC requirement to
GCC-9. On April 2023 we can raise the minimum GCC requirement to GCC-10
and so on.

So this will be the timeline of minimum versions required that would fit
our policy:

 - Now until October 2022 -> GCC-8
 - October 2022 - April 2023 -> GCC-9
 - April 2023 - 2024 -> GCC-10


Depending on the minimum GCC version required some C++-20 features can
be used. You can check those on this "C++20 Language Features" table [2]

Some examples that were brought here:

 - initializer for bit-fields -> GCC-8 (so that can be used already now)
 - coroutines -> GCC-10 (will have to wait until April 2023)

Regards!


[1] https://trac.webkit.org/wiki/WebKitGTK/GCCRequirement
[2] https://gcc.gnu.org/projects/cxx-status.html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New EWS Non-Unified builder

[Carlos Alberto Lopez Perez via webkit-dev]

On 30/04/2021 06:17, Darin Adler via webkit-dev wrote:
>> 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 ones unknowingly adding need for a new 
> include for non-unified builds) is a significant improvement.

I think the issue is not about shifting the work from one sets of commit
to another, but about shifting the work from one developer that is
knowledgable on the code to other that maybe is not.

When you work on a patch, knowing what your includes should be on your
patch is easy if the include-breakage is related with the code you are
touching because you are understanding the code you are working on.

But when totally unrelated code breaks because of your patch, then is
not so easy to quickly fix the issue. At least for those of us that
don't know everything about the internals of WebKit.

Is also not hard, but it would be much easier to fix for the person that
introduced that code since they were familiar with it.

So meanwhile the person that wrote that code would have identified the
include that was missing in X time, I would need X*100 time because I
first need to understand what is going on, and then understand the bare
minimum of the unrelated code that broke to identify the issue, to
finally start hunting down via greps the missing include file. And this
assumes you are already familiar with this issue of missing include
files happening randomly, because otherwise the first time you discover
this you will spend even more time wondering what is happening.


> Adding more EWS bubbles has a cost.
> 

Indeed.
But if it saves time to developers working on the codebase (which I
truly believe it does) then I think it really outweighs the cost IMHO.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev