| Summary: | [GTK][EFL] Disable subtle-crypto in FeatureList.pm | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> | ||||
| Component: | WebKitGTK | Assignee: | Michael Catanzaro <mcatanzaro> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | bugs-noreply, cgarcia, clopez, dbates, elima, gyuyoung.kim, mcatanzaro, mrobinson | ||||
| Priority: | P2 | ||||||
| Version: | Other | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=155008 | ||||||
| Attachments: |
|
||||||
|
Description
Michael Catanzaro
2016-03-05 16:13:32 PST
Created attachment 273106 [details]
Patch
By the way, it's failing EWS due to bug #155008; just ignore that, I will push an unreviewed build fix. Comment on attachment 273106 [details]
Patch
OK
Committed r202535: <http://trac.webkit.org/changeset/202535> Please skip crypto/subtle layout tests (they were passing until now) (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. (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. 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. |