Re: [webkit-dev] Proposal to update WebKitGTK dependency policy
On Tue, Mar 8 2022 at 03:01:04 PM +0100, Carlos Alberto Lopez Perez wrote: 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. Ah, alas. Well it's ultimately Igalia's choice, of course. - Which port(s) is RedHat interested in supporting? Only the GTK port, or both GTK and WPE? We ship WebKitGTK, libwpe, and wpebackend-fdo, but not WPE WebKit. - Is RedHat willing to devote development time to work upstream on the goal of keeping WebKit working with older libraries? Um, yes, of course nobody except me is likely to spend time to keep WebKit building on RHEL. The difference is I would be able to commit my changes upstream in the future, instead of keeping them downstream and rebasing them when they break. E.g. it looks like https://bugs.webkit.org/show_bug.cgi?id=235367 will have to live downstream. If we had this policy, I would be able to land stuff like that upstream too. The main impact on other developers would be an increased wait before you can remove preprocessor guards that support older library versions. That could be annoying, but I don't think it will require too much time commitment. - Will buildbots be provided for RHEL, in the same way Igalia maintains Ubuntu LTS and Debian stable builders to catch issues? I'm not personally very concerned about whether we have upstream builders for RHEL, since fixing problems when they reach tarball releases is good enough for me. But yes, since you requested it, we can probably add upstream bots. (They would probably actually run CentOS Stream, not RHEL.) That will take some time, though, because I'm not currently working on it. In my previous mail, I said I would defer this proposal until we are ready with the requested bots. I do very much want to add more JSC cloop EWS, and I bet Red Hat infrastructure folks might find time to help with those. We can probably add some builders at the same time. But to keep timeline in perspective: I've been planning this for years, but have not yet started on it. :P 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. Hm, I guess I'd better gratefully accept whatever I can get. I'll attempt to keep it working downstream for the full 3+2 years regardless. Regarding resources from Red Hat to help upstream: that's going to remain just me. Certainly I would handle any changes needed to keep WebKit working on RHEL. Beyond that, I'll continue to help out a bit here and there. I wouldn't expect to see major changes in my contribution habits. Michael ___ 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
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
On Thu, Feb 17 2022 at 01:20:50 PM -0600, Michael Catanzaro via
webkit-dev wrote:
That seems like a reasonable request. I'll delay modifying the policy
until I'm able to provide an answer regarding the requested bots.
This could take a while, so the proposed policy change is dead for now.
But hypothetically, if I did have some bots ready, would Igalia be OK
with the proposed change? You seemed skeptical ("I think this may cause
tension in the future regarding supporting the usual GNOME libraries
that move fast: GTK, GStreamer, etc") and I'm sensitive to the fact
that proposing additional burden on other devs is not exactly a super
nice thing to do. I wonder what other devs think.
Michael
___
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
On Thu, Feb 17 2022 at 05:41:34 PM +, Carlos Alberto Lopez Perez via webkit-dev wrote: 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. Yes. I think this may cause tension in the future regarding supporting the usual GNOME libraries that move fast: GTK, GStreamer, etc Possibly, yes. In practice, I think we're already in the habit of keeping #ifs for older dependencies around for longer than is required by our policy, so I suspect it will probably not be *too* annoying compared to our current practice. I wish this would benefit Ubuntu as well, but in practice it won't, since they cannot keep up with our toolchain requirements, and Apple doesn't want to support older toolchains. That's tough to square. :/ To give some data, the last version of RHEL is 9 (released on Nov 2021) Nov 2021 was RHEL 9 beta. We are planning to release RHEL 9.0 this coming spring. 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 Yes, though keep in mind I'm proposing to match the latest minor release (currently RHEL 8.5), not the earliest minor release (RHEL 8.0). We used to update desktop package versions fairly aggressively in RHEL 7 (so long as they don't break API/ABI), but in RHEL 8 we have been more conservative and have mostly stopped doing so. So in practice, yes, most of those versions are indeed unlikely to change. 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? That seems like a reasonable request. I'll delay modifying the policy until I'm able to provide an answer regarding the requested bots. We'd probably have them run CentOS Stream rather than actual RHEL. I suppose that's what we should target with the dependencies policy, as well, since it's simpler than having to know the difference between different RHEL minor releases. What we *really* want most of all is JSC EWS for aarch64, ppc64le, and s390x. Adding a couple x86_64 buildbots should be comparatively easy Michael ___ 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
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
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] Proposal to update WebKitGTK dependency policy
Hi, Since nobody objected to this proposal, I will update our policy soon. Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Proposal to update WebKitGTK dependency policy
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." Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
