Bug 155073 – [GTK][EFL] Disable subtle-crypto in FeatureList.pm

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Michael Catanzaro]

Nobody is working on it and nobody has further plans to work on it.

This would have caught a build failure when we perhaps inadvertently added a required dependency on GnuTLS in r197575.

[Michael Catanzaro]

Created attachment 273106 [details]
Patch

[Michael Catanzaro]

By the way, it's failing EWS due to bug #155008; just ignore that, I will push an unreviewed build fix.

[Daniel Bates]

Comment on attachment 273106 [details]
Patch

OK

[Michael Catanzaro]

Committed r202535: <http://trac.webkit.org/changeset/202535>

[Carlos Alberto Lopez Perez]

Please skip crypto/subtle layout tests (they were passing until now)

[Carlos Garcia Campos]

(In reply to comment #5)
> Please skip crypto/subtle layout tests (they were passing until now)

Wait, why are we disabling a feature that is, at least partially, working? How do you know *nobody* is interested in this? If we disable this, and whatever is currently working breaks we will not notice it. Of course we can disable on production builds.

[Carlos Alberto Lopez Perez]

(In reply to comment #6)
> (In reply to comment #5)
> > Please skip crypto/subtle layout tests (they were passing until now)
> 
> Wait, why are we disabling a feature that is, at least partially, working?
> How do you know *nobody* is interested in this? If we disable this, and
> whatever is currently working breaks we will not notice it. Of course we can
> disable on production builds.

It was already disabled on production builds. It only was enabled on developer ones.

FWIW: I agree with turning on this feature back on developer builds. Otherwise development of this feature is going to be more complicated than necessary.

[Michael Catanzaro]

I disabled this feature because the difference in having it enabled on the bots and having it disabled in production builds led to a change that broke production builds without tripping the bots. It's better that we keep the build flags we use in development builds similar to those we use in production builds, except for a few features that are under active development, so that we have the same set of bugs.

I'll skip the layout tests, thanks for noticing.

(In reply to comment #6)
> Wait, why are we disabling a feature that is, at least partially, working?

Because the primary developer has moved on to another project, and nobody else has shown any interest in working on it since then.

> How do you know *nobody* is interested in this?

I have not seen any progress in it since I started working on WebKit. It's not on my to-do list, and probably not on yours either, and I'm not expecting a new contributor to materialize from nowhere with patches, and I'm not expecting Igalia to invest in it. So....

A lot of people are interested in the feature working, just nobody seems to be currently interested in working on implementing it. If anybody starts to actually work on it, we can turn it back on.

> If we disable this, and
> whatever is currently working breaks we will not notice it.

I honestly don't care if some feature we don't have enabled breaks. I'd actually rather we did not notice, because this feature is never going to be enabled at the current rate, so it's a waste of time trying to fix it. If it breaks, it can be fixed whenever someone wants to try enabling it again.

(In reply to comment #7)
> FWIW: I agree with turning on this feature back on developer builds.
> Otherwise development of this feature is going to be more complicated than
> necessary.

But I don't agree that it's complicated to enable a build flag. It's not like we're getting rid of the flag, you can still use it, we're just changing it to a default that's more suitable.

[Michael Catanzaro]

Updated expectations in r202561.