<html><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head><body bgcolor="#FFFFFF" text="#000000"><br>
<br>
Benjamin Poulain wrote:
<blockquote cite="mid:52325E43.4000206@webkit.org" type="cite">
  <meta content="text/html; charset=ISO-8859-1" 
http-equiv="Content-Type">

  
  
    
  <div class="moz-cite-prefix">On 9/12/13 5:21 PM, Thomas Fletcher
      wrote:<br>
    </div>

    
  <blockquote cite="mid:52325A97.7060904@cranksoftware.com" type="cite"><meta
 content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
      Geoffrey Garen wrote:
      <blockquote 
cite="mid:5B5A1EB3-342D-40C1-9A7D-ADF5A267908D@apple.com" type="cite"><blockquote
 type="cite"><pre wrap="">Sure. We at University of Szeged who work on WebKitNix from this year
contributed many fixes to various part of WebKit: JavaScriptCore,
WebCore, Tools, &#8230;
</pre></blockquote>
        <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, &#8220;...on ARM traditional&#8221; (<a moz-do-not-send="true" 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."<br></blockquote>

    I cannot talk for Geoff but here is my take.<br>

    <br>

    The WebKit code base has:<br>

    -Core features used by everyone.<br>

    -Core features used by many (e.g. curl, Texture Mapper, etc).<br>

    -Port code that is only useful for some people.<br>

    <br>

    In the WebKit project, we value the first two. The port work is
    necessary for everything to fit together, but that is not a
    contribution to the project per say.<br>

    It is always good to refer to the project goals as it summarizes
    this quite nicely: <a moz-do-not-send="true" 
class="moz-txt-link-freetext" 
href="https://www.webkit.org/projects/goals.html">https://www.webkit.org/projects/goals.html</a><br>

    <br>

    This being said, I think this thread is not longer very productive.<br>

    If you are interested in things like removing ancient CPU
    architecture, better start a new thread.<br>
</blockquote>
I disagree .. I think that this has been a very civil discussion on a 
very relevant topic to the long term sustainability<br>
of WebKit as an OpenSource project via an easier barrier to adoption 
into custom environments.&nbsp; I'm familiar with <br>
the project goals, which is another reason why you've never seen much 
back contributions from @cranksoftware.com <br>
since most of our work does indeed end up being in the area of "Port 
code that is only useful for some people".<br>
<br>
What this discussion is starting to center on is why the NIX port would 
not be valued as a mainstream port that,<br>
like the other ports, validates that the implementation of Core features
 (the first two items) makes sense in a broader <br>
context.&nbsp;&nbsp; <br>
<br>
Is the main concern about having maintainers for the port so it can be 
kept up to date or is it more a concern that<br>
the technology direction that the NIX port represents, as an alternative
 porting layer.&nbsp; That if people want to port to <br>
platforms they should drop down to a lower level and effectively start 
copying and pasting the stub implementations <br>
from other ports?<br>
<br>
Thanks,<br>
&nbsp;Thomas<br>
<br>
<br>
<br>
<br>
</body></html>