<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000"><blockquote cite="mid:5B5A1EB3-342D-40C1-9A7D-ADF5A267908D@apple.com" type="cite"><pre wrap="">Thank you for this list. I started reading through it, but I noticed a high percentage of patches that were port-specific build fixes or port-specific features like support for legacy ARM chips. For example, “...on ARM traditional” (<a class="moz-txt-link-rfc2396E" href="https://trac.webkit.org/changeset/142616">&lt;https://trac.webkit.org/changeset/142616&gt;</a>). Those patches are cost to core WebKit development, not benefit. </pre>
</blockquote>
I don't want to mis-interpret your statement here.&nbsp; Can you clarify what
 you mean by "Those<br>
patches are cost to core WebKit development, not benefit.”</div></blockquote><div><br></div></div>Consider &lt;<a href="https://bugs.webkit.org/show_bug.cgi?id=117281">https://bugs.webkit.org/show_bug.cgi?id=117281</a>&gt; — a patch for legacy CPUs that don’t have floating point processing. That patch took three months of reviews, spanning three different core JavaScript hackers, to get right. And after that, it was still wrong, and it required three follow-up fixes.<div><br></div><div>That’s cost.</div><div><br></div><div><div>Geoff</div></div></body></html>