<html>
    <head>
      <base href="https://bugs.webkit.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [GTK][GStreamer] ClearKey EME v1 decryption support"
   href="https://bugs.webkit.org/show_bug.cgi?id=154235#c12">Comment # 12</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - [GTK][GStreamer] ClearKey EME v1 decryption support"
   href="https://bugs.webkit.org/show_bug.cgi?id=154235">bug 154235</a>
              from <span class="vcard"><a class="email" href="mailto:pnormand&#64;igalia.com" title="Philippe Normand &lt;pnormand&#64;igalia.com&gt;"> <span class="fn">Philippe Normand</span></a>
</span></b>
        <pre>(In reply to <a href="show_bug.cgi?id=154235#c10">comment #10</a>)
<span class="quote">&gt; Comment on <span class=""><a href="attachment.cgi?id=271332&amp;action=diff" name="attach_271332" title="patch">attachment 271332</a> <a href="attachment.cgi?id=271332&amp;action=edit" title="patch">[details]</a></span>
&gt; patch
&gt; 
&gt; View in context:
&gt; <a href="https://bugs.webkit.org/attachment.cgi?id=271332&amp;action=review">https://bugs.webkit.org/attachment.cgi?id=271332&amp;action=review</a>
&gt; 
&gt; &gt; Source/WebCore/ChangeLog:24
&gt; &gt; +        disabled by default.
&gt; 
&gt; I see the technical advantage to us in upstreaming this code, even if it
&gt; will never be used by any distros and always disabled by default in
&gt; OptionsGTK.cmake. But I kinda think it should be enabled by default in
&gt; FeatureList.pm, for developers, even if it's not going to be used by any
&gt; distros. Otherwise the build will be broken all the time, and we won't be
&gt; able to run layout tests on the bot, and without running layout tests we
&gt; won't notice when the functionality breaks. I understand we'll only be able
&gt; to test ClearKey, but that seems fine to me, and much better than adding
&gt; this with no tests.
&gt; 
&gt; So, I am going to r- this, hoping not to set back your work, just until
&gt; we're ready to enable it for development builds and can either add or unskip
&gt; at least a couple of tests, and pending our transition to GStreamer 1.6 on
&gt; the bots. (I would love to see that sooner rather than later, because our
&gt; users have had GStreamer 1.6 for a long time now.)
&gt; </span >

Ok so this is the exact same situation as in WebRTC support. We disabled it temporarily in the bots and provided a custom JHBuild moduleset. Would that be OK with you?

About the concern of this not being enabled and bitrotting, I think it's not a valid concern because this code is actively used in a downstream fork. So every build break that will happen will be noticed downstream and I'll be happy to fix in ToT whenever needed :)</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>